English version
DBA interview questions are easier to answer when the concepts are connected instead of memorized one by one. RDBMS design, normalization, stored procedures, triggers, views, transactions, locks, and indexes all show up together when a database is operated in production.
An RDBMS, or relational database management system, stores and manages data through structured tables. Tables are made of rows and columns, and relationships between tables are represented through keys. The point is not only to store data, but to keep it organized, queryable, and consistent.
Normalization is the process of reducing duplicate data and improving integrity by splitting data into better table structures. First normal form keeps column values atomic. Second normal form removes partial dependency. Third normal form removes transitive dependency. In practice, normalization reduces update, insert, and delete anomalies.
Stored procedures are reusable SQL routines stored inside the database. They can hide complex INSERT or UPDATE logic, standardize repeated transaction flows, and give applications a narrower call surface. The tradeoff is traceability: if too much business logic moves into procedures, debugging across application code and database code becomes harder.
Triggers run automatically when table or database events happen. They can be useful for audit logs or related-table updates, but they also create hidden side effects. A trigger failure can roll back the original statement, so triggers should be used carefully and documented clearly.
Views present the result of a query as if it were a table. They can expose only the columns a user needs or hide complex joins behind a simpler interface. Deeply nested views, however, can make the real query plan difficult to understand.
A transaction groups multiple operations into one logical unit of work. SQL Server transactions are usually explained through ACID: atomicity, consistency, isolation, and durability. This is why production T-SQL often combines BEGIN TRAN, COMMIT, ROLLBACK, and error handling.
Locks protect data while transactions read or modify it. Blocking happens when one transaction waits for another transaction's lock. Blocking can be normal, but long blocking chains are operational problems. A deadlock happens when transactions wait on each other in a cycle, and SQL Server resolves it by choosing a victim transaction to roll back.
Indexes are separate structures that help SQL Server find rows faster. A clustered index defines the table's physical row order through a B-tree. A nonclustered index stores key values and row locators separately. Indexes can improve reads, but every extra index adds maintenance cost to inserts, updates, and deletes.
The practical way to prepare for DBA questions is to explain the operational tradeoff behind each feature, not only the definition.
Korean notes
예전 Velog에 정리해둔 DBA 질문 노트를 다시 읽어보면, 답을 외우는 것보다 개념 사이의 연결을 잡는 게 더 중요했다. RDBMS, 정규화, stored procedure, trigger, view, transaction, index, lock은 따로 떨어진 주제가 아니라 SQL Server를 운영할 때 계속 같이 등장한다.
RDBMS란?
RDBMS는 Relational Database Management System의 약자다. 관계형 데이터베이스를 만들고, 수정하고, 관리하기 위한 소프트웨어다.
핵심은 데이터를 마구 쌓아두는 것이 아니라 규칙적인 2차원 테이블 형태로 표현한다는 점이다. 테이블은 row와 column으로 구성되고, table 사이의 관계를 key로 표현한다.
정규화란?
정규화는 중복된 데이터를 줄이고 데이터 무결성을 높이기 위해 table 구조를 나누는 과정이다. 쉽게 말하면 중복된 데이터를 찢어내는 것에 가깝다.
1정규형은 column이 원자값을 갖도록 table을 구성하는 것이다. 2정규형은 부분 함수 종속을 제거하는 것이고, 3정규형은 이행적 종속을 제거하는 것이다.
정규화를 하는 이유는 update anomaly, insert anomaly, delete anomaly를 줄이기 위해서다. 모든 데이터를 한 table에 몰아넣으면 처음에는 편하지만, 데이터가 커질수록 수정과 검증이 어려워진다.
Stored procedure
Stored procedure는 일련의 SQL을 DB 서버 안에 미리 저장해두고 하나의 함수처럼 실행하는 방식이다.
장점은 다음과 같다.
- 복잡한 SQL을 재사용할 수 있다.
- 보안상 직접 노출하면 안 되는
INSERT,UPDATE로직을 감출 수 있다. - application에서는 procedure 호출만 하도록 만들 수 있다.
- 배치성 작업이나 반복되는 transaction 로직을 묶기 좋다.
하지만 procedure가 항상 좋은 것은 아니다. 로직이 DB 안에 숨어버리면 application 코드와 함께 추적하기 어려워질 수 있고, 에러 원인을 찾기 힘들 수 있다.
Trigger
Trigger는 특정 table이나 database event가 발생했을 때 자동으로 실행되는 로직이다.
예를 들어 UPDATE 이후에 감사 로그를 남기거나, 관련 table을 함께 갱신해야 할 때 사용할 수 있다. 하지만 trigger는 눈에 잘 보이지 않는 side effect를 만들기 쉽다.
특히 trigger 내부에서 에러가 발생하면 원래 실행한 SQL까지 rollback될 수 있다. 그래서 trigger를 쓰려면 DB 구조와 transaction 흐름을 정확히 알고 있어야 한다.
View
View는 query 결과를 table처럼 보여주는 가상의 table이다. 실제 데이터를 별도로 저장한다기보다 자주 쓰는 SELECT 문을 이름 붙여두는 것에 가깝다.
사용자에게 필요한 column만 보여주거나 복잡한 join을 감추는 데 사용할 수 있다. 하지만 view를 너무 깊게 중첩하면 실제 실행되는 query를 파악하기 어려워질 수 있다.
Transaction
Transaction은 여러 작업을 하나의 논리적 작업 단위로 묶는 것이다. 대표적인 성질은 ACID다.
- Atomicity: 모두 성공하거나 모두 실패해야 한다.
- Consistency: transaction 전후로 데이터는 일관된 상태여야 한다.
- Isolation: 동시에 실행되는 transaction끼리 서로 영향을 최소화해야 한다.
- Durability: commit된 결과는 장애가 나도 유지되어야 한다.
SQL Server에서 BEGIN TRAN, COMMIT, ROLLBACK, TRY CATCH를 같이 쓰는 이유가 여기에 있다.
Lock과 blocking
Lock은 transaction이 데이터를 읽거나 변경할 때 다른 transaction과 충돌하지 않도록 잡는 보호 장치다.
Blocking은 한 transaction이 lock을 잡고 있어서 다른 transaction이 기다리는 상태다. Blocking 자체는 정상 동작일 수 있다. 문제는 오래 지속되는 blocking이다.
Deadlock은 서로가 서로의 lock을 기다리면서 아무도 진행하지 못하는 상태다. SQL Server는 deadlock victim을 골라 한쪽 transaction을 rollback한다.
Index
Index는 데이터를 더 빨리 찾기 위한 별도 구조다. 클러스터형 인덱스는 table 자체의 저장 순서와 연결되고, 비클러스터형 인덱스는 별도의 B-tree 구조로 key와 row locator를 가진다.
중요한 것은 index가 많다고 무조건 좋은 게 아니라는 점이다. SELECT에는 도움이 될 수 있지만, INSERT, UPDATE, DELETE 때는 index도 같이 관리해야 하므로 비용이 생긴다.
정리
DBA 기본 질문은 각각 따로 외우기보다 운영 관점에서 연결해서 이해하는 게 좋다.
- RDBMS는 table과 관계를 기반으로 데이터를 관리한다.
- 정규화는 중복을 줄이고 무결성을 높인다.
- procedure와 trigger는 DB 내부 로직을 만들지만 추적 비용도 생긴다.
- transaction은 ACID를 지키기 위한 작업 단위다.
- lock, blocking, deadlock은 동시성 제어에서 자연스럽게 따라온다.
- index는 읽기 성능을 높일 수 있지만 쓰기 비용도 만든다.