Oracle 의 Rollback Segments 와 Undo Segments Getting the most out of MetaLink 김재연, 권지영, 김주연 한국오라클 ( 주 ) 제품지원실 본세미나에서는 Oracle의 Rollback segments 와 Undo segments의비교및관리방법및튜닝방법에대해서알아봅니다. 또한손상시의진단및복구방법에대한내용을소개하도록하겠습니다. 그럼 "ORACLE 의 " 세미나를시작하겠습니다.
목차 개요 Rollback 관리방안및튜닝기법 Undo 관리방안및튜닝기법 손상진단및복구방법 본세미나에서진행할내용은다음과같습니다. 먼저 Rollback Segment와 Undo Segment의개요및비교를하겠고, Rollback Segment 의관리방안및튜닝기법과 Undo Segment의관리방안및튜닝기법에대해말씀드리며마지막으로손상의진단및복구방법에대해간략히설명드리겠습니다.
ORACLE 의 개요 1. Rollback / Undo 의목적 2. Rollback / Undo 간의관계 3. Rollback / Undo 의종류 4. 트랜잭션과 Rollback / Undo Rollback 관리방안및튜닝기법 Undo 관리방안및튜닝기법 손상진단및복구방법 Rollback segment 와 undo segment 의개요부분에서는다음의내용을설명합니다. 1.Rollback / Undo의목적 2.Rollback / Undo 간의관계 3.Rollback / Undo의종류 4. 트랜잭션과 Rollback / Undo
1. Rollback / Undo 의목적 1 Transaction Rollback Set Transaction Read Write Name D_TX ; Insert into Dept values (50, R&D, Seoul ); Rollback; 2 Read Consistency Session A (3) Select * from Dept; [ ] (5) Select * from Dept; [ 50, R&D, DEPT ] Session B (1) Insert Into Dept (50, R&D, DEPT ); (2) Select * from Dept; [ 50, R&D, DEPT ] (4) Commit; 3 Transaction Recovery Shutdown abort; Startup; (1) Roll Forward ( 리두로그 ) (2) Roll Back (Rollback) 1. Rollback / Undo 의목적 Rollback segments 는 Transaction 에의해 data 가변경될경우변경전의 before image 를저장하는데사용됩니다 Rollback segments 사용목적은 Transaction rollback, 읽기일관성유지 (Read consistency), Transaction recovery 를위해존재합니다. Transaction rollback이란 oracle서버에서 rollback segment에저장된값을이용해원래의값으로복원됨을말합니다. Transaction rollback 이되는경우는user 에의해강제rollback command를내리거나 transaction 비정상종료에따라 PMON에의해자동rollback 이처리되는경우입니다. Read consistency 는 transaction 이진행되는동안 database 의다른사용자는이 consistent read 에의해 commit 되지않은변경사항을볼수없으며, 또한 rollback segment 에있는이전값은주어진명령문에대한일관된이미지를제공하는데사용됨을의미합니다. Transaction recovery는 transaction이진행되는동안instance가실패한경우 database가다시열릴때commit 되지않은사항은 rollback 되어야하는데이때 rollback segment정보가사용됩니다. Rollback segment의변경사항은또한리두로그파일로보호되므로복구가가능합니다.
2. Rollback 세그먼트 / Undo 간의관계 1 Rollback 과 Undo 는기본적으로는동의어이다. Rollback = Undo Oracle 9i 이전버전 Oracle 9i 이후버전 2 관리방식에있어서 9i 이후버전에서자동관리모드와수동관리모드를선택할수있는기능이추가되었다. 또한트랜잭션처리를위한알고리즘이개선되었다. 8i Rollback < 9i Undo 수동관리모드 수동, 자동관리모드제공알고리즘개선 2. Rollback 세그먼트 /Undo 간의관계 Rollback과 Undo는기본적으로는동의어입니다. Oracle 9i이전엔주로 rollback segment라는용어를사용했습니다. 하지만 oracle9i부터는 undo segment라는용어를사용합니다. 관리방식도 Oracle 9i 이상에서 Undo 데이타의관리를 Oracle 서버가자동으로관리하는자동관리 (automatic Undo Management) 방식을사용합니다. 즉, Undo 세그먼트의생성, 할당및튜닝을 Oracle 서버가관리하므로 Undo 세그먼트관리가단순화되었습니다. DBA는더이상몇개의 Rollback 세그먼트를가질것이지, Rollback의크기는어떻게할것인지, 트랜잭션에따라각각의 Rollback 세그먼트에어떻게할당할것인지를결정할필요가없습니다. 또한 Rollback 세그먼트의각각의속성을고려하실필요가없게된것입니다. Oracle9i 이후버젼에서는자동관리모드나수동관리모드중한방식을선택할수있습니다. 수동관리모드는 oracle9i 이전에사용하던 rollback segment 를말하는것입니다.
3. Rollback / Undo 의종류 Rollback / Undo System Non-System Deferred 시스템테이블스페이스에존재하는객체에사용 지정된 Undo 테이블스페이스에서자동생성관리됨 Auto Mode Private Manual Mode Public 테이블스페이스를 offline immediate 명령으로 offline 시켰거나 recovery 가진행중일때 하나의인스턴스에만독점적으로사용가능 다중인스턴스환경에서어떤인스턴스라도사용가능 (OPS 또는 RAC 환경 ) 3. Rollback/Undo 의종류 Rollback segments 유형은 System/Non-system/Deferred rollback segments 의세가지유형이있습니다. SYSTEM rollback segments 는 database 생성시 SYSTEM tablespace 에자동생성되며 SYSTEM tablespace 내포함된 object 에변경된부분을기록하는데사용되고 Non-SYSTEM rollback segments 는 Private 과 OPS 에서사용되는 Public 의두가지유형이있습니다. Deferred rollback segments 는 immediate option 을사용하여 tablespace offline 상태로변경할경우생성되며, tablespace 를 online 으로재설정할때 transaction rollback 을위해사용되어집니다. Deferred rollback segments 는 oracle 내부적으로관리되어지므로 manual 하게 user 에의해작업할수없으며필요하지않을때자동삭제됩니다. 자동관리방식에선 oracle 이자동으로생성관리합니다.
4. 트랜잭션과 Rollback / Undo (Begin Transaction) Begin Transaction 1. 트랜잭션에서사용할 Rollback / Undo Segment 바인딩. 2. 트랜잭션테이블의슬롯할당 3. Rollback/Undo 블록할당 Change Data Commit Rollback 4. 트랜잭션과 Rollback/Undo 트랜잭션의시작은트랜잭션의첫번째 DML 이수행되면서시작됩니다.. 이것을 Begin Transaction 이라고하며기본적으로는트랜잭션에의해발생하는변동사항은수동관리모드 (RBU) 이거나자동관리모드 (AUM) 이거나동일하나, transaction binding 과 undo segment extension 측면에서차이가있습니다.. 수동관리모드 (RBU) 에선트랜잭션을균등하게배분하며이때 LRU (Least Recently Used) 또는 round robin 방식이사용됩니다. < 참고 > 예를들어, 4개의 rollback segment (rb1, rb2, rb3, and rb4) 가있다면, 첫번째트랜잭션은 system RBU가아닌일반 RBU 이면서, 인스턴스구동후온라인상태가된, 첫번째 RBU에할당됩니다. 이예에서는rb1이라고하자. 두번째트랜잭션은다음 RBU, 예를들어 rb2, 에할당되고이후트랜잭션들도마찬가지방식으로 RBU를할당받게됩니다. 다섯번째트랜잭션은가장오래전에액세스된 RBU에할당되게되는데, 예를들어 rb1, rb2가현재트랜잭션에의해사용되고있고, rb3과 rb4가사용되지않고있다면, 다섯번째트랜잭션에는 rb3가할당되게됩니다. 한편, 처음 4개트랜잭션이모두 active 상태이라면, 다섯번째트랜잭션에는 rb1이할당되게됩니다. Rollback segment 가할당된후에는, 트랜잭션테이블슬롯이할당됩니다. 트랜잭션테이블슬롯가운데, 가장오래전에 commit 된트랜잭션테이블이재사용됩니다. Transaction id(xid) 가트랜잭션에할당되며, 할당된 Transaction id (XID) 로 exclusive TX lock 을획득하게됩니다.
자동관리모드 (AUM) 에서트랜잭션 bind 알고리즘에서는, 우선 undo segment 당하나의트랜잭션을 binding 시키는것을시도합니다. 이과정에서 active transaction 과 binding 되지않은온라인트랜잭션테이블을선택하게됩니다. 만약그와같은트랜잭션테이블을찾을수없다면, 시스템에서는현재사용중인 undo 테이블스페이스내의또다른트랜잭션테이블을 online 시키는것을시도합니다. 만약앞의두가지모두실패한다면, 새로운 undo segment ( 트랜잭션테이블 ) 을생성한후 online 시킵니다. 만약위과정이모두실패할경우 ( 예를들어 undo 테이블스페이스가 full 상태라 undo segment 를생성할수없다면 ) 오라클 8.1 와같은방식으로트랜잭션 binding 을재시도합니다. (least used 트랜잭션테이블을찾아할당받는방식 ) 이와같은접근방법은하나의트랜잭션테이블이대부분하나의트랜잭션에서만사용되도록합니다. 또한트랜잭션테이블을새로생성시키고온라인시키는것은시스템에의해자동적으로실행되므로, 사용자입장에서는위처리과정이 transparent 합니다.
4. 트랜잭션과 Rollback / Undo (Data Change) Begin Transaction Change Data 1. 데이터블록내의가용 ITL 검색 2. 변경하고자하는 row에대한lock 획득 3. 데이터블럭내의변경사항을기록할리두정보생성 4. Undo 정보생성 1 데이터블록에대한변경에대한역작업 (inverse operation) 2 RBS / Undo 블록에대한변경내역 3 ( 필요할경우 ) RBS / Undo 헤더에대한변경 5. 리두레코드생성후, 변경내역을데이터블록에반영 Commit Rollback Redo ITL 검색 Lock 획득 Undo 4. 트랜잭션올백 /Undo (data change) Data 변경시는내부적으로다음의단계를수행하게됩니다. 1. 먼저데이터블록내의가용 ITL 을검색합니다. 2. 변경하고자하는 row 에대한 lock 을획득합니다. 3. 데이터블록내의변경사항을기록할리두정보를생성하고 4. Undo 정보를생성합니다. Undo 정보에는 1 데이터블록에대한변경에대한역작업 (inverse operation) 2 Rollback / Undo 블록에대한변경내역 3 ( 필요할경우 ) Rollback / Undo 헤더에대한변경내역이포함됩니다. 5. 리두레코드생성후, 변경내역을데이터블록에반영합니다.
4. 트랜잭션과 Rollback / Undo (Commit) Begin Transaction 1. SCN 값검색 2. 트랜잭션테이블의내용갱신 3. Current undo block 을 free block pool로반납 4. Redo Log 버퍼에 commit record 생성 5. Redo Log 버퍼의내용을디스크에기록 (Durability 보장 ) 6. Row 와 Table에대한lock 해제 Change Data Commit Rollback 4. 트랜잭션 Rollback/Undo(commit) 변경된 data를 commit하는경우엔내부적으로다음과같은작업이수행됩니다. 먼저 SCN 값검색을합니다. 그리고트랜잭션테이블의내용을갱신하며경우에따라서 Current undo block 을 free block pool로반납합니다. Redo Log 버퍼에 commit record 생성하게되는데여기서 scn값을사용하게되므로처음에 scn값을검색하게됩니다. Redo Log 버퍼의내용을디스크에기록하게되는데이는 Durability 보장을위함입니다. 마지막으로 Row 와 Table에대한 lock 해제합니다. < 참고자료 > 다음두가지경우에대해 current extent 내의 undo block을 free block pool에반납한다 : 1. 트랜잭션이 commit 되고, When the transaction is committed and if: -Free space 공간이부족할때 ( 부족한공간이 >= 400 byte 이상 ). -Current extent에포함된블록이 active part에속할때 [StartDBA, CurrentDBA]. 2. RBS의확장이실패할경우, current extent의마지막 block이 free block pool에반납되어야한다. 참고로, 트랜잭션은다음과같은경우 commit 된다 : 사용자가 COMMIT 을수행 사용자가 DDL 구문을수행 사용자가서버와의연결을끊을때
4. 트랜잭션과 Rollback / Undo (Rollback) Begin Transaction 1. Undo Record Chain 의 Header 찾기 (Linked List 의 Head) 위치는트랜잭션테이블에기록되어있음. 2. Undo Record 의 user undo 부분에기록된데이터변경작업을역순으로수행. Change Data Commit Rollback 4. 트랜잭션 Rollback/Undo (rollback) 트랜잭션 rollback이시작될때는먼저 undo record chain의 head를찾는작업이수행됩니다. Head DBA는 transaction table의 transaction descriptor에서찾을수있습니다. Chain내의각각의 link는 undo record를가리키며, undo record의 user undo 부분은 rollback시적용되어야하는부분입니다. Undo Record의 user undo 부분에기록된데이터변경작업을역순으로수행합니다. < 참조 > Undo를적용할때마다, 통계수치인 Rollback changes - undo records applied 값이증가된다. <Notes> 오라클서버는, commit 되지않은트랜젝션전체가 rollback 될수있는기능을제공하며, savepoint 이후 commit 되지않는변경사항에대해서만, rollback 을시킬수있는기능역시제공한다.
ORACLE 의 개요 Rollback 관리방안및튜닝기법 1. 튜닝목적 2. 세그먼트개수결정 3. OPTIMAL 값결정 4. Extent 개수와크기결정 5. Statspack Report Undo 관리방안및튜닝기법 손상진단및복구방법 Rollback 관리방안및튜닝기법에선다음의사항을설명합니다. 1. 튜닝목적 2. 세그먼트개수결정 3. OPTIMAL 값결정 4. Extent 개수와크기결정 5. Statspack Report를통한튜닝방법
1. 튜닝목적 1 목적 1. 트랜잭션에서 Rollback세그먼트를획득하기위해 대기하는시간을최소화. 2. 평상시 Rollback 세그먼트의확장발생을최소화. 3. 적은양의 Rollback을사용 ( 지침 ) 4. 트랜잭션에서 Rollback 공간부족으로인한에러발생방지 5. SQL에서항상 read-consistent한데이터조회가능 1. 튜닝목적 Rollback segment 의튜닝목적은다음과같습니다. 트랜잭션에서 Rollback세그먼트를획득하기위해대기하는시간을최소화 평상시 Rollback 세그먼트의확장발생을최소화. 적은양의Rollback을사용 트랜잭션에서 Rollback 공간부족으로인한에러발생방지 SQL에서항상 read-consistent한데이터조회가능하게함을목적으로합니다.
2. 세그먼트의개수결정 1 OLTP 다수의작은 Rollback 세그먼트유지 Rollback 세그먼트당 4개의트랜잭션할당을권고 * Rollback 세그먼트당최대 transaction table slot 수만큼사용가능 2 BATCH 소수의큰 Rollback 세그먼트유지트랜잭션당한개의 Rollback 세그먼트할당 SQL>SET TRANSACTION USE ROLLBACK SEGMENT large_rbs; Rollback Segment 개수설정을위한튜닝포인트 RBS_HEADER_WAIT_RATIO 값을 0.01 이하로유지 select rn.name, (rs.waits/rs.gets) rbs_header_wait_ratio from v$rollstat rs, v$rollname rn where rs.usn = rn.usn order by 1; 2. 세그먼트개수결정 Rollback segments 개수와 size 가충분한지판단기준은 transaction activity 에직접적인영향을받습니다. 일반적인경우주로일어나는 transaction activity 에근거하여 size 와개수를결정해야하고 Batch job 수행과같은경우큰 transaction 을위해별도의 rollback segment를할당합니다. OLTP 는빈번한 transaction update 로인해 rollback segment header 의 contention 문제가발생할수있습니다. 그러므로 size가크지않은여러개의 rollback segment 를생성하는것이좋으며, 대략 4개의 transaction 당한개의 rollback segment를설정하도록합니다. Rollback 세그먼트를동시에사용할수있는최대트랜잭션개수는 rollback segment header의 transaction table의 slot수에의하는데이는오라클블럭의크기와버젼에따라다르며 Oracle8 기준 2K block size를사용하는경우 21개입니다. Batch 는각concurrent job 당size 가큰한개의rollback 을지정하는것이일반적입니다. Rollback segment개수설정을위해선다음과같이 rollback segment 에대한 contention 을조회하여튜닝을통한개수조정이필요합니다.
방법은화면상의 select 문장을참조하여주시기바랍니다. $ sqlplus system/manager SQL> select rn.name, (rs.waits/rs.gets) rbs_header_wait_ratio from v$rollstat rs, v$rollname rn where rs.usn = rn.usn order by 1; 위 query 에의해조회된 rbs_header_wait_ratio 가 0.01 보다크면, rollback segment contention 방지를위해개수를추가합니다. < 참고자료 > Rollback Segment Header Contention 발생은 V$ROLLSTAT 의 WAITS, V$WAITSTAT 의 UNDO HEADER, V$SYSTEM_EVENT 의 Undo Segment TX Slot event 발생을통해 header contention 을의심해볼수있습니다. 다음 query 에서 v$rollstat view 의 waits 와 gets 를조회하여 Ratio 가 1% 미만을유지하도록하고 waits/gets 의결과가 0 에가깝도록조정하시기바랍니다. SVRMGR> select class, count from v$waitstat where class in ('undo header','undo block', 'system undo header', 'system undo block'); 만약 1% 이상을초과하는경우 rollback segment 크기를현재보다크게하거나새롭게생성 / 추가하시기바랍니다.
3. OPTIMAL 값결정 1 Rule of Thumb 일반적으로 20 30개 EXTENTS SIZE가적절. Optimal Size를 initial/next와같게주면매번shrink가발생하므로부적절 2 적정치계산 사용량이많은시간대에 Rollback 세그먼트평균크기를구하여, OPTIMAL 값으로사용 * OPTIMAL 값이너무적을경우, ORA-1555 발생가능 select initial_extent + next_extent * (extents -1) "RBS SIZE(byte)", extents from dba_segments where segment_type ='ROLLBACK'; 3. Optimal 값결정 rollback segment가할당된 extent 를반납 (deallocate) 하게하려면 optimal값을설정해야합니다. 즉, optimal 에서지정된크기만큼만 rollback segment 를유지하겠다는의미가됩니다. Optimal size 의적정치는 20~30개의 extent size 정도가적당하며 optimal size 를 initial/next 와같게주면 extent 가빈번하게 shrink가일어나므로적합하지않습니다. 화면의 query 를 peak time에여러번수행하여 rollback segment들의평균크기를구하고이것을 optimal 크기로지정하여사용하는것이권장사항입니다. Optimal값이너무작은경우엔 ora-1555 snapshot too old error발생요인이될수있습니다. < 참고 > SQL> select initial_extent + next_extent * (extents -1) "RBS SIZE(byte)", extents from dba_segments where segment_type ='ROLLBACK'; 위 query의평균값 (byte) 을 rollback segment들의 optimal size로사용할수있습니다. 주의 ) optimal 설정을너무적게하거나 shrink 를빈번하게하는경우 ORA-1555 에러발생요인이될수있습니다. 그러므로 ORA-1555 가자주발생되는경우 optimal 을설정하지않거나되도록큰값으로설정하는것이좋습니다.
4. Extent 개수와크기결정 INITIAL OLTP: 128K, 512K, 1M BATCH : 2M,4M, 8M,16M Minextents INITIAL = NEXT = 2 n 20 NEXT INITIAL 값과동일하게지정... 0.50 0.40 0.30 0.20 0.10 OPTIMAL = x 0.00 10 30 사이의값. 테스트결과 20 extents 정도가가장효과적임 Probability of extending 00 10 20 30 Number of extents 4. extent 개수와크기결정 동적인 rollback segments 의 extents 확장으로 space 할당 / 해제가빈번하게일어날경우, 성능저하에영향을미치는요소가되므로이를최소화하는것이권고사항입니다. Extents size는일반적으로 Initial 경우 small transaction 일때 128K,512K,1M 를설정하고large transaction 의경우 2M, 4M, 8M, 16M와같이 2의 N승으로초기설정하시기바랍니다. Next extent 는 Initial 과동일하게설정하도록합니다. ( 만약어느 rollback은 next가 16k이고다른건 32k라면 16k자리를 shrink하거나 drop하는경우 2k자리가 extend가필요하면 16k짜리두개가져다쓰면되는데, 30k로하면 16k짜리하나랑14k가남으니까 2의배수로하면묶어서쓰면딱딱떨어지니까 2의 N승으로, note :69464.1) Minextents는 10~30개의 extents 사이의값을설정하되성능테스트결과 20개의 extents 정도로지정하는것이가장효과적이라고합니다. 화면상의표를보시면 20개의 extents에선거의추가확장이없는것을확인하실수있습니다. < 참고 > Extents 의개수와 size는 transaction 유형에따라달라지는데큰 size 에적은개수로유지하는것보다는작은 size 에개수가많은것이 space 관리차원에서효과적입니다. 예를들어 300m rollback segment 에 100m 짜리 3개의 extent 가존재시 space 추가로 extent 확장이일어나게되면 next extents 100m 가할당되고실제필요한 space보다더큰 extents 가할당되어지게될수있어공간낭비가발생될수있습니다.
반면, 15m 짜리 extent 가 20개존재한다면 next extents 추가시 15m 짜리 extent 가할당되고 space 낭비를줄일수있습니다. 결국일반적인권고사항에따라생성하고 rollback segment의 contention 을확인하여 tuning 후크기및개수를시스템에맞게설정하는것이가장효과적이라볼수있습니다. Rollback Segment Header Contention 발생은 V$ROLLSTAT 의 WAITS, V$WAITSTAT 의 UNDO HEADER, V$SYSTEM_EVENT 의 Undo Segment TX Slot event 발생을통해 header contention 을의심해볼수있습니다. 다음 query 에서 v$rollstat view 의 waits 와 gets 를조회하여 Ratio 가 1% 미만을유지하도록하고 waits/gets 의결과가 0 에가깝도록조정하시기바랍니다. SVRMGR> select class, count from v$waitstat where class in ('undo header','undo block','system undo header', 'system undo block'); 만약 1% 이상을초과하는경우 rollback segment 크기를현재보다크게하거나새롭게생성 / 추가하시기바랍니다.
5. Statspack Report 1 Statspack Report Rollback Segment Stats Rollback Segment Storage * 9i 에서다음두가지항목이추가됨 Undo Segment Summary for DB Undo Segment Stats for DB PCT Waits 값을낮게유지 Trans Table Pct Undo Bytes RBS No Gets Waits Written Wraps Shrinks Extends ------ -------------- ------- --------------- -------- -------- -------- 0 9.0 0.00 0 0 0 0 4 6,838.0 0.18 554,206 0 0 0 5 2,174.0 0.55 292,474 0 0 0 6 4,309.0 0.23 471,992 0 0 0 Avg Active 와 Optimal Size 값조정, 우측예는 Optimal 값이지정되지않음. ->Optimal Size should be larger than Avg Active RBS No Segment Size Avg Active Optimal Size Maximum Size ------ --------------- --------------- --------------- --------------- 0 753,664 0 753,664 4 2,520,743,936 0 2,520,743,936 5 2,109,702,144 0 2,109,702,144 6 528,449,536 0 528,449,536 5. Statspack report Oracle 8.1.6 부터지원되는 STATSPACK Reports 를통해 Rollback /UNDO segment 의두가지정보에대해 tuning을할수있습니다. 1) Rollback Segment Stats 2) Rollback Segment Storage 9i 에서는두가지정보가추가되었습니다. 1) Undo Segment Summary for DB 2) Undo Segment Stats for DB 화면에보이는 report는 STATSPACK 결과입니다. 이중화면상단의표는 Rollback Segment Stats for DB 부분으로화면상에세개의 rollback segment에대해선미소한 contention이있으며 "Pct(percent over the set) Waits" 수치가높으면 rollback segments 증가 / 생성을권장합니다. 화면하단의표는 Rollback Segment Storage for DB 부분으로 Optimal Size 는 Avg Active보다커야합니다. 다음은 optimal size 에대해설정이되어있지않은경우입니다.
5. Statspack Report ( 계속 ) 아래예에서, RBS 1, RBS 9는 Optimal Size에비해Avg Active 값이크므로, 튜닝이필요하며, ORA-1555 ("snapshot too old ) 에러가발생할수도있다. ->Optimal Size should be larger than Avg Active RBS No Segment Size Avg Active Optimal Size Maximum Size ------ --------------- --------------- --------------- --------------- 0 5,087,232 0 5,087,232 1 52,420,608 ########### 52,428,800 335,536,128 2 52,420,608 10,551,688 52,428,800 283,107,328 3 52,420,608 10,621,742 52,428,800 283,107,328 4 52,420,608 10,736,056 52,428,800 283,107,328 5 52,420,608 17,861,266 52,428,800 325,050,368 6 52,420,608 19,579,373 52,428,800 335,536,128 7 52,420,608 11,571,513 52,428,800 283,107,328 8 52,420,608 44,140,215 52,428,800 335,536,128 9 52,420,608 65,045,643 52,428,800 325,050,368 OPTIMAL SIZE 를크게지정하도록조치 다음은 optimal size 설정이되어있는경우이며 RBS 1번과 9번의경우 optimal size 보다 Avg Active가큰경우입니다. 즉, consistent problem(ora-1555) 문제를야기시킬수있는경우로 optimal size를크게설정해야합니다. Ora-1555 error가빈번하게발생하는경우 optimal 를크게지정하거나아예지정하지않아서 shrink 를하지않도록해야합니다.
ORACLE 의 개요 Rollback 관리방안및튜닝기법 Undo 관리방안및튜닝기법 1. 환경구성 2. Undo 모니터를위한뷰 3. Undo 테이블스페이스크기결정 손상진단및복구방법 Undo 관리방안및튜닝기법에서는환경구성과 Undo 모니터를위한뷰를소개합니다. 그리고자동관리모드에서 Undo 테이블스페이스크기결정방법에대해서설명합니다.
1. 환경구성 1 초기화파라미터 UNDO_MANAGEMENT : 자동모드를사용할지수동모드를사용할지여부를결정 UNDO_TABLESPACE : 사용할특정 UNDO 테이블스페이스를지정 * 최소한하나의 UNDO 테이블스페이스생성이필요함 UNDO_RETENTION : Undo 데이터보관기간지정 UNDO_SUPPRESS_ERRORS : 수동제어오류처리방식지정 UNDO_MANAGEMENT=AUTO UNDO_TABLESPACE=UNDOTBS UNDO_RETENTION=900 UNDO_SUPPRESS_ERRORS = TRUE 1. 환경구성 환경구성을위한초기화파라미터는다음과같습니다. UNDO_MANAGEMENT 파라미터는테이타베이스의 Undo 모드를결정합니다. 이파라미터는 AUTO 또는 MANUAL 값중하나로설정할수있으며초기화파라미터파일에서설정해야합니다. ( 데이터베이스가운영중에는 UNDO_MANAGEMENT 를동적으로변경할수없습니다. AUTO로설정하게되면데이터베이스는자동 Undo 관리모드로설정되며 undo 테이블스테이스가필요합니다. ) UNDO_TABLESPACE 파라미터는사용할 undo 테이블스페이스를지정합니다. 이파라미터는초기화파일에서설정하거나데이터베이스의운영중에도 ALTER SYSYTEM 명령을사용하여동적으로변경할수있습니다. UNDO_RETENTION 파라미터는일관성읽기를위해제공되는 Undo 데이타의보유기간을결정합니다. 초기화파일에서설정하거나, ALTER SYSTEM 명령을사용하여동적으로수정할수있습니다. 이 parameter는초단위로지정됩니다. 기본값은 900초이며, 이는 Undo 데이타를 15분동안보유합니다.
UNDO_RETENTION을설정한후에도 UNDO 테이블스페이스의크기가너무작으면지정한시간동안 Undo 데이타가보유되지않습니다. UNDO_RETENTION 파라미터는현재 Undo 테이블스페이스에 UNDO_RETENTION 기간동안발생하는모든트랜잭션을수용할수있을만큼충분한커야합니다. ( 활성트랜잭션에 Undo 영역이필요한데 Undo 테이블스페이스에사용가능한공간이없으면데이터베이스가 UNDO_RETENTION으로인해보유되었던 Undo 영역을재사용합니다. 이경우 ora-1555 SNAPSHOT TOO OLD 오류로인해긴쿼리의경우실패할수있습니다. ) UNDO_SUPPRESS_ERRORS 파라미터를사용하면자동 Undo 관리모드에서수동관리모드작업시에러가발생하는것을방지합니다. 즉, ALTER ROLLBACK SEGMENT ONLINE, SET TRANSACTION USE ROLLBACK SEGMENT 문을수행하면 ORA-30019 에러가발생하는것을방지합니다. ORA-30019: Illegal rollback segment operation in Automatic Undo mode
1. 환경구성 2 Undo 테이블스페이스구성 데이터베이스생성시지정 CREATE DATABASE db01... UNDO TABLESPACE undo1 DATAFILE '/u01/oradata/undoldb01.dbf' SIZE 20M AUTOEXTEND ON 데이터베이스생성후별도생성 CREATE UNDO TABLESPACE undo1 DATAFILE '/u01/oradata/undo1db01.dbf' SIZE 20M; UNDO 테이블스페이스생성 자동 Undo 관리에는 undo 테이블스페이스가필요합니다. undo 테이블스페이스가데이타베이스에두개이상가능하지만, 그중에하나만활성화되어있습니다. UNDO 테이블스페이스를생성하는방법은 CREATE DATABASE문에절을추가하여데이타베이스와함께 undo 테이블스페이스를생성할수있습니다. 또한데이터베이스가생성된후에도 CREATE UNDO TABLESPACE 명령을사용하여 undo 테이블스페이스을생성할수있습니다.
1. 환경구성 3 Undo 테이블스페이스변경 테이블스페이스전환 DBA 는하나의 Undo 테이블스페이스에서다른테이블스페이스로전환할수있다. 인스턴스당하나의 Undo 테이블스페이스만활성 Undo 테이블스페이스로지정될수있다. ALTER SYSTEM 명령을이용하여수행한다. ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS2 Undo 테이블스페이스삭제 UNDO 테이블스페이스가현재임의의인스턴스에서사용되지않는경우에만삭제할수있다. 활성 UNDO 테이블스페이스삭제방법 (1) 새 UNDO 테이블스페이스로전환 (2) 모든현재트랜잭션이완료된후에테이블스페이스삭제 UNDO 테이블스페이스생성 자동 Undo 관리에는 undo 테이블스페이스가필요합니다. undo 테이블스페이스가데이타베이스에두개이상가능하지만, 그중에하나만활성화되어있습니다. UNDO 테이블스페이스를생성하는방법은데이타베이스와함께 undo 테이블스페이스를생성하거나데이터베이스가생성된후에도 CREATE UNDO TABLESPACE 명령을사용하여 undo 테이블스페이스을생성할수있습니다. UNDO 테이블스페이스변경및전환 ALTER SYSTEM 명령을사용하여 undo tablespace를다른 tablespace로변경할수는있습니다. ( 활성 Undo 테이블스페이스에있는 Undo 세그먼트를오프라인상태로변경할수는없습니다.) Undo 테이블스페이스를전환하면새로운트랜잭션은새로지정한 UNDO 테이블스페이스를사용하게됩니다. 하지만모든현재트랜잭션, 즉이미존재하던 UNDO 테이블스페이스에할당된트랜잭션은완료될때까지계속해서기존의 Undo 테이블스페이스를사용합니다. 위와같이 UNDO 테이블스페이스를전환한후, 전환전의 UNDO테이블스페이스를참조하여쿼리를수행하는데일관성있는읽기를제공할수없는경우는 ORA-1555 snapshot too old 오류가발생할수있습니다. UNDO 테이블스페이스삭제는인스턴스에서현재사용되지않을때, 커밋되지않은트랜잭션이포함되어있지않아야가능합니다.
삭제하려는 UNDO 테이블스페이스가데이타베이스의현재 Active한 UNDO 테이블스페이스인경우는먼저새 UNDO 테이블스페이스를설정해야합니다. 만약 UNDO 테이블스페이스가없는경우라면먼저생성한후 ALTER SYSTEM 명령을사용하여현재 UNDO 테이블스페이스를변경합니다. UNDO tablespace를삭제하려면, 테이블스페이스내의모든트랜잭션이완료되어야합니다. Active한트랜잭션이있는지여부를확인하려면,v$rollstat, 의 xacts column을조회합니다. < 참고 > SQL> SELECT a.name,b.status FROM v$rollname a, v$rollstat b WHERE a.name IN (SELECT segment_name FROM dba_segments) AND a.usn = b.usn; NAME STATUS --------- ----------- _SYSSMU4$ PENDING OFFLINE 쿼리결과만약 PENDING OFFLINE 상태의 Undo 세그먼트가존재한다면이 UNDO 세그먼트에는 Active 트랜잭션이아직포함되어있는것입니다. 쿼리결과, 행이반환되지않으면모든트랜잭션이완료된것이며 DROP 명령으로테이블스페이스를삭제할수있습니다. SQL> DROP TABLESPACE UNDOTBS;
2. Undo 모니터를위한뷰 1 V$UNDOSTAT MANUAL 모드와 AUTO 모드둘다에서사용가능. UsedBlks 열은할당된 Undo 블럭수를나타냄. * DBA_UNDO_EXTENTS 는 undo 테이블스페이스에있는각익스텐트에대한커밋시간을보여줌. End- Undo Txn Txn Query Exten SSTooOld Time Blocks Concrcy Total Len Stolen Error ----- ------ ------- ----- ----- ------ -------- 16:07 252 15 151 25 2 0 16:00 752 16 1467 150 0 0 15:50 873 21 1954 45 4 0 15:40 1187 45 3210 633 20 1 15:30 1120 28 2498 1202 5 0 15:20 882 22 2002 55 0 0... Undo 를모니터위한뷰 V$UNDOSTAT 뷰를사용하여 Undo에대한공간할당과사용을모니터합니다. ( 각행은 10분간격으로인스턴스에서수집된통계가저장됩니다. 시간간격은 10분이라고하였지만 10분미만의시간이반환될때도있습니다. ) 이뷰를사용하면현재작업로드에필요한 Undo 공간의크기를예측할수있으며 Undo 사용을튜닝할수있습니다. 이뷰는자동모드와수동모드에서모두사용할수있습니다. 화면의예제에서는 15:30와 15:40 사이에최고 Undo 소비가발생했음을보여줍니다. 이 10분동안소비된 Undo 블록수는 1,187개로, 이는초당 2개정도의블록이소비된것을보여줍니다 (1187/10*60). 또한이기간동안동시에 45개의트랜잭션이실행되어가장높은트랜잭션이수행되었습니다. 가장긴쿼리수행시간은 15:20와 15:30 사이에 1,202 초로가장높습니다. 이외에 DBA_UNDO_EXTENTS 는 undo 테이블스페이스에있는각익스텐트에대한커밋시간을보여줍니다.
3. Undo 테이블스페이스크기결정 크기결정에필요한정보 (UR) UNDO_RETENTION ( 초 ) (UPS) 초당생성되는 Undo 데이터블록수 (DBS) 익스텐트및파일크기에따라달라지는오버헤드 (db_block_size) SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes" FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'), (SELECT (SUM(undoblks)/SUM (((end_time-begin_time)*86400))) AS UPS FROM v$undostat), (SELECT value AS DBS FROM v$parameter WHERE name = 'db_block_size'); 3. UNDO 테이블스페이스크기결정 UNDO 테이블스페이스의크기를조정하려면세가지가필요합니다. 두가지는초기화파일에서얻을수있는 UNDO_RETENTION과 DB_BLOCK_SIZE입니다. 세번째는초당생성되는 Undo block의수를 V$UNDOSTAT에서얻을수있습니다. 다음의노란색글씨로표시된것이초당생성되는 undo block수를알수있는공식입니다. < 참고 > 생성되는전체 block의수를계산하여모니터되는시간 ( 초 ) 으로나눕니다. SQL> SELECT (SUM(undoblks)/SUM (((end_time-begin_time)*86400))) FROM v$undostat ; END_TIME 과 BEGIN_TIME 은 DATE형이기때문에뺄셈을수행하면결과가날짜로표시됩니다. 그러므로날짜를초로변환하려면하루를초로계산한 86400을곱합니다. 이결과로초당 Undo block 수가반환되는것입니다. 이값을 DB_BLOCK_SIZE에정의된데이터베이스 block과같은크기인 Undo block의크기로곱합니다. 다음은필요한바이트수를계산합니다. 화면상의표시된공식에의한결과를가지고 undo tablespace크기를결정할수있습니다. 좋은결과를얻으려면데이타베이스의작업로드가가장많은낮동안에계산하는것이좋습니다.
한문장으로구성하면아래와같습니다. SQL> SELECT (UR * (UPS * DBS)) + (DBS * 24) AS "Bytes" FROM (SELECT value AS UR FROM v$parameter WHERE name = 'undo_retention'), (SELECT (SUM(undoblks)/SUM (((end_time-begin_time)*86400))) AS UPS FROM v$undostat), (SELECT value AS DBS FROM v$parameter WHERE name = 'db_block_size'); Bytes ---------- 19106213 < 참고 > 4) Undo Segment Summary : 9I STATSPACK Report 에추가된정보로 V$UNDOSTAT view 에서도확인가능 -> Undo segment block stats: -> us - unexpired Stolen, ur - unexpired Released, uu - unexpired reused -> es - expired Stolen, er - expired Released, eu - expired reused Undo Undo Num Max Qry Max Tx Snapshot Out of us/ur/uu/ TS# Blocks Trans Len (s) Concurcy Too Old Space es/er/eu ---- -------------- ---------- -------- ---------- -------- ------ ------------ 1 20,284 1,964 8 12 0 0 0/0/0/0/0/0
ORACLE 의 개요 Rollback 관리방안및튜닝기법 Undo 관리방안및튜닝기법 손상진단및복구방법 1. _ 파라미터 2. Rollback 손상으로데이터베이스구동실패시조치 3. 구동중인시스템손상진단및복구방법 4. 에러유형별조치방안 손상진단및복구방법에선다음의사항을설명합니다. 1. _ 파라미터 2. Rollback 손상으로데이터베이스구동실패시조치방법 (startup errors ) 3. 구동중인시스템손상진단및복구방법 (errors after startup) 4. 에러유형별조치방안
1. _ 파라미터 1 유의사항 여기서다루는 _OFFLINE_ROLLBACK_SEGMENTS 와 _CORRUPTED_ROLLBACK_SEGMENTS 파라미터는, 데이터베이스의논리적 corruption을유발시킬수있으며, 오라클로부터공식적으로지원되는내용이아니다. 따라서, 수반되는위험에대해충분히이해하고, 더이상다른조치를취할수없을때적용되어야하는방법이다. 2 _OFFLINE_ROLLBACK_SEGMENTS * 지정된 Rollback 세그먼트에대해 SMON이트랜잭션리커버리를하지않도록지정. * 파라미터에의해지정된 Rollback 세그먼트에대한보호장치가작동하지않음. ( 예 : Rollback세그먼트와관련된 active transaction이존재하더라도drop 가능 ) _ 파라미터 여기서다루는 _OFFLINE_ROLLBACK_SEGMENTS 와 _CORRUPTED_ROLLBACK_SEGMENTS 파라미터는, 데이터베이스의논리적 corruption을유발시킬수있으며, 오라클로부터공식적으로지원되는내용은아니며, 최후의복구방법으로사용하게됩니다. 따라서, 수반되는위험에대해충분히이해하고, 더이상다른조치를취할수없을때적용되어야하는방법입니다. 이러한 _ 파라미터사용시는반드시 oracle엔지니어에의한가이드를따르시길바랍니다. 임의적으로적용후지원을요청하는경우엔추가복구할방법이없을수있습니다. _OFFLINE_ROLLBACK_SEGMENTS 는지정된 Rollback 세그먼트에대해 SMON이트랜잭션리커버리를하지않도록지정합니다. 이파라미터에의해지정된 Rollback 세그먼트에대한보호장치가작동하지않으므로 Rollback세그먼트와관련된 active transaction이존재하더라도 drop이가능합니다. 이는데이타베이스에논리적 corruption을유발하는것입니다.
1. _ 파라미터 ( 계속 ) 3 4 _CORRUPTED_ROLLBACK_SEGMENTS * 지정된 Rollback 세그먼트의헤더에대한액세스 (I/O) 를금지시키고, 해당 Rollback 세그먼트의내용이모두 commit 된것으로간주함. 두파라미터간차이점 항목 _OFFLINE _CORRUPTED 비고 트랜잭션테이블액세스 트랜잭션커밋전 트랜잭션커밋 Lock 이걸린 row 에대한 update 작업 가능 consistent read view 지원 delayed block cleanout 이정상적으로수행됨 실패 불가 commit 되지않은내용도보임 트랜잭션이커밋된것으로간주 실패하지않음 _OFFLINE 상태에서헤더액세스실패시, ORA-376 ( 파일이오프라인상태 ), ORA-1578 ( 블록이깨진경우 ) 발생 _CORRUPTED_ROLLBACK_SEGMENTS는지정된 Rollback 세그먼트의헤더에대한액세스를금지시키고, 해당 Rollback 세그먼트의내용이모두 commit 된것으로간주합니다. _OFFLINE_ROLLBACK_SEGMENTS와 _CORRUPTED_ROLLBACK_SEGMENT의차이점은표와같이정리가가능합니다. _OFFLINE_ROLLBACK_SEGMENTS는 rollback segment나 undo segment의 transaction table에대한 read가가능합니다. commit된 transaction에대한 delayed block clean out이수행되며 uncommit된 transaction에대한 consistent read view생성이가능합니다. 그래서이 parameter만사용하는경우, table등을일관되게재구성이가능합니다. 하지만 lock이걸린 row에대한 update작업은실패하게됩니다. _CORRUPTED_ROLLBACK_SEGMENT는 transaction table에대한 access가불가합니다. 모든 transaction들이 commit되었다고봅니다. 그래서 commit되지않은 transaction들도 commit된것으로간주하기에 logical corruption상황이발생하게됩니다.
2. Rollback 손상으로데이터베이스구동실패시조치 로드맵 진단 조치 구동시에러발생 udump 내트레이스파일분석 init 파라미터변경후구동 구동중인시스템손상진단및복구방법 Event 10015 (Event 10013) 설정 문제세그먼트확인 9i UNDO_MANAGEMENT=MANUAL _OFFLINE_ROLLBACK_SEGMENTS=(_SYSSMU1$, _SYSSMU2$, _SYSSMU3$,...etc) 7.3 8i _OFFLINE_ROLLBACK_SEGMENTS=(RBS05) EVENT = "10015 TRACE NAME CONTEXT FOREVER, LEVEL 10" Database startup 시 rollback/undo segment 손상과관련된오류발생시진단및조치방법에대한로드맵입니다. 상세한분석을위해서 10015나 10013 event를설정하고이에의해생성된 trace file을가지고문제시되는 rollback및 undo segment확인과정을거쳐서조치하실수있습니다. 각오류에대한조치방법을뒤에서설명하겠습니다.
3. 구동중인시스템손상진단및복구방법 로드맵 진단 조치 Rollback 헤더정보조회 파일상태 RECOVER Rollback 세그먼트데이터파일복구필요 데이터파일 RECOVERY Rollback 세그먼트 DROP 파일상태 OFFLINE RBS 헤더액세스가능 Rollback 세그먼트연관액티브트랜잭션확인 최후의방법 파일상태 ONLINE 오류유형별조치방안 Database가 startup후구동중인상태에서 rollback/undo segment 손상시진단및조치방법에대한로드맵입니다. 먼저 rollback segment header정보를통해서생성되어있는 rollback segment의정보및 active transaction이있는지여부확인을합니다. 이후 rollback segment가속해있는 RBS tablespace의상태가 recover인지, offline인지 online인지를확인합니다. Online인경우엔 rollback segment header 엑세스가가능하나나머지두경우엔 datafile에대한복구가먼저선행되어야합니다. Rollback segment header의엑세스가가능하게되면 rollback segment의상태에따라혹은오류유형에따라복구과정에들어가게됩니다.
4. 에러유형별조치방안 ORA-1555 여러 session 에의해데이터변경이자주발생하는상황에서 SELECT 를통한데이터조회시 ORA-1555 에러발생. 원인 조치방안 SELECT 가시작된후다른세션에서동일테이블의데이터를변경할수있음. 그런데, SELECT 는실행된시점의데이터를읽기위해 (Consistent Read) 위해 Rollback 세그먼트를참조함. Rollback 당수용할수있는트랜잭션의개수가제한되어있으므로, commit 량이많다면, SELECT 에서참조하는 Rollback 세그먼트의정보가다른트랜잭션에의해 overwrite 되어존재하지않게됨. 이경우 ORA-1555 가발생. (1) Rollback 세그먼트의개수를늘려줌. (2) Rollback 세그먼트당크기를늘려줌. (3) 데이터를 fetch 하는커서에대한 loop 내에잦은 commit 을피함. (4) Cursor 에서처리하는데이터의양 consistent read 하게될데이터의양을줄여줌. (where 조건에서데이터를나누어처리 ) (5) Rollback shrink 가자주발생할경우, consistent read 를위한 before image 정보가없어질가능성이높아지므로, OPTIMAL 값을작지않게지정. (20extents 의 size 정도 ) ORA-1555 Ora-1555 error는 Long query 가시작된후다른세션에서동일테이블의데이터를변경하는경우 Long query 작업을하는 session은실행된시점의데이터를읽기위해 (Consistent Read) Rollback 세그먼트를참조하게됩니다. 하지만 Rollback 당수용할수있는트랜잭션의개수가제한되어있으므로, commit 량이많다면, SELECT에서참조하는 Rollback 세그먼트의정보가다른트랜잭션에의해 overwrite 되어존재하지않게될수있으며. 이경우 ORA-1555 snapshot too old error 가발생합니다. 조치방법은 Rollback 세그먼트의개수나크기를늘려주거나데이터를 fetch 하는커서에대한 loop 내에잦은 commit을피하며, Cursor에서처리하는데이터의양. 즉, consistent read 하게될데이터를나누어처리하시기바랍니다. 또한 Rollback shrink가자주발생할경우, consistent read를위한 before image 정보가없어질가능성이높아지므로, 만일 optimal을지정한경우라면 OPTIMAL 값을크게지정합니다. (20개의 extents size 정도지정 )
4. 에러유형별조치방안 ORA-1578 인스턴스구동중, ORA-1578 에러메시지와함께, 인스턴스구동실패 원인 조치방안 Rollback 세그먼트헤더의 corruption. 인스턴스구동중참조되는블록의 corruption (1) ( 아카이브로그모드 ) 유효한 backup을가지고손상된데이터파일의복구 (2) 손상된데이터파일이시스템테이블스페이스의데이터파일인데, 아카이브로그모드이면서복구를위한유효한백업이없거나, 노아카이브로그모드인경우는 cold backup 이나 export backup을이용한 DB재생성 (3) 시스템테이블스페이스데이터파일이외의데이터파일에서에러가발생한경우, 데이터파일을 MOUNT 상태에서 OFFLINE 시킨후데이터베이스오픈시도. (4) 데이터파일을 OFFLINE 시킬때, ora-1145 error 발생한다면, corrupt된 rollback segment block과관련되어있다는것을의미함. rollback_segments parameter에서문제의 rollback segment는 comment 처리후 _OFFLINE_ROLLBACK_SEGMENTS 파라미터를사용한데이터베이스구동시도. (5) 인스턴스가구동된후에는 corruption 발생세그먼트확인. (6) Corruption이발생한Rollback 세그먼트상태점검및조치 ORA-1578 Instance구동중에 rollback segment header의 corruption이나 instance구동중참조되는 block의 corruption발생시 ora-1578 error와함께 Startup이실패하게되는데이때조치방안은다음과같습니다. (1) 아카이브로그모드인경우유효한 backup을가지고손상된데이터파일을복구합니다. (2) 손상된데이터파일이시스템테이블스페이스의데이터파일인데, 아카이브로그모드이면서복구를위한유효한백업이없거나, 노아카이브로그모드인경우는 cold backup이나 export backup을이용한 DB재생성을합니다. (3) 시스템테이블스페이스데이터파일이외의데이터파일에서에러가발생한경우, 데이터파일을 MOUNT 상태에서 OFFLINE 시킨후데이터베이스오픈을시도. 합니다. (4) 데이터파일을 OFFLINE 시킬때, ora-1145 error 가발생한다면, corrupt된 rollback segment block과관련되어있다는것을의미하며. rollback_segments parameter에서문제의 rollback segment는 comment 처리후 _OFFLINE_ROLLBACK_SEGMENTS 파라미터를사용한데이터베이스구동을시도. 합니다. (5) 인스턴스가구동된후에는 corruption 발생세그먼트확인하여 (6) Corruption이발생한 Rollback 세그먼트상태점검및조치를합니다.
4. 에러유형별조치방안 ORA-1578 원인 Rollback 세그먼트헤더에 corruption 발생. Rollback 세그먼트헤더에대한 ORA-1578 발생 조치방안 (1) 아카이브로그모드에서백업본이있을경우 recovery 수행. (2) 백업본이없거나, 아카이브로그모드가아닐경우하단에 기술된조치수행 ORA-1578 원인 Rollback 세그먼트블록에 corruption 발생. Rollback 세그먼트블록에대한 ORA-1578 발생 조치방안 (1) Corruption이발생한파일및블록확인 (2) Corrupt가발생한 Rollback 세그먼트확인 SELECT segment_type, segment_name FROM dba_extents WHERE file_id=<file_num> AND <block_num> BETWEEN block_id and block_id+blocks-1; (3) Rollback 세그먼트의상태확인. OFFLINE 일경우 Rollback 세그먼트 DROP. 기타경우 Rollback 세그먼트상태점검및조치 ORA-1578 Rollback 세그먼트헤더에 corruption 이발생한경우엔, (1) 아카이브로그모드에서백업본이있을경우 recovery 수행합니다. Eg) ALTER DATABASE DATAFILE OFFLINE Save current copy of the file. Restore it at OS level from a good backup RECOVER DATAFILE ; ALTER DATABASE DATAFILE ONLINE; (2) 백업본이없거나, 아카이브로그모드가아닐경우 Rollback 세그먼트블록에 corruption시와같은순서에의해조치합니다. Rollback 세그먼트블록에 corruption 이발생한경우엔, (1) Corruption이발생한파일및블록을확인하고이정보를가지고 (2) Corrupt가발생한 Rollback 세그먼트를확인합니다. SELECT segment_type, segment_name FROM dba_extents WHERE file_id=<file_num> AND <block_num> BETWEEN block_id and block_id+blocks-1; (3) Rollback 세그먼트의상태를확인하여 OFFLINE 일경우 Rollback 세그먼트 DROP. 하며, 기타경우 Rollback 세그먼트상태점검하여조치하게됩니다.
4. 에러유형별조치방안 ORA-1545 인스턴스구동중, ORA-1545 에러메시지와함께, 인스턴스구동실패 원인 조치방안 init 파일의 rollback_segments에지정된 Rollback 세그먼트가가용상태가아님. Rollback 세그먼트를저장하는데이터파일이 OFFLINE 상태이거나, OPS에서다른인스턴스가사용중인 Rollback 세그먼트를지정하였을때발생. * Corruption이발생한경우, 일반적으로 ORA-1578이발생함. (1) Rollback 세그먼트이름을 init 파일에정확히적었는지확인. (2) Rollback 세그먼트가저장된데이터파일의상태가 ONLINE인지확인. (3) 문제가되는 Rollback 세그먼트를 rollback_segments 파라미터에서제외시킨후, 인스턴스를 startup mount. (4) 손상된데이터파일의복구 ( 아카이브로그모드 ) (5) 문제를유발시킨 Rollback 세그먼트의상태점검및조치 ora-1545 Instance startup시 ora-1545 error가발생하고 startup시실패하는경우는 init 파일의 rollback_segments에지정된 Rollback 세그먼트가가용상태가아니거나 Rollback 세그먼트를저장하는데이터파일이 OFFLINE 상태이거나, OPS에서다른인스턴스가사용중인 Rollback 세그먼트를지정하였을때발생합니다. 이에대한조치방법은 (1) 먼저 Rollback 세그먼트이름이 init 파일에정확히적었는지 (2) Rollback 세그먼트가저장된데이터파일의상태가 ONLINE인지확인합니다.. (3) 문제가되는 Rollback 세그먼트를 rollback_segments 파라미터에서제외시킨후, 인스턴스를 startup mount. 후 (4) 필요한경우손상된데이터파일의복구 ( 아카이브로그모드 ) 및 (5) 문제를유발시킨 Rollback 세그먼트의상태점검후조치합니다.
4. 에러유형별조치방안 ORA-1545 Rollback 세그먼트를 DROP 시킬때 ORA-1545 에러와함께실패 원인 조치방안 ONLINE 상태의 Rollback 세그먼트를 DROP 하려할경우, ORA-1545 발생 (1) Rollback 세그먼트의 STATUS 확인 (2) ONLINE 상태이면, Rollback 세그먼트를 OFFLINE 시킨후 DROP. ORA-1546 원인 테이블스페이스에 active rollback segment 가포함됨. 테이블스페이스를 OFFLINE 시킬때 ORA-1546 에러와함께실패 조치방안 (1) Rollback 세그먼트 OFFLINE 후재시도. Ora-1545 Rollback 세그먼트를 DROP 시킬때 ORA-1545 에러와함께실패하는경우는현재 rollback segment의상태가 online인경우입니다. 조치방법은 offline으로변경후 drop을합니다. Tablespace를 offline시킬때 Ora-1546 error는 tablespace내에 active rollback segment가포함되어있는경우에발생합니다. 조치방법은 rollback segment 를 offline 후에 tablespace 에대한 offline 을재시도하면됩니다.
4. 에러유형별조치방안 NEEDS RECOVERY 데이터베이스운영중, Rollback 세그먼트상태가 NEEDS RECOVERY 일때 원인 조치방안 (1) Rollback 세그먼트헤더액세스불가 (2) 트랜잭션 roll out 과정에서문제발생 ( 예 : 트랜잭션 roll out 에필요한테이블스페이스나, 데이터파일이 OFFLINE 상태일때 ) (1) 에러가발생한 Rollback 세그먼트상태점검및조치 PARTLY AVAILABLE 데이터베이스운영중, Rollback 세그먼트상태가 PARTL Y AVAILABLE 일때 원인 조치방안 (1) Rollback 세그먼트를사용하는 active transaction 이있으나, SMON 에서 recovery 를진행하고있을때. (2) Rollback 세그먼트에 in doubt transaction 이관련되어있을때. (1) 케이스 1의경우 SMON에서 recovery 완료후 Rollback 상 태를 OFFLINE 으로전환시킴. (2) 케이스 2의경우 in doubt transaction 이해소되어야함. (3) 에러가발생한 Rollback 세그먼트상태점검및조치 NEEDS RECOVER 데이터베이스운영중, Rollback 세그먼트상태가 NEEDS RECOVERY인경우는 Rollback과정에서어떤이유에서든문제가생겨서실패했기떄문입니다. Rollback이일어나면수정된데이터블록에기록된결과는취소되어야하지만, 해당데이타블록에접근이불가능하여 Rollback 작업을하지못하면 rollback segment상태가 needs recovery로되는것입니다. 데이터블럭에접근이불가능한경우는 tablespace나 datafile이 offline이거나없는경우, 해당데이터블록이속한 object가손상된경우, rollback segment의 data block이손상된경우등입니다. Rollback 세그먼트상태점검및조치를해야합니다. SELECT segment_id,segment_name FROM dba_rollback_segs WHERE status = NEEDS RECOVERY ; PARTLY AVAILABLE Rollback 세그먼트상태가 PARTLY AVAILABLE인경우는 Rollback 세그먼트를사용하는 active transaction이있으나, SMON에서 recovery를진행하고있을때또는 Rollback 세그먼트에 in doubt transaction이관련되어있을때그렇습니다. (ora-1591) 이경우전자의경우엔 SMON에서 recovery 완료후 Rollback 상태를 OFFLINE 으로전환시키며, 후자의경우엔 in doubt transaction 이해소되어야합니다. 이경우엔 in doubt transaction 을포함하는 rollback segment의상태점검및조치가필요하게됩니다.