ora-1555를 보다가 정리합니다. ^^
1. 간략 용어 및 개념 정리 – block cleanouts : ITL에 ‘C’ marking 하면서 발생하는 일련의 작업. (자세한 내용은 생략) – delayed block cleanouts : block cleanouts를 commit할 때가 아니라, 나중에 select / dml 작업때 수행한다. – delayed logging block cleanouts : commit시에 fast block cleanouts를 수행하고( ‘U’를 marking), ‘U’ mark에 대해서 이후의 dml 작업시 완전한 block cleanouts을 한다. select시에는 하지 않는다.
2. 왜 delayed… 인가? fast commit을 위해서 이렇게 한다. commit시에 바로 block cleanouts를 한다고 가정하자.대량 batch update이후에 commit을 찍을 때, 어떻게 될까? Disk로 내려간 block에 대해서는 다시 physical I/O를 발생시켜 가면서 까지 변경된 모든 block을 buffer cache에 올리고 block cleanouts를 해야한다. commit 작업이 몇 시간이 될 수도 있다.
3. delayed_logging_block_cleanouts = true (7.3이상 부터 적용) 일 때의 mechanism. commit시에 buffer cache에 있는 block에 대해서만fast block cleanout 을 한다. fast block cleanout 시 block cleanout에 비해 훨씬 적은 일을 한다. 따라서 상대적으로 cost가 매우 적다.
fast block cleanout> – the ITL entry’s flag is set to U – the Lck count is left as it is – the fsc is left in place (in this case 0 because no space has been freed) – the commit SCN wrap number is not reported.
Disk로 내려간 block에 대해서는 delayed block cleanouts mechanism이 적용된다. (즉, select / dml 에 의해 block cleanouts 이 일어난다.)
fast block cleanout (‘U’ marking) 이 된것은 이후에 “select”가 아니라, “dml”에 의해 완전한 block cleanout이 일어난다.(‘C’ marking)
장점1 : dml수행시 block cleanout이 발생하므로 dml에 의한 redo record에 piggyback된다. 즉, select시쓸데 없이 cleanout redo records가 발생하지 않는다. 장점2 : select시 block cleanout에 의한 block update가 발생하지 않으므로, OPS mode일 때, ping을 많이 줄여준다.
4. ora-1555 after bulk update. bulk update시에는 많은 update된 block들이 disk로 내려가게 된다. 따라서 delayed block cleanouts mechanism 이 적용된다.
따라서, bulk update를 하고, 야간에 해당 table을 하나의 프로그램에서만 long-run query를 할 때에도 다른 table들에 대한 dml들이 많이 발생하고 있으면, bulk update시 사용했던 rollback segment의 transaction slot이 overwrite되고 결국 rollback segment의 lowest scn이 query시작시의 read-consistent scn보다 더 크게 된다. delayed_logging_block_cleanouts = true 에 의해 ‘U’ marking이 된 것은 당시의 scn(정확히는 wrap#)이 있기 때문에 query시작전에 commit이 되었다는 것을 알 수 있다. 그러나, commit전에 disk로 내려갔던 block들은 delayed_block_cleanouts 메카니즘을 따르기 때문에 이러한 정보가 없다. 따라서, commit이 query시작전인지 아닌지를 알 길이 없어진다. 따라서, ora-1555를 만나게 된다. 이러한 이유로 bulk update직후, 바로 full scan을 미리 해서 block cleanout 을 다 시켜버리면 당근 괜찮다. full scan하는 것이 업무중에 부담스럽다면 bulk update후 사용했던 rollback segment를 다른 dml작업이 사용하지 못하게 offline시켜 놓는 것도 한 방법이라고 하겠다. 그리고, bulk update 중간중간에 commit을 할 수 있다면 buffer cache에 올라와 있는 동안에 commit이 되므로 delayed_logging_block_cleanout의 mechanism을 따라 ‘U’를 marking하게 할 수 있다.
5. ‘CU’가 찍혀있는 경우 : ‘U’ marking이 되어 있는 ITL에 대해서 완전한 block cleanout을 하러 갔을 때, transaction slot이 overwrite 되었을 경우입니다.
Reference Note ) Note 39019.1 Init.ora Parameter “DELAYED_LOGGING_BLOCK_CLEANOUTS” Reference Note Note 46145.1 Case Study of Delayed Logging Block Cleanout with Dumps Note 45895.1 ORA-01555 “Snapshot too old” in Very Large Databases
コメント