분류 전체보기 (8)
ORACLE (4)
주식 (0)
네트워크 (0)
네트워크용어 (0)
SQL (0)
정보 (0)
교정 (0)
다른세계 (0)
엑셀 (0)
calendar
«   2024/04   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
tags
archive
link
ColorSwitch 00 01 02
▣  ORACLE - 해당되는 글 4건

▣  EXADATA dbd 용량 급증. - ORACLE - 2018. 9. 27. 11:37

엑사데이터를 관리하다 보면 dbd 파일이 급증하는 경우가 있다.

일종의 버그라고 듣기는 했는데 과연 버그일까 싶기도 하고 ... 30기가 이상으로 용량이 늘어나는거 같지는 않지만 u01이 급증을 하기에 신경이 많이 쓰인다.

결국 클러스터를 내리고 파일을 삭제하고 다시 클러스터를 올려서 기동을 시키는데 패치전에 증상이 계속 나타나다가 어느순간 사라졌다.

결국 프로그램이나 특정 쿼리 혹은 배치로 인해서 발생한 문제가 아니었을까 싶기도 한데 정확한 원인은 모르고 SR은 패치하라고만 하니 답이 안나온다 ㅋ

어쨌든 bdb파일은 더 이상급증하지 않은 상황에 패치는 진행했으니 꾸준히 지켜봐야 한다.


dbd 파일이 급증했을때는 아래와 같이 조치하면 된다.


1. dbd 파일 확인

cd /u01/app/11.2.0.4/grid/crf/db/[SID]/

ls -ltr


2.  crs down

crsctl stop resource ora.crf -init


3. crs 확인

crsctl status resource ora.crf -init


4. dbd 파일 삭제

rm -rf *.dbd


5. crs 재기동

crsctl start resource ora.crf -init


6. 로그 파일이 정상적으로 올라오는지 확인

ls -ltr


dbd파일이 재생성 되는지 확인하면 끝!



▣  exadata cell check - ORACLE - 2018. 9. 18. 14:00

exadata cell check 방법.

플래티넘 서비스를 쓴다면 상관없지만 보안으로 인해 외부망에 연결할수 없는 상황이라면 쓸만하다.


cell check

/opt/oracle.SupprotTools/idbiagtools/deli -g cell_group -l root cellcli -e list cell


cell detail

/opt/oracle.SupprotTools/idbiagtools/deli -g cell_group -l root cellcli -e list cell detail


celldisk detail 

/opt/oracle.SupprotTools/idbiagtools/deli -g cell_group -l root cellcli -e list celldisk detail


griddisk detail

/opt/oracle.SupprotTools/idbiagtools/deli -g cell_group -l root cellcli -e list griddisk detail


physicaldisk detail

/opt/oracle.SupprotTools/idbiagtools/deli -g cell_group -l root cellcli -e list physicaldisk detail




▣  ACTIVE DATA GUARD - ADG - ORACLE - 2018. 9. 18. 13:18

 ADG (ACTIVE DATA GUARD)


오라클이 제공하는 무중단 재해복구 솔루션으로 운영단에 문제가 생기더라도 빠른 전환을 통해서 서비스를 제공할 수 있다.


MRP 프로세스가 recovery 를 하면서 갭을 줄이게 되는데 어떤 문제로 인해서 갭이 발생하게 된다면 해당 프로세스를 내렸다 올리면 된다.


아래는 갭이 발생하여  SR에서 답을 받은것인데 사이트마다 구성이 다를수 있으므로 갭 발생시 그대로 하지 말고 SR을 올리자..

(밑에 있는데로 했다가 문제가 생겨도 내 책임 아니다;;)


alter database cover managed standby database cancel;

alter database cover managed standby database using current logfile disconnect;


alter database cover managed standby database cancel; 

과정에서 hang이 발생할 경우 몇 번 더 시도해보고 안될경우 db를 내린다.

shutdown immediate 

이 과정에서도 제대로 내려가지 않을경우에는 강제로 내렸다가 올린다.

shutdown abort


startup


이 후에는 mount 상태에서 recovery 를 하고 OPEN이 되던지 아니면 그냥 OPEN이 되던지 할것이다.

mount 상태에서 recovery 후 open 이 되었다면 MRP 프로세스가 정상적으로 떠 있는지 확인을 해야 한다.

내 경우에는 단 한번도 자동으로 떠 있는것을 보지 못하였다. 그럼 당연히 띄워줘야한다.


alter database cover managed standby database using current logfile disconnect;


정상적으로 실행이 되어 있는지 다시 한번 체크를 하고 rac 구성일 경우 노드를 확인한다.

이것역시 내 경우에는 2번 노드가 mount 상태로 되어 있어 정상적인 상태는 아니였기 때문에 2번 노트도 재기동 시켜주었다.


만약 mount 상테에서 recovery 없이 open이 되었고 여전히 갭이 있다면 위의 쿼리를 실행시켜 MRP 프로세스를 띄워주면 recovery 를 하게 된다.

마찬가지로 MRP프로세스가 떠 있는지 확인하고 2번 노드 확인하면 된다.


SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS; 

select process,pid from V$managed_standby where process like '%MRP%'; 


ZDLRA (Zero Data Loss Recovery Appliance)

오라클에서 나온 백업 솔루션이다. 오라클에서 나온만큼 가격도 한가격 하는걸로 알고 있으며 국내에서 쓰는곳도 거의 없는것으로 알고 있다.

그만큼 자료도 데이터도 구하기 힘들다는 뜻이기도 하다.


처음에 지드라를 접하고 나서 이걸 생각한 사람은 대단하다고 느꼈다.


백업은 보통 full 백업을 받고 archive 백업을 받는다.

문제가 생기면 full백업 받은 시점으로 복구를 하고 archive로 복구를 한다.


지드라는 타겟이 된 online redo buffer 를 보고 데이터를 가져온다. 그리고 자신의 instance 에 넣어버린다.

자신의 instance에 넣기 때문에 archive 역시도 지드라에 떨어진다. 타겟에서 archive 파일을 가지고 올 필요가 없다.

online redo buffer 를 보기 떄문에 작업이 완료되지 않은 데이터까지 복구가 가능하다


지드라 백업은 초기에 한번 full 백업을 받고 변경이 된 block 만 가져와서 증분백업을 한다. (block change tracking 사용 권장)

그리고 증분백업을 이용하여 날마다 새로운 가상의 full 백업을 만든다.

초기 풀백업만 한번 받으면 그 다음부터는 날마다 풀백업으로 사용될수 있다. 풀백업은 날마다 만들어지는데 용량은 변경된 만큼만 늘어난다. 



좋은 솔루션임에는 확실하나 국내에서 많이 쓰이지 않아 자료를 찾기 힘들기 떄문에 문제가 발생하면 바로 조치하기가 쉽지 않다.



ra_task - 최근 30일 수행된 백그라운드 작업 및 수행결과

rai_dynamic_tasks - 실시간으로 진행중인 백그라운드 작업 모니터링

ra_active_session - 현재 running 중인 세션에 대한 정보 및 세션의 작업 내용

ra_incident_log - 지드라에서 발생한 에러 정보


etc

 select

b.db_unique_name,

b.dbid,

to_char(a.low_time,'YYYYMMDD HH24:MI:SS') "LOW TIME",

to_char(a.high_time,'YYYYMMDD HH24:MI:SS') "HIGH TIME",

a.low_scn "LOW SCN",

a.high_scn "HIGH_SCN"

from ra_disk_restore_range a, ra_database b

where a.db_key=b.db_key;




articles
recent replies
recent trackbacks
notice
Admin : New post