오라클이랑 인텔이랑 투닥투닥 하면서 싸워서 낸 결론은 DBMS의 정합성을 위해서는 MVCC미만잡이라는 결과였고


이는 오라클이 혼자서 다해처먹는 몇년전 시장의 근거가 됨



MVCC라는건 트랜잭션끼리의 정합성을 관리하기위한 이론 중 하나인데


멀티 버전 뭐시기 뭐시기였던거 같은데 어쨌든 기조는 실제 데이터와 다른 여러개의 버전을 만들어서 시점을 관리한다는 것임(스냅샷)


오라클은 아마 이 버전을 LSN이던가 뭐 그런 명칭으로 관리함. 이를 다른 이름으로 DB내부에서의 시간이라 표현하기도 함



DBMS의 스냅샷이 임시로 저장되는 곳은 UNDO 테이블스페이스이며 COMMIT을 안하게 되면.. 얘가 COMMIT 하기 이전 시점을 계속해서 보존해야 하므로 UNDO를 계속해서 쌓아야 됨.. DML이 발생할 때마다... 실제로 반영되어야 할 데이터와 실제 데이터간의 간격을 LSN 갭(이라고 오라클에서 부르는지 확실하진 않음. 일단 우리 제품은 그래)이라 하며 이 갭이 늘어나면 늘어날수록 DB는 십창이 되기 시작함...성능이 좆병신이 된다던가...근데 사실 이 갭은 DML만 포함되는 것은 아니고 SELECT도 커서 열고 작업하는게 자꾸 지연되고 안닫으면 그렇게 될수잇어. 이쪽은 UNDO는 안쌓이지만 이것저것 부작용은 생김.


이윽고 UNDO가 꽉차게 되면 그때부터 모든 세션의 DML은 행이 걸리거나 DML이 팅겨나옴. 좆되겠죠?


이건 걍 MVCC이론을 사용하는 사실상 대부분의 RDBMS는 동일한 취약점을 가지고 있고 보통은 프로퍼티 같은 거 조절해서 아씹 이새끼 COMMIT ROLLBACK 다안하고 존나개기네 꺼지셈 하면서 SESSION TIMEOUT을 걸어놓으므로 실운영에서 이런경우 발생할일은 잘업다.


물론 AP로직상 그렇게 될 경우도 있고 단순하게 처리량이 밀려서 이렇게 될순 있어서 UNDO를 넉넉하게 잡아서 손해볼 일은 없음.


메모리 DB는 심지어 UNDO도 메모리에 대다수 올려서 관리하므로 더 좆될 수 있음.



이 UNDO FULL 상황이 궁금하면 DB암거나 켜고 UNDO 존나짝게 잡은다음에 커밋 없이 INSERT 벌크로 존나 쑤셔넣어보면 됨.


물론 실제로 세션마다 어느정도 할당하는 UNDO RELATION이란 놈이 있어서 전부 다 행이 걸리진 않지만 이놈도 좀만 쓰면 UNDO FULL 나면서 병신 되는건 매한가지