그 DBA가 누구야?

내가 한창 신입때 제조업 전산부서에 있을때 항상 듣던말이 있다.

??? : DeadLock이예요! lock 걸렸어요!
부장 : 빨리 고쳐 이 XXX야!!!!
(우당탕탕-)

그땐 이게 무슨 소린지 몰라서 ㅇㅅㅇ 했지만 대충 눈치로 알아보면 공정MES에서 여러 섹션에서 같은 DB에 트랜잭션을 하려고할때 DeadLock이 걸리게 되는건데 이게 공정이 실시간으로 계속 돌아가는거라 얼른 수정하지않으면 계속 데이터를 못넣으니까 얼른 고쳐야되겠지?

그때는 MS-SQL을 쓰고있었고 난 아직 신입이였기때문에 Lock을 푸는 건 항상 '그 대리'의 몫이였는데
'그 대리'에게 DB에 관하여 배울때마다 이 'DBA와 춤을'을 적고자 한다
아, '그 대리'는 지금 게임회사로 이직해서 열일을 하고계신다

난 SQL만 짤 줄 알지 Lock 같은거 몰라

대충 Lock이란 트랜잭션이 동시에 이루어지면 걸리는거- 라고 생각하고있었는데,
언제부턴가 기업의 기술블로그를 염탐하고있을때 Lock이라는 주제로 다룬걸 보았다.
그게 PostgreSQL이였는데,
MS-SQL만 8년 외길인생 DBA에게 PostgreSQL에서의 Lock과 MS-SQL의 Lock 차이를 물어보았다.
결국 비슷하다- 라는 얘긴데
Lock이 어떨때 일어나는지 개념이 없는 나에게
갑자기 transaction lock table(?)을 보여주며 알려주기 시작했다.
(원래 즉흥 스터디는 갑자기 나오는 게 제맛)

이 표를 참고하여 설명하겠다.
출처 : https://docs.microsoft.com/ko-kr/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver15

대충 DB 구조가 이렇다고 가정할때,
A와 B 두개의 섹션에서 특정 한 Row를 delete 하려고 한다.
Row의 상위 개념은 IX가 되고, Row단은 X가 된다고 할때
이 표를 보자,

IX와 IX 끼리는 No Conflict 충돌하지 않으므로, 통과
X와 X끼리는 Conflict 충돌, 곧 Lock

이런식으로 판단하면 된다고 한다.
다만, 데이터베이스를 무엇을 쓰냐에 따라 다를수도 있다고한다.

Read uncommitted와 Read committed

Read Uncommitted는 말 그대로 commit되기 전의 데이터를 읽을 수 있다는 것이고
(Django에 save(commit=False)한 데이터도 읽을 수 있지않을까?)
Read Committed는 commit된 데이터만 읽는다는 것이다.

Django 공식문서에서 Read Committed Setting
1. PostgreSQL : https://docs.djangoproject.com/en/3.0/ref/databases/#optimizing-postgresql-s-configuration
2. MySQL : https://docs.djangoproject.com/en/3.0/ref/databases/#mysql-isolation-level