Neo-Oracle Home

개요

정상적으로 운영중인 11.2.0.4 grid 환경에서 crsd.bin을 kill하면 바로 다시 시작되는데

이럴 상황은 거의 없겠지만 crsd를 다시 시작되지 않을 count만큼 kill 하고 어떻게 되는지 봅니다.

가끔 crsd만 죽어있는 상황에 적용할 수 있겠습니다.

kill 진행 - crsd.bin을 너무 빨리 kill하면 crsd startup hang이 걸리니 2초 간격으로 진행

=> 11번 죽였더니 안살아납니다. crsd의 maximun restart attempts은 확인을 못하겠네요. 테스트로 11번이 max 라는건 알게 되었습니다. 확인하는 다른 방법 아시는분은 알려주시면 감사하겠습니다.

alertcrs로그의 상태 중 마지막 영역

리소스 상태 체크

정상화 시키기 위해 stop 및 start 시도

crsd만 시작

확인

저자: 김수남, 김한도, 김태식, 서현석, 정영균

출판사: 영진닷컴

1판 1쇄 발행일: 2012년 4월 15일

오라클을 알고 있는 사람이 알티베이스의 내부 아키텍쳐를 대략적으로 이해하기 위해 좋은 책입니다.

기본적인 내용 말고 특징이나 단점, 궁금한 점이 책을 읽는 도중 체크되어 기록합니다.

괄호안의 내용은 제 의견이며, 단순히 책을 읽으며 생각나는 의견을 적은 것으로, 제품에 대한 선입견을 가지지 마시고 참고만 하면 되겠습니다.

특징

■ TCP/IP로 접속시는 shared 방식, IPC로 접속시는 dedicated 방식

■ 인메모리 TBS도 오라클에서 어느정도 keep buffer로 지원 가능할거 같은데..? 언두 빼고..

■ 메모리tbs던 디스크tbs던 log flusher가 기본 3.2초마다 logfile에 logbuffer 내용을 내려씀

■ 로그파일 크기는 DB 생성 후에는 변경할 수가 없다. 로그파일은 재활용되지 않고 새로 생성된다. 단, 체크포인트 시마다 불필요 로그파일이 삭제된다.=> 체크포인트 낫 컴플릿이 발생하지 않는다.

■ prepare_log_file_count 값을 설정시 미리 빈 로그 파일을 만들어 둔다.

■ 휘발성 메모리테이블스페이스가 존재한다. 그런데 오라클도 따지자면 temp table이 있는데..

■ loadbanancer가 서비스 쓰레드에게 일을 재분배하거나 idle한 서비스 쓰레드 갯수를 줄인다.

■ session manager가 클라이언트 상황 감지해서 비정상적 클라이언트 연결 끊어졌는지 확인

■ log anchor 파일은 다중화 가능

■ memory tbs는 undo를 사용하지 않고 메모리 tbs 내에 새로운 row를 저장하고 이를 연결한다. 불필요한 versioning 데이터는 memory ager가 삭제한다.

■ undo segment 수동관리는 없고 자동 관리 방법만 있다.

■ snapshot too old는 발생하지 않는다, 단 오라클에 비해 undo tbs 공간을 더 많이 사용할 수 있다.

■ 데드락 처리가 오라클과 반대. 즉 오라클은 먼저 락을 한 트랜잭션을 롤백하나 알티는 나중에 락 시도한 트랜잭션을 롤백함.

■ 메모리db는 디스크I/O가 없기에 cpu time을 줄이는 것이 주요 튜닝 목표

■ 알티도 CBO기반 옵티마이저가 기본값.

■ 알티는 null값도 인덱스에 저장함.

단점

■ 오라클의 멤버 다중화 기능은 없다. (RAID 설정된 디스크에 거의 두기 때문에 단점이라고 할 지는..)

■ 오라클의 spfile 기능은 없다. (좀 번거로울 뿐)

■ query_prepare, query_execute, query_binding 같은 공간(오라클의 LC와 동일역할)이 계속 할당되어 사용할 수 있다. 이 영역들은 max값 제한이 없기에 메모리가 무한정 늘어날 수 있다. 쿼리 1개가 사용하는 제한값 설정은 있다.(어떻게 관리?)

■ memory tbs는 undo를 사용하지 않고 메모리 tbs 내에 새로운 row를 저장하고 이를 연결한다. 이 Versioning 기법에 의해 메모리가 증가되는 경우가 제일 많다. (mem_max_db_size에 제한 받기는 하지만..)

■ memory tbs는 lock escalation이 일어날 수 있음. lock_escalation_memory_size 기본값이 100MB이고 만약 트랜잭션이 메모리 테이블에 dml을 하는데 버저닝 데이터가 100MB를 넘으면 DML시의 IX lock을 X lock으로 올리고 새로운 버전의 레코드와 before-image 생성하지 않고 현재 버전의 레코드에 바로 업데이트 진행. (이것의 영향이 어느정도일까?)

■ commit_write_wait_mode의 기본값이 0인데 이는 커밋시에 디스크가 아닌 메모리에만 기록하면 트랜잭션에게 응답을 준다는 의미. (빠르긴 하겠지만 데이터 손실 위험한건 아닌지?)

■ log_buffer_type을 0으로 해서 OS커널 영역에 redo log 기록하면 RT가 죽어도 OS가 살아있기에 OS가 redo log를 logfile에 기록하니까 안정적이 된다고 하는데.. (그럼 OS 정전 등으로 죽으면 결국 데이터 날아간다는 의미 아닌지?)

■ time_statistics 값이 기본 0이라서 시간 소요 관련 v$ 뷰들의 컬럼 값이 안나옴. 1로 변경해야함. (실제 DB에선 아마 1 쓰겠지?)

■ 옵티마이저 모드 중 first_rows 같은 모드는 없음. rbo와 cbo뿐

■ 컬럼 분포도(히스토그램)이나 클러스터링 팩터는 없음(최신 버전엔 나왔나? 하긴 오라클도 히스토그램을 실제 중요 DB에서 잘 사용하지 않기도 하니..)

■ AWR이나 statspack같은건 없음(최신 버전엔 나왔나?)

■ 별도로 통계수집하는 명령어가 없음. DML작업시마다 통계정보가 바뀜. (성능 영향이 있을것 같은데..)

■ 병렬 처리 아직 지원 안함.(최신 버전엔 나왔나?)

궁금한 점

▶ memory TBS가 기본 옵션인가?-> 오라클처럼 in memory db 옵션이 별도 금액이 필요한가의 의미

▶ checkpoint list, prepare list, lru list, flush list가 있는데 책에는 checkpoint list의 역할이 애매하다.

▶ PGA 자동관리 같은건 없는건가?

▶ checkpoint image file이 어떻게 메모리 tbs의 안정성을 보장하는지 자세한 원리

▶ memory tbs의 versioning 이슈를 관리하기 위한 방법은?

이펙티브 오라클이라는 2004년에 출시한 서적에 나오는 이야기로 아마 9i나 10g가 출시된 시기를 기준으로 써있습니다.

책에 나온 내용은 반말로, 제가 추가한 내용은 존댓말로 적겠습니다.

개발자와 DBA의 공용 필독서 => 새로운 릴리즈가 나올 때마다 다음 문서를 읽어야 한다.

■ Concepts

■ New feature Guide

개발자의 필독서

■ Application Development Guide

■ PL/SQL User Guide , Reference => 최근엔 User Guide가 따로 없고 위에서 말한 Development Guide에 PL/SQL 내용이 있습니다

■ Perfomance Tuning Guide => 전반부를 반드시 읽고 나머지 부분은 훑어보면 된다

DBA의 필독서 => concepts와 New feature Guide를 읽은 후 다음 문서를 읽어야 한다.

■ Backup and Recovery Concepts => 현재 기준으로 Backup and Recovery User's Guide를 이야기하는 것 같습니다.

10g에서도 Backup 관련은 Backup and Recovery Basics, Backup and Recovery Advanced Users's Guide 그리고 Reference만 있습니다. 아마도 Backup and Recovery Basics를 말하는 것 같은데 11g 문서부터는 Backup and Recovery User's Guide와 Reference만 나오고 있습니다.

■ Backup and Recovery Reference

■ Administration Guide

■ Perfomance Tuning Guide => 후반부는 각별히 주의해 읽어야 한다.

Concepts 문서를 조금이라도 읽어본 사람들은 해당 문서가 굉장히 좋은 문서임을 압니다.

허나 무료인데도 국내에선 Concept를 읽어본 사람은 드뭅니다(제 주변을 보아선?). 아무래도 영문이라서 그렇겠지요.

그리고 개발자 중에서 과연 Concepts을 읽는 사람이 있을까요? 아마도 없을 것 같습니다.