RAC용 점검 스크립트

RAC 1노드에서 양쪽 노드 모두 확인하는 점검 스크립트입니다.



엔지니어 분들이 고객사 점검에 사용하면 좋게 만들었습니다.

운영하시는 분들도 일일 상태 체크나 DB관련 정보 확인을 위해 사용 할 수 있습니다.

11g 기준으로 작성 되었습니다.


check_RAC.sql


'ORACLE > Operation & Admin' 카테고리의 다른 글

RAC용 점검 스크립트  (0) 2018.12.25
무료 오라클 성능진단 툴 Mumbai 3.1.1  (0) 2018.12.25
Table 또는 인덱스의 사이즈를 확인 하는 쿼리  (0) 2018.11.01
CURSOR_SHARING  (0) 2018.10.31
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18

무료 오라클 성능진단 툴 Mumbai 3.1.1

오라클 성능 진단 툴인 Mumbai 3.1.1





일단 AWR, Statspack, ASH 등을 이툴로 DB에 접속해 직접 추출 할 수 있으며, 무엇보다 좋은것은 시각화를 가능하게 해주는 점입니다.


실시간 모니터링 보다는 성능진단시 더 유용합니다. 시각화를 통한 보고서 작성이나 성능에 관련한 다양한 내용을 확인 할 수 있기 때문에 좋습니다.


아래 출처에 가시면 다운받을수 있습니다.


링크 : https://marcusmonnig.wordpress.com/2016/09/21/mumbai-version-3-1-1-available/



'ORACLE > Operation & Admin' 카테고리의 다른 글

RAC용 점검 스크립트  (0) 2018.12.25
무료 오라클 성능진단 툴 Mumbai 3.1.1  (0) 2018.12.25
Table 또는 인덱스의 사이즈를 확인 하는 쿼리  (0) 2018.11.01
CURSOR_SHARING  (0) 2018.10.31
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18

Netbackup 연동 RMAN 복원 테스트

현업에서는 서버를 관리하는데 있어서 대부분 백업 솔루션이 들업갑니다.


중소규모의 회사나 서버가 몇대 없는 회사의 경우, RMAN 스크립트를 만들어서 crontab 이나 작업스케줄러에 등록하여 백업을 받기도 하지만, 대규모의 기업이나 많은 수의 서버를 가진 업체의 경우 Netbackup 같은 백업 솔루션이 들어갑니다.


백업 솔루션은 Netbackup만 있는 것은 아니고 많은 회사들이 출시한 다양한 제품이 있지만, 국내에서 가장 많이 사용하는 백업 솔루션은 Netbackup 입니다. 백업 솔루션은 Acronis 같은 제품도 있고, 다양하게 있습니다.


Netbackup 같은 백업 솔루션은 단순 DB 백업 뿐 아니라 서버 자체를 백업 한다거나 다른 어플리케이션 백업도 가능합니다.

그렇기 때문에 Netbackup 엔지니어들은 Netbackup 설치나 OS 복구 정도는 할 수 있습니다. 


하지만, 오라클은 DB를 Netbackup을 이용해서 백업 할 줄 알아도, DB를 복구 하는 방법을 모르는 경우가 대부분 입니다. Netbackup을 다루는 회사마다 복구 메뉴얼이 있고, 메뉴얼 대로 복구 하는 경우가 많지만, 왜 그렇게 복구를 해야 하는지?, 복구하다 막혔을때 어떻게 해야 하는지 모르는 경우가 많아 DB 엔지니어나 DBA의 도움을 필요로 합니다. Netbackup 엔지니어들은 오라클을 집중적으로 공부한 경우가 많지 않기 때문이죠.


백업 계약이라는 것은 백업만 해주는게 아니고 장애시 복구가 포함 되는 것인데 백업 엔지니어가 DBA가 없으면 복구를 못하는 경운가 많다는 것이죠. 개인적으로 봤을때는 말이 안되는 상황이라고 봅니다. 업체측에서 restore 까지만 계약 되어 있다고 하는 경우도 있는데, 일반적으로 백업 복구는 recovery 후 시스템 정상화까지가 복구입니다. 


DBA와 백업 엔지니어가 협력해야 하는게 맞고, 서로서로 좋은게 좋은것이지만, 기본적으로 혼자 복구 할 줄 알아야 한다고 생각합니다. 어떤 회사는 들어가보면 DB는 있는데 DBA도 없고, DB 유지보수 계약도 없는 경우도 많거든요.




시나리오


● RAC 2노드 (ASM) -> Single DB (ASM Standalone)


 - RAC는 라이센스도 비싸고, 장비 세팅이나 준비사항이 많습니다. 

   그렇기 때문에 DR서버를 구축하거나 복구를 위한 테스트 서버를 RAC로 구축하는것은 낭비입니다.

 - 오라클 DB의 버전은 동일하게 맞춥니다. 원본이 11.2.0.4 라면 복구도 11.2.0.4

 - 파일 시스템은 일반 파일시스템이나 Raw Device 이어도 상관 없지만, 복구 과정 중에 Rename 작업이 필요하며, 

   ASM의 경우는 Rename 작업이 필요가 없습니다.

 - Netbackup에서 원본 서버의 RMAN 백업과 Archive 파일을 백업 받습니다.

 - 복구 서버에도 Netbackup 에이전트를 설치하고, RMAN의 저장 경로를 Netbackup으로 인식 시켜줍니다.



1. pfile 설정


 - pfile을 Netbackup에 있는 RMAN 백업에서 내려 받아도 상관 없지만, 그냥 원본에서 spfile을 pfile로 백업해서 드래그로 긁어 오는게 편합니다.


 원본서버

 SQL> create pfile='init<SID>.ora' from spfile;


 $ORACLE_HOME/dbs 밑에 가면 init<SID>.ora 파일이 생성 되어 있는데, 복구서버의 동일한 디렉토리에 복사해 주거나, vi로 만들어서 안의 내용을 복사해서 붙여 넣습니다.


rac2.__db_cache_size=1526726656

rac1.__db_cache_size=1459617792

rac2.__java_pool_size=16777216

rac1.__java_pool_size=16777216

rac2.__large_pool_size=33554432

rac1.__large_pool_size=33554432

rac1.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

rac2.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

rac2.__pga_aggregate_target=1258291200

rac1.__pga_aggregate_target=1342177280

rac2.__sga_target=2097152000

rac1.__sga_target=2013265920

rac2.__shared_io_pool_size=0

rac1.__shared_io_pool_size=0

rac2.__shared_pool_size=486539264

rac1.__shared_pool_size=469762048

rac2.__streams_pool_size=0

rac1.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/rac/adump'

*.audit_trail='db'

*.cluster_database=true

*.compatible='11.2.0.4.0'

*.control_files='+DATA/rac/controlfile/current.260.923661671','+RECO/rac/controlfile/current.256.923661671'

*.db_block_size=8192

*.db_create_file_dest='+DATA'

*.db_domain=''

*.db_name='rac'

*.db_recovery_file_dest='+RECO'

*.db_recovery_file_dest_size=7423918080

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=racXDB)'

rac1.instance_number=1

rac2.instance_number=2

*.log_archive_dest_1='LOCATION=/archive'

*.log_archive_format='arch_rac_%t_%s_%r.arc'

*.memory_target=3348103168

*.open_cursors=300

*.processes=350

*.remote_listener='rac-cluster-scan:1521'

*.remote_login_passwordfile='exclusive'

*.sessions=390

rac2.thread=2

rac1.thread=1

rac2.undo_tablespace='UNDOTBS2'

rac1.undo_tablespace='UNDOTBS1'

 


파라미터 파일을 수정해야 합니다.

rac 관련되 부분을 삭제 혹은 주석 처리하고, cluster_database는 ture에서 false로 변경해 줍니다.


수정 후


rac.__db_cache_size=1459617792

rac.__java_pool_size=16777216

rac.__large_pool_size=33554432

rac.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

rac.__pga_aggregate_target=1342177280

rac.__sga_target=2013265920

rac.__shared_io_pool_size=0

rac.__shared_pool_size=469762048

rac.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/rac/adump'

*.audit_trail='db'

*.cluster_database=false

*.compatible='11.2.0.4.0'

*.control_files='+DATA/rac/controlfile/current.260.923661671'

*.db_block_size=8192

*.db_create_file_dest='+DATA'

*.db_domain=''

*.db_name='rac'

*.db_recovery_file_dest='+DATA'

*.db_recovery_file_dest_size=7423918080

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=racXDB)'

rac.instance_number=1

#rac2.instance_number=2

*.log_archive_dest_1='LOCATION=/archive'

*.log_archive_format='arch_rac_%t_%s_%r.arc'

*.memory_target=3348103168

*.open_cursors=300

*.processes=350

#*.remote_listener='rac-cluster-scan:1521'

*.remote_login_passwordfile='exclusive'

*.sessions=390

#rac2.thread=2

rac.thread=1

#rac2.undo_tablespace='UNDOTBS2'

rac.undo_tablespace='UNDOTBS1'


수정하고 diag 경로를 생성하고, archive 경로가 맞는지 확인해줍니다.


$ mkdir -p /app/oracle/admin/rac/adump

$ mkdir -p /archive

# chown oracle.oinstall /archive


수정이 완료 되면 DB가 nomount 상태까지 올라갑니다.


$ sqlplus / as sysdba

SQL> startup nomount;


그러면 DB쪽은 Restore 준비가 끝난 상태입니다.



2. Netbackup 에서 Controlfile 내려 받기


 - DB가 nomount 상태가 되면 Netbackup 에이전트 설치 및 Netbackup RMAN 연동이 가능합니다. (Netbackup 엔지니어 작업)

 - Netbackup과 RMAN이 연결되면, RMAN에서 list backup 명령시 백업 파일들이 나옵니다.


RMAN> 


RUN {

ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';

SEND 'NB_ORA_SERV=<넷백업 서버명>, NB_ORA_CLIENT=<복구서버 클라이언트 명>';

RESTORE CONTROLFILE FROM 'ctrl_dracDB_udnrljheg_s439_p1_t928630224';

RELEASE CHANNEL ch00;

}


빨간색으로 된 부분은 콘트롤 파일의 백업인데, 백업마다 이름이 다르고, 서버마다 다르니 맞는 걸 찾아서 복원하면 됩니다.


콘트롤 파일이 복원디면 DB mount가 가능해집니다.


RMAN> alter database mount;



3. Restore


 - controlfile이 복원되면 restore가 가능해집니다.

 - ASM의 경우 datafile의 끝에 랜덤 숫자로 고유번호가 붙는데, 원본 DB와 복구DB의 번호가 다릅니다.

 - Restore 시 바뀐 번호로 자동 적용됩니다.


restore 명령을 실행 해봅니다.


RMAN>


RUN {

ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';

SEND 'NB_ORA_SERV=<넷백업 서버명>, NB_ORA_CLIENT=<복구서버 클라이언트 명>';

RESTORE DATABASE;                                   

RELEASE CHANNEL ch00;

}


그러면 진행 상황이 나오며, restore가 진행됩니다.


Starting restore at 23-OCT-16

using channel ORA_DISK_1


channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to +DATA/rac/datafile/system.256.923661571

channel ORA_DISK_1: restoring datafile 00002 to +DATA/rac/datafile/sysaux.257.923661571

channel ORA_DISK_1: restoring datafile 00003 to +DATA/rac/datafile/undotbs1.258.923661573

channel ORA_DISK_1: restoring datafile 00004 to +DATA/rac/datafile/users.259.923661573

channel ORA_DISK_1: restoring datafile 00005 to +DATA/rac/datafile/example.264.923661707

channel ORA_DISK_1: restoring datafile 00006 to +DATA/rac/datafile/undotbs2.265.923661973

channel ORA_DISK_1: restoring datafile 00007 to +DATA/rac/datafile/test01.269.924548909

channel ORA_DISK_1: reading from backup piece /work/rman/0qrijlsp_1_1_20161017.bkp

channel ORA_DISK_1: piece handle=/work/rman/0qrijlsp_1_1_20161017.bkp tag=TAG20161017T161729

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:18:05

Finished restore at 23-OCT-16


RMAN>



4. Recovery


 - recover database 명령을 날려보면 필요한 archive log 파일 리스트가 나옵니다.


RMAN> recover database;


Starting recover at 23-OCT-16
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=473
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=239
channel ORA_DISK_1: reading from backup piece /work/rman/0srijm73_1_1_20161017.bkp
channel ORA_DISK_1: ORA-19870: error while restoring backup piece /work/rman/0srijm73_1_1_20161017.bkp
ORA-19504: failed to create file "/archive/arch_rac_2_473_923661675.arc"
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
Additional information: 1

failover to previous backup
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 10/23/2016 17:28:31
RMAN-20506: no backup of archived log found
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of archived log for thread 1 with sequence 239 and starting SCN of 4539696 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 473 and starting SCN of 4539693 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 238 and starting SCN of 4539695 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 472 and starting SCN of 4539692 found to restore
RMAN-06025: no backup of archived log for thread 1 with sequence 237 and starting SCN of 4539694 found to restore
RMAN-06025: no backup of archived log for thread 2 with sequence 471 and starting SCN of 4539691 found to restore

thread 1은 1번 노드, thread 2는 2번 노드의 아카이브 파일입니다.
빨간색으로 된 부분에서 sequence 넘버를 잘 보면 맨 위에가 최신이고, 아래쪽이 오래된 시퀀스 넘버입니다.
해당 시퀀스 번호를 가진 아카이브 로그가 필요하다는 뜻 입니다.

그러면 Netbackup에서 아카이브 로그를 복구 합니다.

RUN {
ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
SEND 'NB_ORA_SERV=<넷백업 서버명>, NB_ORA_CLIENT=<복구서버 클라이언트 명>';
RESTORE ARCHIVELOG FROM SEQUENCE 237 UNTIL SEQUENCE 239 THREAD 1;
RESTORE ARCHIVELOG FROM SEQUENCE 471 UNTIL SEQUENCE 473 THREAD 2;
RELEASE CHANNEL ch00;
}


그 후에

RMAN> recover database;

RMAN> alter database open resetlogs; 

하면 완료가 됩니다.


  1. 도움이 되는 내용 잘 읽었습니다.
    다만, 조금 잘 못 알고 계신 부분이 있는데요..
    보통의 S/W유지보수 계약 시, 장애복구 내용은 해당하는 S/W의 정상화지
    Application 단위 장애의 정상화가 아닙니다....
    그런 계약이라면 아마 엄청난 유지보수 비용을 요구하리라 생각됩니다.

    오라클 DB의 장애인데, 백업업체가 모든걸 처리하면 오라클 유지보수 업체는 어떤 일을 하시나요?
    오라클 업체야 말로 계약한 DB시스템의 장애 시 복구 Role 이 있는 것이지요??
    복구 Role 이 누가 더 큰지 잘 생각해 보시기 바랍니다.

    님의 논리대로라면,
    백업엔지니어는
    MSSQL, Oracle, DB2, Exchange, SAP 기타 등등 현존하는 거의 모든 Application을 다룰 줄 알아야 한다는 것인데
    그런 인력이 과연 존재는 할까요?? ^^;


Error in invoking target 'agent nmhs' of makefile

11g 설치시 나오는 에러

Error in invoking target 'agent nmhs' of makefile ....

이라고 에러가 나오는 경우.


Oracle 11g R2를 Install하는 동안 “Error in invoking target 'agent nmhs' of makefile - during 11g Installation”과 같은 오류가 보고되는 경우 그냥 무시를 하고 진행해도 되지만 “$ emctl status dbconsole” 또는 오라클 에이젼트가 오작동을 일으키는 경우가 있습니다.


위와 같이 오류가 보고되는 순간 계속 진행하지 말고,


1. “$ORACLE_HOME/sysman/lib/ins_emagent.mk”을 vi로 Open


2. “$(MK_EMAGENT_NMECTL)”를 찾아서 “$(MK_EMAGENT_NMECTL) -lnnz11” 로 수정


3. 인스톨로 “Retry”를 선택하여 무시하지 말고 계속 진행.

리눅스7 버전에서 11g grid 설치시 root.sh 실패

root.sh 실행시 

아래와 같이 나오며 설치 실패 되는 경우


[root@localhost /]# /u01/app/11.2.0/grid/perl/bin/perl -I/u01/app/11.2.0/grid/perl/lib -I/u01/app/11.2.0/grid/crs/install /u01/app/11.2.0/grid/crs/install/roothas.pl

Using configuration parameter file: /u01/app/11.2.0/grid/crs/install/crsconfig_params

Creating trace directory

User ignored Prerequisites during installation

LOCAL ADD MODE

Creating OCR keys for user ‘oracle’, privgrp ‘oinstall’..

Operation successful.

LOCAL ONLY MODE

Successfully accumulated necessary OCR keys.

Creating OCR keys for user ‘root’, privgrp ‘root’..

Operation successful.

CRS-4664: Node localhost successfully pinned.

Adding Clusterware entries to inittab

ohasd failed to start

Failed to start the Clusterware. Last 20 lines of the alert log follow:

2016-01-01 02:14:46.806:

[client(11401)]CRS-2101:The OLR was formatted using version 3.

2016-01-01 02:14:49.572:

[client(11424)]CRS-1001:The OCR was formatted using version 3.


ohasd failed to start at /u01/app/11.2.0/grid/crs/install/roothas.pl line 377, line 4.




해결 방안


1. deinstall 해서 설치를 삭제


[root@localhost deinstall]# su – oracle

Last login: Fri Jan 1 02:17:02 EST 2016 on pts/1

[oracle@localhost ~]$ cd /u01/app/11.2.0/grid/deinstall

[oracle@localhost deinstall]$ ./deinstall


Checking for required files and bootstrapping …

Please wait …

Location of logs /tmp/deinstall2016-01-01_02-30-16AM/logs/


############ ORACLE DEINSTALL & DECONFIG TOOL START ############

######################### CHECK OPERATION START ###########################

[START] Install check configuration ##


Checking for existence of the Oracle home location /u01/app/11.2.0/grid

Oracle Home type selected for deinstall is: Oracle Grid Infrastructure for a Standalone Server

Oracle Base selected for deinstall is: /u01/app/oracle

Checking for existence of central inventory location /u01/app/oraInventory

Checking for existence of the Oracle Grid Infrastructure home /u01/app/11.2.0/grid

Checking for sufficient temp space availability on node(s) : ‘localhost.localdomain’


## [END] Install check configuration ##

Traces log file: /tmp/deinstall2016-01-01_02-30-16AM/logs//crsdc.log

Network Configuration check config START

Network de-configuration trace file location: /tmp/deinstall2016-01-01_02-30-16A/logs/netdc_check2016-01-01_02-30-40-AM.log

Network Configuration check config END

Asm Check Configuration START


ASM de-configuration trace file location: /tmp/deinstall2016-01-01_02-30-16AM/logs/asmcadc_check2016-01-01_02-30-41-AM.log

ASM configuration was not detected in this Oracle home. Was ASM configured in this Oracle home (y|n) [n]: n

ASM was not detected in the Oracle Home


######################### CHECK OPERATION END #########################

####################### CHECK OPERATION SUMMARY #######################

Oracle Grid Infrastructure Home is: /u01/app/11.2.0/grid

The cluster node(s) on which the Oracle home deinstallation will be performed are:null

Oracle Home selected for deinstall is: /u01/app/11.2.0/grid

Inventory Location where the Oracle home registered is: /u01/app/oraInventory

ASM was not detected in the Oracle Home

Do you want to continue (y – yes, n – no)? [n]: y

A log of this session will be written to: ‘/tmp/deinstall2016-01-01_02-30-16AM/logs/deinstall_deconfig2016-01-01_02-30-35-AM.out’

Any error messages from this session will be written to: ‘/tmp/deinstall2016-01-01_02-30-16AM/logs/deinstall_deconfig2016-01-01_02-30-35-AM.err’


######################## CLEAN OPERATION START ########################

ASM de-configuration trace file location: /tmp/deinstall2016-01-01_02-30-16AM/logs/asmcadc_clean2016-01-01_02-30-57-AM.log

ASM Clean Configuration END


Network Configuration clean config START

Network de-configuration trace file location: /tmp/deinstall2016-01-01_02-30-16A/logs/netdc_clean2016-01-01_02-30-57-AM.log

De-configuring backup files…

Backup files de-configured successfully.


The network configuration has been cleaned up successfully.

Network Configuration clean config END


—————————————->


Run the following command as the root user or the administrator on node “localhost”.


/tmp/deinstall2016-01-01_02-30-16AM/perl/bin/perl -I/tmp/deinstall2016-01-01_02-30-16AM/perl/lib -I/tmp/deinstall2016-01-01_02-30-16AM/crs/install /tmp/deinstall2016-01-01_02-30-16AM/crs/install/roothas.pl -force -deconfig -paramfile “/tmp/deinstall2016-01-01_02-30-16AM/response/deinstall_Ora11g_gridinfrahome1.rsp”


Press Enter after you finish running the above commands


<————————————-


This is the point where you have to execute the command highlighted and execute it from root user and wait for it to complete in order to deconfigure the Oracle Restart Stack.


[root@localhost ~]# /tmp/deinstall2016-01-01_02-30-16AM/perl/bin/perl -I/tmp/deinstall2016-01-01_02-30-16AM/perl/lib -I/tmp/deinstall2016-01-01_02-30-16AM/crs/install /tmp/deinstall2016-01-01_02-30-16AM/crs/install/roothas.pl -force -deconfig -paramfile “/tmp/deinstall2016-01-01_02-30-16AM/response/deinstall_Ora11g_gridinfrahome1.rsp”

Using configuration parameter file: /tmp/deinstall2016-01-01_02-30-16AM/response/deinstall_Ora11g_gridinfrahome1.rsp

CRS-2613: Could not find resource ‘ora.cssd’.

CRS-4000: Command Stop failed, or completed with errors.

CRS-2613: Could not find resource ‘ora.cssd’.

CRS-4000: Command Delete failed, or completed with errors.

CRS-4133: Oracle High Availability Services has been stopped.

Successfully deconfigured Oracle Restart stack



#########################

Setting the force flag to false

Setting the force flag to cleanup the Oracle Base

Oracle Universal Installer clean START


Detach Oracle home ‘/u01/app/11.2.0/grid’ from the central inventory on the local node : Done

Delete directory ‘/u01/app/11.2.0/grid’ on the local node : Done

Delete directory ‘/u01/app/oraInventory’ on the local node : Done

Delete directory ‘/u01/app/oracle’ on the local node : Done

Oracle Universal Installer cleanup was successful.

Oracle Universal Installer clean END


## [START] Oracle install clean ##

Clean install operation removing temporary directory ‘/tmp/deinstall2016-01-01_02-30-16AM’ on node ‘localhost’

## [END] Oracle install clean ##

######################### CLEAN OPERATION END #########################

####################### CLEAN OPERATION SUMMARY #######################

Oracle Restart was already stopped and de-configured on node “localhost”

Oracle Restart is stopped and de-configured successfully.

Successfully detached Oracle home ‘/u01/app/11.2.0/grid’ from the central inventory on the local node.

Successfully deleted directory ‘/u01/app/11.2.0/grid’ on the local node.

Successfully deleted directory ‘/u01/app/oraInventory’ on the local node.

Successfully deleted directory ‘/u01/app/oracle’ on the local node.

Oracle Universal Installer cleanup was successful.


Run ‘rm -rf /etc/oraInst.loc’ as root on node(s) ‘localhost’ at the end of the session.

Run ‘rm -rf /opt/ORCLfmap’ as root on node(s) ‘localhost’ at the end of the session.

Run ‘rm -rf /etc/oratab’ as root on node(s) ‘localhost’ at the end of the session.

Oracle deinstall tool successfully cleaned up temporary directories.

#######################################################################

############# ORACLE DEINSTALL & DECONFIG TOOL END #############


2. Oracle Support 홈페이지 (metalink)에서 패치 18370031 를 받는다.


3. Grid를 재설치 하고 root.sh 실행 바로전에 OPatch 18370031을 패치 한다.


 $ opatch napply -local ./18370031


4. 패치가 끝나면 root.sh 실행

DBMS 기본 데이터 타입

● 문자 데이터 타입


데이터 타입 

설명 

 CHAR(크기[BYTE|CHAR])

 고정길이 문자, 최대 2000byte, 디폴트 값 1byte 

 VARCHAR2(크기[BYTE|CHAR])

 고정길이 문자, 최대 4000byte, 디폴트 값 1byte 

 NCHAR (크기)

 고정길이 유니코드 문자 (다국어 입력 가능), 최대 2000BYTE, 디폴트 값 1byte

 NVARCHAR2 (크기)

 고정길이 유니코드 문자 (다국어 입력 가능), 최대 4000BYTE, 디폴트 값 1byte

 LONG

 최대 2GB 크기의 가변길이 문자형, 잘 사용하지 않음



● 숫자 데이터 타입


 데이터 타입 

 설명 

 NUMBER[(p,[s])]

 가변숫자, p(1~38, 디폴트 38) s(-84~127, 디폴트 0) 십진수 기준, 최대 22byte

 FLOAT[(p)]

 NUMBER의 하위 타입, p는 1~128, 디폴트 128, 이진수 기준, 최대 22byte

 BINARY_FLOAT

 32비트 부동소수점 수, 최대 4byte 

 BINARY_DOUBLE

 64비트 부동소수점 수, 최대 8byte 


- 4가지가 있지만 주로 NUMBER를 많이 사용합니다. 다른 DBMS는 INTEGER와 같은 정수형, DECIMAL과 같은 실수형을 제공합니다. 오라클도 INTEGER과 DECIMAL로 생성이 가능 하지만, 내부적으로는 NUMBER 형으로 변환되어 생성됩니다.



● 날짜 데이터 타입


데이터 타입 

 설명 

 DATE

 BC 4712년 1월 1일부터 9999년 12월 31일, 

 연,월,일,시,분,초까지 입력가능

 TIMESTAMP[(fractional_seconds_precision)]

 연도, 월, 일, 시, 분, 초는 물론 밀리초 까지 입력 가능

 fractional_seconds_precision은 0~9까지 입력할 수 있고 디폴트는 6



● LOB 데이터 타입 (Large OBject의 약자)


데이터 타입

 설명 

 CLOB

 문자형 대용량 객체. 고정길이와 가변길이 문자 집합 지원, 

 최대크기 (4GB-1)x(데이터베이스 블록 사이즈)

 NCLOB

 유니코드(다국어 지원)를 포함한 문자형 대용량 객체. 

 최대크기 (4GB-1)x(데이터베이스 블록 사이즈)

 BLOB

 이진형 대용량 객체, 최대 크기 (4GB-1)x(데이터베이스 블록 사이즈)

 BFILE

 대용량 이진 파일에 대한 로케이터(위치, 이름)저장. 최대 저장 크기는 4GB



● NULL


 - NULL은 '값이 없음'을 의미하면 테이블을 생성할 때 컬럼 속성에 기술한다. 디폴트 값이 NULL이므로 별도 지정 없으면 해당 컬럼은 NULL을 허용한다. NOT NULL로 명시한 컬럼에 데이터를 넣지 않으면 해당 로우 INSERT가 불가능하다.



'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

데이터베이스 객체의 종류

●  데이터베이스 객체의 종류


 데이터베이스 객체

 설명

 TABLE

 데이터를 담고 있는 객체 

 VIEW

 하나 이상의 테이블을 연결해서 마치 테이블인 것처럼 사용하는 객체 

 INDEX

 테이블에 있는 데이터를 빠르게 찾기 위한 객체 

 SYNONYM

 데이터베이스 객체에 대한 별칭을 부여한 객체 

 SEQUENCE

 일련번호 채번을 할 때 사용하는 객체

 FUNCTION

 특정 연산을 하고 값을 반환하는 객체

 PROCEDURE

 함수와 비슷하지만 값을 반환하지는 않는 객체 

 PACKAGE

 용도에 맞게 함수나 프로시저를 하나로 묶어놓은 객체



●  TABLE


- 데이터를 넣고 수정하고 삭제하는, 데이터를 담고 있는 가장 기본적인 객체. ROW (행)과 COLUMN (열)으로 구성된 2차원 형태(표)의 객체로 우리가 자주쓰는 엑셀과 비슷한 구조라고 보면 이해가 쉽습니다.


- TABLE 생성은 CREATE문으로 생성할 수 있는데, 기본 구문은 아래와 같습니다.


CREATE TABLE [스키마.]테이블명 (

컬럼1    컬럼1_데이터타입    [NULL, NOT NULL],

컬럼2    컬럼2_데이터타입    [NULL, NOT NULL],

...

) [TABLESPACE 테이블스페이스명];


스키마명은 생략이 가능하며, 생략하게되면 현재 자신이 로그인한 스키마 이름으로 생성됩니다.

TABLESPACE 구문도 생략이 가능한데, 해당 사용자의 디폴트 TABLESPACE에 생성됩니다.

'ORACLE > Oracle DBMS' 카테고리의 다른 글

DBMS 기본 데이터 타입  (0) 2018.11.02
데이터베이스 객체의 종류  (0) 2018.11.02
SCN과 Checkpoint  (0) 2014.06.12
Redo Log  (0) 2014.06.12
Control File  (0) 2014.06.11
Oracle Character set 에 관하여  (0) 2014.06.10

Table 또는 인덱스의 사이즈를 확인 하는 쿼리

개별 단위로 테이블 사이즈가 알고 싶을때 조회 하는 쿼리


select owner,segment_name,segment_type,sum(bytes)/1024/1024 as MB

from dba_segments

where OWNER='APP_USER'

GROUP BY owner,segment_name,segment_type;

'ORACLE > Operation & Admin' 카테고리의 다른 글

RAC용 점검 스크립트  (0) 2018.12.25
무료 오라클 성능진단 툴 Mumbai 3.1.1  (0) 2018.12.25
Table 또는 인덱스의 사이즈를 확인 하는 쿼리  (0) 2018.11.01
CURSOR_SHARING  (0) 2018.10.31
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18

CURSOR_SHARING

CURSOR_SHARING


어플리케이션이 리터럴SQL을 사용해서 만들어졌거나 패키지 어플리케이션이 바인드 변수를 사용하지 않는 경우, 이런 상황에서 성은이 나빠진다면 CURSOR_SHARING 파라미터를 이용해서 어플리케이션을 크게 변경하지 않고 튜닝하는 것이 가능합니다.


CURSOR_SHARING 파라미터는 EXACT, FORCE, SIMILAR 라는 값을 가지고 있고, FORCE 또는 SIMILAR로 설정한 경우, 사용자가 리터럴 SQL을 수행하여도 오라클이 리터럴값을 바인드 변수로 치환합니다.


실제 수행구문

SQL> select count(col1) from test where col2 = 10;


오라클이 Parse 한 SQL문

SQL> select count(col1) from test where col2 = :"SYS_B_0" ;


● FORCE 

 - 리터럴 값에 상관없이 한 개의 공유 커서를 공유합니다. 바인드 피크와 같이 특이한 값에 최적화될 위험이 있습니다.

 - Shared Pool 사용량을 줄이는 효과 및 경합을 줄이는 효과가 큽니다.


● SIMILAR

 - 실행 계획이 확실히 같을 때에만 한 개의 공유 커서를 공유합니다. 최적의 실행 계획이 같지 않을 가능성이 있는 경우에는 동일 문장에 여러 개의 공유 커서를 만듭니다.

 - 옵티마이저 통계를 수집한 경우 범위 조건을 지정하거나, 히스토그램을 수집했을때의 '=' 조건 등은 리터럴값에 따라 최적인 실행 계획이 달라질수 있으므로 다른 리터럴 값마다 자식 커서를 생성합니다.

 - 옵티마이저 통계가 없고 다이나믹 샘플링도 꺼져있다면, 내부 기본값에 의해 실행 계획이 결정되므로 같은 공유 커서를 사용합니다. 컬럼 통계가 최소값과 최대값만 있을 경우 (히스토그램 없음), '=' 조건은 선택도가 항상 1/NDV가 되기 때문에 같은 공유 커서를 사용합니다.


'CURSOR_SHARING=SIMILAR'일 때는 경우에 따라 Shared Pool 사용량을 줄이는 효과가 거의 없으며 경합도 줄이지 못하는 경우가 있습니다. SIMILAR를 사용할 때는 테스트를 하고 V$SQLAREA.VERSION_COUNT를 조사하여 값이 적은지에 대한 여부 (커서의 공유되고 있는지)를 확인해야 합니다.


SQL> select sql_text, version_count from v$sqlarea

   2  where sql_text like 'select /* TEST%';


SQL_TEST                                                VERSION_COUNT

------------------------------------------------------- -------------

select count(col1) from test where col2 = :"SYS_B_0" ;              5  


VERSION_COUNT = 5 는  같은 SQL문의 자식 커서가 5개 있다는 뜻

'ORACLE > Operation & Admin' 카테고리의 다른 글

무료 오라클 성능진단 툴 Mumbai 3.1.1  (0) 2018.12.25
Table 또는 인덱스의 사이즈를 확인 하는 쿼리  (0) 2018.11.01
CURSOR_SHARING  (0) 2018.10.31
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18
Listener password  (0) 2018.10.14

ASM 용량 확인

오라클 ASM DG 용량 확인


col name format a10

col USABLE_FILE_GB format 999,999.00

col TOTAL_GB       format 999,999.00

col FREE_GB        format 999,999.00

col USABLE_CALC_GB format 999,999.00


select group_number "Group#",

       name,

       total_mb/1024 TOTAL_GB,

   round((total_mb - USABLE_FILE_MB)/1024,2) USED_GB,

       USABLE_FILE_MB/1024 USABLE_FILE_GB,    

   free_mb/1024 FREE_GB,

       100-round(free_mb/total_mb*100) "usgae(%)",

        ((FREE_MB - REQUIRED_MIRROR_FREE_MB))/1024 USABLE_CALC_GB,

       type, state

from v$asm_diskgroup;


실제 사용하는 ASM의 용량을 확인 할 수 있습니다.


Free 와 Usable의 차이는 

Exadata의 경우, 남은 디스크 용량이 있으나 오라클 측에서 판매시 용량 제한을 위해 걸어둔 락이 있을시 사용 할 수 있는 공간의 이 FREE와 USABLE_FILE_DB 컬럼의 차이로 나타납니다.



    Group# NAME TOTAL_GB    USED_GB USABLE_FILE_GB FREE_GB   usgae(%) USABLE_CALC_GB TYPE STATE

---------- ---------- ----------- ---------- -------------- ----------- ---------- -------------- ------ -----------

1 DATA    119.99      37.87       82.12   82.12 32     82.12 EXTERN CONNECTED

2 RECO     60.00 1.34       58.65   58.65 2     58.65 EXTERN CONNECTED



일반적인 RAC ASM의 경우 DG를 RECO나 DATA만을 설정하기도 하고, DATA에 모두 넣는 경우도 있습니다.

OCR_VOTE 부분만 따로 빼서 설정하는 경우도 있습니다.



ASM을 모델링 할때


OCR, DATA, RECO, ACFS, FRA 등을 구성 할 수 있습니다.

FRA를 자주 활용 한다면 FRA DG를 크게 구성해서 FRA를 활용하는 방법도 있습니다.


'ORACLE > Operation & Admin' 카테고리의 다른 글

Table 또는 인덱스의 사이즈를 확인 하는 쿼리  (0) 2018.11.01
CURSOR_SHARING  (0) 2018.10.31
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18
Listener password  (0) 2018.10.14
CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17

Datafile Resize 계산하기

- maxshrink.sql - 


set verify off 

column file_name format a50 word_wrapped 

column smallest format 999,990 heading ""Smallest|Size|Poss."" 

column currsize format 999,990 heading ""Current|Size"" 

column savings format 999,990 heading ""Poss.|Savings"" 

break on report 

compute sum of savings on report 


column value new_val blksize 

select value from v$parameter where name = 'db_block_size' 


select file_name, 

ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) smallest, 

ceil( blocks*&&blksize/1024/1024) currsize, 

ceil( blocks*&&blksize/1024/1024) - 

ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) savings 

from dba_data_files a, 

( select file_id, max(block_id+blocks-1) hwm 

from dba_extents 

group by file_id ) b 

where a.file_id = b.file_id(+) 


column cmd format a75 word_wrapped 


select 'alter database datafile '''||file_name||''' resize ' || 

ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) || 'm;' cmd 

from dba_data_files a, 

( select file_id, max(block_id+blocks-1) hwm 

from dba_extents 

group by file_id ) b 

where a.file_id = b.file_id(+) 

and ceil( blocks*&&blksize/1024/1024) - 

ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) > 0 



테이블 스페이스에 공간이 부족해서 여유공간을 확보하려고 테이블에 데이터를 지우고 축소를 하려면?


해당 Tablespace가 automatic segment management 가 되어있어야 하고


해당 Table은 row movement가 enable 되어있어야 합니다


되어있다면 


SQL> alter table [table_name] shrink space;


SQL> alter table [table_name] shrink space cascade;


Shrink 작업으로 HWM를 당긴 다음에 Resize 작업을 진행해야 합니다.


Shrink는 온라인 상태에서 가능하나 시간이 오래 걸리고,


HWM 당길 테이블들을 기존에 담고 있는 Tablespace로 Move 명령을 하면 Reorg 작업이 가능합니다.


단, Tablespace를 offline 상태에서 해야합니다.

'ORACLE > Operation & Admin' 카테고리의 다른 글

CURSOR_SHARING  (0) 2018.10.31
ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18
Listener password  (0) 2018.10.14
CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17
Oracle 8i Startup, shutdown  (0) 2018.04.09

RMAN 으로 Raw device 백업 복구하기

테스트 1 : Raw device 상태의 데이터파일을 RMAN 의 backupset 으로 백업 받은 후 정상적으로 복구 되는지 확인


Step 1. 현재상태 확인


[oracle@localhost ~]$ sqlplus / as sysdba


SQL*Plus: Release 10.2.0.5.0 - Production on Wed Feb 1 11:05:19 2012

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL> !vi dd.sql


set line 200

col tablespace_name for a10

col file_name for a45

select tablespace_name,bytes/1024/1024 MB,file_name from dba_data_files

/

:wq!


SQL> @dd <- Data file 상태 확인


TABLESPACE MB FILE_NAME

------------------- ---------- ---------------------------------------------

USERS 5 /dev/raw/raw4

SYSAUX 250 /dev/raw/raw2

UNDOTBS1 30 /dev/raw/raw3

SYSTEM 440 /dev/raw/raw1

EXAMPLE 100 /dev/raw/raw5


SQL> !vi log.sql <- Redo log file 상태 확인


set line 200

col group# for 999

col member for a20

col mb for 999

col seq# for 999

col archived for a4

col status for a8

select a.group#,a.member,b.bytes/1024/1024 MB,b.sequence# "SEQ#" ,b.archived,b.status

from v$logfile a, v$log b

where a.group#=b.group#

order by 1,2

/

:wq!


SQL> @log


GROUP# MEMBER MB SEQ# ARCH STATUS

---------- -------------------- ------ ------- ---------- -----------

1 /dev/raw/raw10 50 4 NO CURRENT

1 /dev/raw/raw9 50 4 NO CURRENT

2 /dev/raw/raw11 50 2 YES INACTIVE

2 /dev/raw/raw12 50 2 YES INACTIVE

3 /dev/raw/raw13 50 3 YES INACTIVE

3 /dev/raw/raw14 50 3 YES INACTIVE

6 rows selected.


SQL> select name from v$controlfile;


NAME

---------------------------------

/dev/raw/raw6

/dev/raw/raw7

/dev/raw/raw8


SQL> archive log list;

Database log mode Archive Mode

Automatic archival Enabled

Archive destination /data/arc2

Oldest online log sequence 2

Next log sequence to archive 4

Current log sequence 4


Step 2. RMAN 을 사용하여 전체 백업(백업경로는 /data/backup/rman/ 으로 하겠습니다)


[oracle@localhost ~]$ rman target /


Recovery Manager: Release 10.2.0.5.0 - Production on Wed Feb 1 10:47:50 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: TESTDB (DBID=2557423915)


RMAN> backup as compressed backupset

2> format '/data/backup/rman/%U_%T'

3> database;

Starting backup at 01-FEB-12

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=144 devtype=DISK

channel ORA_DISK_1: starting compressed full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00001 name=/dev/raw/raw1

input datafile fno=00003 name=/dev/raw/raw2

input datafile fno=00005 name=/dev/raw/raw5

input datafile fno=00002 name=/dev/raw/raw3

input datafile fno=00004 name=/dev/raw/raw4

channel ORA_DISK_1: starting piece 1 at 01-FEB-12

channel ORA_DISK_1: finished piece 1 at 01-FEB-12

piece handle=/data/backup/rman/01n27hl4_1_1_20120201 tag=TAG20120201T104907

comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:36

channel ORA_DISK_1: starting compressed full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

including current control file in backupset

including current SPFILE in backupset

channel ORA_DISK_1: starting piece 1 at 01-FEB-12

channel ORA_DISK_1: finished piece 1 at 01-FEB-12

piece handle=/data/backup/rman/02n27hm8_1_1_20120201 tag=TAG20120201T104907

comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

Finished backup at 01-FEB-12


[oracle@localhost ~]$ ls -lSh /data/backup/rman/

합계 112M

-rw-r----- 1 oracle dba 111M 2월 1 10:49 01n27hl4_1_1_20120201 <- 전체 backupset

-rw-r----- 1 oracle dba 1.1M 2월 1 10:49 02n27hm8_1_1_20120201 <- controlfile backupset


Step 3. 테스트용 테이블 scott.gogak 테이블 생성 후 장애 발생시킴


[oracle@localhost ~]$ sqlplus scott/tiger


SQL*Plus: Release 10.2.0.5.0 - Production on Wed Feb 1 11:14:21 2012

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL> create table gogak (no number, name varchar2(10)) tablespace users;

Table created.


SQL> insert into gogak values (1,'AAA');

1 row created.


SQL> insert into gogak values (2,'BBB');

1 row created.


SQL> commit;

Commit complete.


SQL> select * from gogak;


NO NAME

---------- ----------

1 AAA

2 BBB


SQL> conn / as sysdba

Connected.


SQL> @dd


TABLESPACE MB FILE_NAME

---------------- ---------- ---------------------------------------------

USERS 5 /dev/raw/raw4 <- 이 파일에 장애 발생시킴

SYSAUX 250 /dev/raw/raw2

UNDOTBS1 30 /dev/raw/raw3

SYSTEM 440 /dev/raw/raw1

EXAMPLE 100 /dev/raw/raw5


SQL> !dd if=/dev/zero of=/dev/raw/raw4 bs=8k

dd: writing `/dev/raw/raw4': 장치에 남은 공간이 없음

12801+0개의 레코드를 입력하였습니다

12800+0개의 레코드를 출력하였습니다


SQL> alter tablespace users offline immediate;

Tablespace altered.


SQL> alter tablespace users online;

alter tablespace users online

*

ERROR at line 1:

ORA-01122: database file 4 failed verification check

ORA-01110: data file 4: '/dev/raw/raw4'

ORA-01210: data file header is media corrupt


SQL> select * from scott.gogak;

select * from scott.gogak

*

ERROR at line 1:

ORA-00376: file 4 cannot be read at this time

ORA-01110: data file 4: '/dev/raw/raw4'


Step 4. RMAN 으로 해당 장애 복구하기


[oracle@localhost ~]$ rman target /


Recovery Manager: Release 10.2.0.5.0 - Production on Wed Feb 1 11:19:20 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: TESTDB (DBID=2557423915)

RMAN> run {

2> sql "alter tablespace users offline immediate";

3> restore tablespace users;

4> recover tablespace users;

5> sql "alter tablespace users online";

6> }

sql statement: alter tablespace users offline immediate

Starting restore at 01-FEB-12

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00004 to /dev/raw/raw4

channel ORA_DISK_1: reading from backup piece /data/backup/rman/01n27hl4_1_1_20120201

channel ORA_DISK_1: restored backup piece 1

piece handle=/data/backup/rman/01n27hl4_1_1_20120201 tag=TAG20120201T104907

channel ORA_DISK_1: restore complete, elapsed time: 00:00:02

Finished restore at 01-FEB-12

Starting recover at 01-FEB-12

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 01-FEB-12

sql statement: alter tablespace users online


RMAN> exit

Recovery Manager complete.


[oracle@localhost ~]$ sqlplus scott/tiger


SQL*Plus: Release 10.2.0.5.0 - Production on Wed Feb 1 11:21:53 2012

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL> select * from gogak;


NO NAME

---------- ----------

1 AAA

2 BBB


위에서 테스트 해 본 바와 같이 Raw device 도 RMAN 으로 백업 및 복구가 가능합니다.



테스트 2. Raw device 상태의 데이터 파일을 backupset 으로 증분 백업 가능한지와 복구 가능한지 테스트



Step 1. 현재 상태 확인


[oracle@localhost ~]$ sqlplus / as sysdba


SQL*Plus: Release 10.2.0.5.0 - Production on Wed Feb 1 11:24:25 2012

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL> @dd


TABLESPACE MB FILE_NAME

----------------- ---------- ---------------------------------------------

USERS 5 /dev/raw/raw4

SYSAUX 250 /dev/raw/raw2

UNDOTBS1 30 /dev/raw/raw3

SYSTEM 440 /dev/raw/raw1

EXAMPLE 100 /dev/raw/raw5


SQL> @log


GROUP# MEMBER MB SEQ# ARCH STATUS

----------- ---------------------- ------- --------- ---------- -------------

1 /dev/raw/raw10 50 4 NO CURRENT

1 /dev/raw/raw9 50 4 NO CURRENT

2 /dev/raw/raw11 50 2 YES INACTIVE

2 /dev/raw/raw12 50 2 YES INACTIVE

3 /dev/raw/raw13 50 3 YES INACTIVE

3 /dev/raw/raw14 50 3 YES INACTIVE


SQL> select name from v$controlfile;


NAME

----------------------------------------

/dev/raw/raw6

/dev/raw/raw7

/dev/raw/raw8

6 rows selected.



Step 2. RMAN 을 사용하여 증분 백업을 여러 차례 수행합니다.


[oracle@localhost ~]$ rman target /


Recovery Manager: Release 10.2.0.5.0 - Production on Wed Feb 1 11:28:05 2012

Copyright (c) 1982, 2007, Oracle. All rights reserved.

connected to target database: TESTDB (DBID=2557423915)


RMAN> backup as compressed backupset

2> incremental level 0

3> format '/data/backup/rman/%U_%T'

4> database;

Starting backup at 01-FEB-12

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=145 devtype=DISK

channel ORA_DISK_1: starting compressed full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00001 name=/dev/raw/raw1

input datafile fno=00003 name=/dev/raw/raw2

input datafile fno=00005 name=/dev/raw/raw5

input datafile fno=00002 name=/dev/raw/raw3

input datafile fno=00004 name=/dev/raw/raw4

channel ORA_DISK_1: starting piece 1 at 01-FEB-12

channel ORA_DISK_1: finished piece 1 at 01-FEB-12

piece handle=/data/backup/rman/03n27jur_1_1_20120201 tag=TAG20120201T112827

comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:35

channel ORA_DISK_1: starting compressed full datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

including current control file in backupset

including current SPFILE in backupset

channel ORA_DISK_1: starting piece 1 at 01-FEB-12

channel ORA_DISK_1: finished piece 1 at 01-FEB-12

piece handle=/data/backup/rman/04n27jvu_1_1_20120201 tag=TAG20120201T112827

comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

Finished backup at 01-FEB-12

-- 다른 터미널에서 데이터 변경을 위해 테이블 생성하고 데이터 입력합니다.


SQL> create table scott.gogak2 (no number,name varchar2(10)) tablespace users;

Table created.


SQL> insert into scott.gogak2 values (1,'CCC');

1 row created.


SQL> insert into scott.gogak2 values (2,'DDD');

1 row created.


SQL> commit;

Commit complete.


-- RMAN 터미널에서 증분 백업을 수행합니다.

RMAN> backup as compressed backupset

2> incremental level 2

3> format '/data/backup/rman/%U_%T'

4> tablespace users;

Starting backup at 01-FEB-12

using channel ORA_DISK_1

channel ORA_DISK_1: starting compressed incremental level 2 datafile backupset

channel ORA_DISK_1: specifying datafile(s) in backupset

input datafile fno=00004 name=/dev/raw/raw4

channel ORA_DISK_1: starting piece 1 at 01-FEB-12

channel ORA_DISK_1: finished piece 1 at 01-FEB-12

piece handle=/data/backup/rman/05n27knu_1_1_20120201 tag=TAG20120201T114150

comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 01-FEB-12



Step 3. 장애를 발생 시킵니다


SQL> @dd


TABLESPACE MB FILE_NAME

---------------- ------- ---------------------------------------------

USERS 5 /dev/raw/raw4

SYSAUX 250 /dev/raw/raw2

UNDOTBS1 30 /dev/raw/raw3

SYSTEM 440 /dev/raw/raw1

EXAMPLE 100 /dev/raw/raw5


SQL> !dd if=/dev/zero of=/dev/raw/raw4 bs=8k <- 장애를 발생시킵니다

dd: writing `/dev/raw/raw4': 장치에 남은 공간이 없음

12801+0개의 레코드를 입력하였습니다

12800+0개의 레코드를 출력하였습니다


SQL> alter tablespace users offline immediate;

Tablespace altered.


SQL> alter tablespace users online;

alter tablespace users online

*

ERROR at line 1:

ORA-01122: database file 4 failed verification check

ORA-01110: data file 4: '/dev/raw/raw4'

ORA-01210: data file header is media corrupt


SQL> select * from scott.gogak2;

select * from scott.gogak2

*

ERROR at line 1:

ORA-00376: file 4 cannot be read at this time

ORA-01110: data file 4: '/dev/raw/raw4'



Step 4. RMAN 으로 복구 후 확인합니다.


RMAN> run {

2> restore tablespace users;

3> recover tablespace users;

4> sql "alter tablespace users online" ;

5> }

Starting restore at 01-FEB-12

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backupset restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

restoring datafile 00004 to /dev/raw/raw4

channel ORA_DISK_1: reading from backup piece /data/backup/rman/05n27knu_1_1_20120201

channel ORA_DISK_1: restored backup piece 1

piece handle=/data/backup/rman/05n27knu_1_1_20120201 tag=TAG20120201T114150

channel ORA_DISK_1: restore complete, elapsed time: 00:00:01

Finished restore at 01-FEB-12

Starting recover at 01-FEB-12

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 01-FEB-12

sql statement: alter tablespace users online


SQL> select * from scott.gogak2;


NO NAME

---------- ----------

1 CCC

2 DDD



테스트 3. RMAN 으로 Raw device 상태의 데이터 파일을 Raw device 형태로 백업 받은 후 복구 가능한지 테스트



Step 1. 현재 상태 확인


RMAN> report schema;

Report of database schema

List of Permanent Datafiles

===========================

File Size(MB) Tablespace RB segs Datafile Name

---- -------- -------------------- ------- ------------------------

1 440 SYSTEM *** /dev/raw/raw1

2 30 UNDOTBS1 *** /dev/raw/raw3

3 250 SYSAUX *** /dev/raw/raw2

4 5 USERS *** /dev/raw/raw4

5 100 EXAMPLE *** /dev/raw/raw5

List of Temporary Files

=======================

File Size(MB) Tablespace Maxsize(MB) Tempfile Name

---- -------- -------------------- ----------- --------------------

1 20 TEMP 100 /dev/raw/raw15


Step 2. RMAN 으로 Raw device 파일 백업 수행


RMAN> copy

2> datafile 1 to '/data/backup/rman/system' ,

3> datafile 2 to '/data/backup/rman/undotbs1' ,

4> datafile 3 to '/data/backup/rman/sysaux' ,

5> datafile 4 to '/data/backup/rman/users' ,

6> datafile 5 to '/data/backup/rman/example' ;

Starting backup at 01-FEB-12

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile copy

input datafile fno=00001 name=/dev/raw/raw1

output filename=/data/backup/rman/system tag=TAG20120201T115814 recid=9

stamp=774100724

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:35

channel ORA_DISK_1: starting datafile copy

input datafile fno=00003 name=/dev/raw/raw2

output filename=/data/backup/rman/sysaux tag=TAG20120201T115814 recid=10

stamp=774100744

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:16

channel ORA_DISK_1: starting datafile copy

input datafile fno=00005 name=/dev/raw/raw5

output filename=/data/backup/rman/example tag=TAG20120201T115814 recid=11

stamp=774100749

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:07

channel ORA_DISK_1: starting datafile copy

input datafile fno=00002 name=/dev/raw/raw3

output filename=/data/backup/rman/undotbs1 tag=TAG20120201T115814 recid=12

stamp=774100754

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03

channel ORA_DISK_1: starting datafile copy

input datafile fno=00004 name=/dev/raw/raw4

output filename=/data/backup/rman/users tag=TAG20120201T115814 recid=13

stamp=774100756

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01

Finished backup at 01-FEB-12

-- 다른 창에서 백업 파일을 확인합니다


[oracle@localhost rman]$ pwd

/data/backup/rman


[oracle@localhost rman]$ ls –lSh

-rw-r----- 1 oracle dba 441M 2?? 1 11:58 system

-rw-r----- 1 oracle dba 251M 2?? 1 11:59 sysaux

-rw-r----- 1 oracle dba 101M 2?? 1 11:59 example

-rw-r----- 1 oracle dba 31M 2?? 1 11:59 undotbs1

-rw-r----- 1 oracle dba 5.1M 2?? 1 11:59 users


Step 3. 테스트용 테이블 scott.gogak3 을 생성 후 장애를 발생시킵니다.


SQL> create table scott.gogak3 (no number, name varchar2(10))

2 tablespace users;

Table created.


SQL> insert into scott.gogak3 values (1,'EEE');

1 row created.


SQL> insert into scott.gogak3 values (2,'FFF');

1 row created.


SQL> commit;

Commit complete.


SQL> select * from scott.gogak3;


NO NAME

---------- ----------

1 EEE

2 FFF


SQL> @dd


TABLESPACE MB FILE_NAME

---------------- -------- ---------------------------------------------

USERS 5 /dev/raw/raw4

SYSAUX 250 /dev/raw/raw2

UNDOTBS1 30 /dev/raw/raw3

SYSTEM 440 /dev/raw/raw1

EXAMPLE 100 /dev/raw/raw5

SQL> !dd if=/dev/zero of=/dev/raw/raw4 bs=8k

dd: writing `/dev/raw/raw4': 장치에 남은 공간이 없음

12801+0개의 레코드를 입력하였습니다

12800+0개의 레코드를 출력하였습니다


SQL> alter tablespace users offline immediate;

Tablespace altered.


SQL> alter tablespace users online;

alter tablespace users online

*

ERROR at line 1:

ORA-01122: database file 4 failed verification check

ORA-01110: data file 4: '/dev/raw/raw4'

ORA-01210: data file header is media corrupt


SQL> select * from scott.gogak3;

select * from scott.gogak3

*

ERROR at line 1:

ORA-00376: file 4 cannot be read at this time

ORA-01110: data file 4: '/dev/raw/raw4'


Step 4. RMAN 으로 파일을 복원 한 후 복구합니다.


RMAN> restore tablespace users;

Starting restore at 01-FEB-12

using channel ORA_DISK_1

channel ORA_DISK_1: restoring datafile 00004

input datafile copy recid=13 stamp=774100756 filename=/data/backup/rman/users

destination for restore of datafile 00004: /dev/raw/raw4

channel ORA_DISK_1: copied datafile copy of datafile 00004

output filename=/dev/raw/raw4 recid=14 stamp=774101682

Finished restore at 01-FEB-12

위에서 진하게 표시된 부분을 보면 RMAN 에서 자동으로 copy 된 raw device 를 찾아서

복원하는 것을 알 수 있습니다.


RMAN> recover tablespace users;

Starting recover at 01-FEB-12

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:00

Finished recover at 01-FEB-12


-- sqlplus 창에서 데이터가 복구되었는지 확인합니다.


SQL> alter tablespace users online;

Tablespace altered.


SQL> select * from scott.gogak3;

NO NAME

---------- ----------

1 EEE

2 FFF


정상적으로 복구가 된 것을 알 수 있습니다.

위에서 살펴본 바와 같이 Raw Device 로 구성된 database 도 RMAN 으로 동일하게 관리할 수 있습니다.

Listener password

Listener password 생성


1. 배경


해커들이 가장 즐겨 사용하는 트릭 중 하나가 대량의 텍스트를 리스너로 전달하여 실행을 강제 종료하도록 유도하는 것입니다. 

이 경우 데이터베이스는 여전히 실행 중이지만 리스너가 다운되기 때문에 새로운 연결을 생성할 수 없게 되므로, “서비스 거부(denial of service)” 공격이 가능합니다. 


해커는 이를 위해 리스너의 속성 변경을 시도할 수 있습니다. 이를 위해 services 커맨드를 이용하여 리스너에 의해 처리되는 서비스의 목록을 조회하는 방법이 자주 사용됩니다. 

아래 실행 예에서 볼 수 있는 것처럼 해커에게 필요한 충분한 수준의 정보가 제공되고 있음을 확인할 수 있습니다. 



LSNRCTL> set displaymode verbose

LSNRCTL> services

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)

(HOST=prolin1.proligence.com)(PORT=1521)(IP=FIRST)))

Services Summary...

Service "PROPRD" has 1 instance(s).

  Instance "PROPRD1", status READY, has 1 handler(s) for this

service...

    Handler(s):

      "DEDICATED" established:0 refused:0 state:ready

         LOCAL SERVER

(ADDRESS=(PROTOCOL=BEQ)(PROGRAM=/u01/oracle/products/10.1/db1/bin/ora

cle)(ARGV0=oraclePROPRD11)(ARGS='(LOCAL=NO)')(ENVS='_=/u01/oracle/pro

ducts/10.1/db1/bin/racgmain,_USR_ORA_CONNECT_STR=/ as

sysdba,_CAA_CHECK_INTERVAL=600,SHLIB_PATH=/u01/oracle/products/10.1/d

b1/lib32:/u01/oracrs/10gr1crs/lib32:/opt/nmapi/nmapi2/lib/hpux32:,_CA

A_ACTIVE_PLACEMENT=0,PATH=,_USR_ORA_ALERT_NAME=,_USR_ORA_IF=,_CAA_OPT

IONAL_RESOURCES=,_USR_ORA_START_TIMEOUT=0,ORACLE_BASE=/u01/oracle/pro

ducts/10.1/db2,_USR_ORA_DISCONNECT=false,_CAA_SCRIPT_TIMEOUT=600,_CAA

_UPTIME_THRESHOLD=7d,_USR_ORA_STOP_TIMEOUT=0,_CAA_FAILOVER_DELAY=0,_U

SR_ORA_PRECONNECT=none,_USR_ORA_FLAGS=,_CAA_TYPE=application,_USR_ORA

_INST_NOT_SHUTDOWN=,_CAA_REASON=boot,INIT_STATE=3,_USR_ORA_OPEN_MODE=

,_CAA_STATE=:OFFLINE,,_CAA_RESTART_ATTEMPTS=5,_CAA_ACTION_SCRIPT=/u01

/oracle/products/10.1/db1/bin/racgwrap,_CAA_DESCRIPTION=CRS

application for

Instance,_CAA_HOSTING_MEMBERS=prolin1,ORA_RACG_EXEC_ENV=LD_LIBRARY_PA

TH=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nm

api/nmapi2/lib/hpux64:/usr/lib:,_CAA_CLIENT_LOCALE=,_CAA_NAME=ora.PRO

PRD1.PROPRD11.inst,ORA_CRS_HOME=/u01/oracrs/10gr1crs,_CAA_AUTO_START=

1,_CAA_TARGET=:ONLINE,,_USR_ORA_PFILE=,_USR_ORA_OPI=false,_USR_ORA_CH

ECK_TIMEOUT=0,_CAA_PLACEMENT=restricted,_USR_ORA_LANG=,LD_LIBRARY_PAT

H=/u01/oracle/products/10.1/db1/lib:/u01/oracrs/10gr1crs/lib:/opt/nma

pi/nmapi2/lib/hpux64:/usr/lib:,_CAA_REQUIRED_RESOURCES=ora.prolin1.vi

p,_CAA_FAILURE_THRESHOLD=0,ORACLE_HOME=/u01/oracle/products/10.1/db1,

_USR_ORA_SRV=,PWD=/u01/oracrs/10gr1crs/bin,_USR_ORA_VIP=,_USR_ORA_STO

P_MODE=immediate,_CAA_FAILURE_INTERVAL=0,_USR_ORA_NETMASK=,_USR_ORA_D

EBUG=0,ORACLE_SID=PROPRD1,ORA_NET2_DESC=9,12,ORACLE_SPAWNED_PROCESS=1

')(ENV_POLICY=NONE))


또 다른 해킹 유형으로 리스너를 셧다운하는 방법이 있습니다. 새로운 연결은 거부되며, 따라서 실질적인 서비스 거부 공격이 가능합니다. 또는 다른 서버에 먼저 침입한 후 리스너의 원격 관리 기능을 이용하여 리스너를 원격에서 종료하는 방법이 가능합니다. 



2. 전략


최선의 대안은 tnslsnr, lsnrctl 실행 파일의 소유자를 제외한 모든 권한을 제거하는 것입니다. 이러한 방법으로 오라클 소프트웨어의 소유자를 제외한 어느 누구도 리스너를 시작 또는 종료할 수 없도록 통제할 수 있습니다. 실행 파일의 권한은 아래와 같이 설정됩니다. 


-rwx------   1 oracle    oinstall    214720 Oct 25 01:23 lsnrctl

-rwx------   1 oracle    oinstall   1118816 Oct 25 01:23 tnslsnr


경우에 따라 리스너의 시작/종료 권한을 다른 사용자에게 허용해야 할 수도 있습니다. 이러한 경우라면 아래와 같이 권한을 변경해 주어야 합니다. 


$ chmod 0711 lsnrctl



하지만 이와 같은 경우라 하더라도 패스워드 정책을 통해 불법적인 침입을 차단할 수 있어야 합니다. 패스워드를 설정하면 (HELP와 같은 무해한 명령을 제외한) 모든 커맨드가 비활성화됩니다. 


패스워드를 설정하는 방법은 버전에 관계없이 동일합니다. 하지만 그 적용 메커니즘은 버전에 따라 다릅니다:

 

Oracle9i Database Release 2 및 이전 버전에서는 모든 사용자가 패스워드를 입력해야 합니다. 

Oracle Database 10g Release 1 및 이후 버전에서는 데이터베이스 소프트웨어를 소유한 OS 사용자는 패스워드를 입력할 필요가 없습니다. 다른 모든 사용자는 패스워드를 필요로 합니다.

Oracle Database 11g Release 2부터는 Listener에 password생성하는 방법이 Deprecated되어 Single DB는 가능하지만 RAC에서는 사용할 수 없습니다.



3. Listener password 설정


 1) $ORACLE_HOME/network/admin/listener.ora 파일 상에 파라미터 추가

   LOCAL_OS_AUTHENTICATION_LISTENER = OFF

   - Oracle10g만 필요하며 9i 이전 DB는 필요없음

   

 2) lsnrctl 실행 후 작업 (이 때 리스너는 실행되고 있어야 함)


 - change_password 

   새로운 Passowrd를 설정하는 부분으로 old password 를 물어볼 때 그냥 엔터 ,

   new password 와 reenter password는 새로운 비빌번호 입력


 - set password

   새로 설정한 password확인

   

 - save_config

   새로 설정한 비밀번호 저장


3. 2번 단계가 끝나면 listener.ora 파일이 아래의 내용이 추가된다

#----ADDED BY TNSLSNR ----

PASSWORDS_LISTENER_ODSSDB01 = 75CD180DE6C75466

#--------------------------------------------



4. 설정 확인


패스워드를 입력하는 방법이 아래와 같습니다: 


LSNRCTL> set password mypassword

The command completed successfully

LSNRCTL> status

Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))

STATUS of the LISTENER

------------------------

Alias                     LISTENER

...


잘못된 패스워드가 입력되면 아래와 같은 에러가 뜹니다. 

TNS-01169: The listener has not recognized the password.



패스워드를 입력하지 않고 명령을 실행하면 아래와 같은 에러가 뜹니다. 

TNS-01190: The user is not authorized to execute the requested listener command



패스워드가 적용되었는지 확인하기 위해서는 아래와 같이 실행하여 리스너의 STATUS 설정을 조회합니다: 


$ lsnrctl status



출력 결과는 버전에 따라 다릅니다. Oracle9i Database 환경의 실행 결과 중 일부가 아래와 같습니다: 


STATUS of the LISTENER

------------------------

Alias                     LISTENER

Version                   TNSLSNR for Solaris: Version 9.2.0.6.0 - Production

Start Date                25-OCT-2005 10:26:47

Uptime                    0 days 13 hr. 8 min. 36 sec

Trace Level               off

Security                  ON

마지막 라인(Security ON)에서 패스워드가 설정되었음을 확인할 수 있습니다.


RAC인 경우 CRS Start시 listener를 자동으로 start되는데 이때 패스워드를 사용할 수 없으므로 수작업으로 listener를 start시켜야 합니다.

'ORACLE > Operation & Admin' 카테고리의 다른 글

ASM 용량 확인  (0) 2018.10.28
Datafile Resize 계산하기  (0) 2018.10.18
Listener password  (0) 2018.10.14
CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17
Oracle 8i Startup, shutdown  (0) 2018.04.09
ASM  (0) 2018.03.12

RAC to single RMAN 복구 (예제 - from ASM to ASM)

RAC to single RMAN 복구 (예제 - from ASM to ASM)



1. 원본 DB에서 RMAN으로 Full 백업



$ rman target /

RMAN> run {

Allocate channel c2 device type disk

format ‘경로/파일명.bkp’;

backup database plus archivelog;

}



2. 파라미터 파일 복원



원본 서버에서 RMAN 백업 파일을 가져옵니다.

복구 테스트 서버에는 엔진만 설치 되어 있습니다.


$ export ORACLE_SID=test (복구하는 db는 다른이름으로 해도 상관없습니다.)

$ rman target /

RMAN> startup nomount;  (명령을 하면 파라미터 파일 없이 구동됩니다)

RMAN> restore spfile from '백업파일이 있는 경로/파일.bkp’; 

- (RMAN 으로 백업된 파일이 여러 개 이기 때문에 이중에서 spfile이 들어있는 파일을 찾아야 하는데 명령어를 날려서 성공하는걸 찾는 수밖에 없습니다.)


 이 작업이 성공하면 $ORACLE_HOME/dbs 밑에 복구 DB의 ORACLE_SID로 설정된 명칭으로 spfile이 생성됩니다.

Sqlplus / as sysdba 접속해서

Create pfile from spfile; 명령으로 파라미터 파일을 pfile로 생성합니다.

Initnirs.ora 파일을 열고 RAC 관련된 부분을 삭제합니다.


변경전 (예제)

test2.__db_cache_size=1526726656

test1.__db_cache_size=1459617792

test2.__java_pool_size=16777216

test1.__java_pool_size=16777216

test2.__large_pool_size=33554432

test1.__large_pool_size=33554432

test1.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

test2.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

test2.__pga_aggregate_target=1258291200

test1.__pga_aggregate_target=1342177280

test2.__sga_target=2097152000

test1.__sga_target=2013265920

test2.__shared_io_pool_size=0

test1.__shared_io_pool_size=0

test2.__shared_pool_size=486539264

test1.__shared_pool_size=469762048

test2.__streams_pool_size=0

test1.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/test/adump'

*.audit_trail='db'

*.cluster_database=true

*.compatible='11.2.0.4.0'

*.control_files='+DATA/test/controlfile/current.260.923661671','+RECO/test/controlfile/current.256.923661671'

*.db_block_size=8192

*.db_create_file_dest='+DATA'

*.db_domain=''

*.db_name='test'

*.db_recovery_file_dest='+RECO'

*.db_recovery_file_dest_size=7423918080

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=testXDB)'

test1.instance_number=1

test2.instance_number=2

*.log_archive_dest_1='LOCATION=/archive'

*.log_archive_format='arch_test_%t_%s_%r.arc'

*.memory_target=3348103168

*.open_cursors=300

*.processes=350

*.remote_listener='test-cluster-scan:1521'

*.remote_login_passwordfile='exclusive'

*.sessions=390

test2.thread=2

test1.thread=1

test2.undo_tablespace='UNDOTBS2'

test1.undo_tablespace='UNDOTBS1'

*.utl_file_dir='/log/logminer'


변경 후

test.__db_cache_size=1459617792

test.__java_pool_size=16777216

test.__large_pool_size=33554432

test.__oracle_base='/app/oracle'#ORACLE_BASE set from environment

test.__pga_aggregate_target=1342177280

test.__sga_target=2013265920

test.__shared_io_pool_size=0

test.__shared_pool_size=469762048

test.__streams_pool_size=0

*.audit_file_dest='/app/oracle/admin/test/adump'

*.audit_trail='db'

*.cluster_database=false

*.compatible='11.2.0.4.0'

*.control_files='+DATA/test/controlfile/current.260.923661671'

*.db_block_size=8192

*.db_create_file_dest='+DATA'

*.db_domain=''

*.db_name='test'

*.db_recovery_file_dest='+DATA'

*.db_recovery_file_dest_size=7423918080

*.diagnostic_dest='/app/oracle'

*.dispatchers='(PROTOCOL=TCP) (SERVICE=testXDB)'

test.instance_number=1

#test2.instance_number=2

*.log_archive_dest_1='LOCATION=/archive'

*.log_archive_format='arch_test_%t_%s_%r.arc'

*.memory_target=3348103168

*.open_cursors=300

*.processes=350

#*.remote_listener='test-cluster-scan:1521'

*.remote_login_passwordfile='exclusive'

*.sessions=390

#test2.thread=2

test.thread=1

#test2.undo_tablespace='UNDOTBS2'

test.undo_tablespace='UNDOTBS1'


 * Diag 파일 경로 생성,

 * Archive log 경로 생성 or 변경, 

 * db_nique_name, service_name 변경

 * cluster parameter 변경

 * SGA,PGA TEST DB에 맞게 변경.


새로 생성한 pfile을 이용해 DB를 nomount로 open 합니다.



3. Control file 복원



$ export ORACLE_SID=test

$ rman target /

RMAN> restore controlfile from ‘백업파일이 있는 경로/파일.bkp’;

RMAN> restore controlfile from '/work/rman/0rrijm6l_1_1_20161017.bkp';


Starting restore at 23-OCT-16

using channel ORA_DISK_1


channel ORA_DISK_1: restoring control file

channel ORA_DISK_1: restore complete, elapsed time: 00:00:07

output file name=+DATA/test/controlfile/current.256.926006957

Finished restore at 23-OCT-16

성공하면 위와 같이 에러 메시지 없이 완료됩니다. (역시 어떤 백업 파일에 있는지 모르니 될떄까지 파일을 선택해 봐야 합니다.)

RMAN> alter database mount;

데이터베이스를 Mount 합니다.

RMAN> alter database mount;


database mounted

released channel: ORA_DISK_1


RMAN>



4. 패스워드 파일 복사



scp orapwtest1 ‘복구할DB’:/oracle/app/oracle/product/11.2.0.4/db_1/dbs/orapwtest



5. 데이터 파일 복구



RMAN> catalog start with '백업파일이 있는 경로';

RMAN> CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/work/rman/%U_%T.bkp';

RMAN> CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/work/rman/%U_%T.bkp';

RMAN> CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/work/rman/%U_%T.bkp';

RMAN> CONFIGURE CHANNEL 4 DEVICE TYPE DISK FORMAT '/work/rman/%U_%T.bkp';


RMAN> catalog start with '/work/rman/';


searching for all files that match the pattern /work/rman/


List of Files Unknown to the Database

=====================================

File Name: /work/rman/0rrijm6l_1_1_20161017.bkp

File Name: /work/rman/0prijlsh_1_1_20161017.bkp

File Name: /work/rman/0srijm73_1_1_20161017.bkp

File Name: /work/rman/0qrijlsp_1_1_20161017.bkp


Do you really want to catalog the above files (enter YES or NO)? yes

cataloging files...

cataloging done


List of Cataloged Files

=======================

File Name: /work/rman/0rrijm6l_1_1_20161017.bkp

File Name: /work/rman/0prijlsh_1_1_20161017.bkp

File Name: /work/rman/0srijm73_1_1_20161017.bkp

File Name: /work/rman/0qrijlsp_1_1_20161017.bkp


RMAN> restore database;      


Starting restore at 23-OCT-16

using channel ORA_DISK_1


channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to +DATA/test/datafile/system.256.923661571

channel ORA_DISK_1: restoring datafile 00002 to +DATA/test/datafile/sysaux.257.923661571

channel ORA_DISK_1: restoring datafile 00003 to +DATA/test/datafile/undotbs1.258.923661573

channel ORA_DISK_1: restoring datafile 00004 to +DATA/test/datafile/users.259.923661573

channel ORA_DISK_1: restoring datafile 00005 to +DATA/test/datafile/example.264.923661707

channel ORA_DISK_1: restoring datafile 00006 to +DATA/test/datafile/undotbs2.265.923661973

channel ORA_DISK_1: restoring datafile 00007 to +DATA/test/datafile/test01.269.924548909

channel ORA_DISK_1: reading from backup piece /work/rman/0qrijlsp_1_1_20161017.bkp

channel ORA_DISK_1: piece handle=/work/rman/0qrijlsp_1_1_20161017.bkp tag=TAG20161017T161729

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:18:05

Finished restore at 23-OCT-16


RMAN> recover database;


Starting recover at 23-OCT-16

using channel ORA_DISK_1


starting media recovery


channel ORA_DISK_1: starting archived log restore to default destination

channel ORA_DISK_1: restoring archived log

archived log thread=2 sequence=473

channel ORA_DISK_1: restoring archived log

archived log thread=1 sequence=239

channel ORA_DISK_1: reading from backup piece /work/rman/0srijm73_1_1_20161017.bkp

channel ORA_DISK_1: ORA-19870: error while restoring backup piece /work/rman/0srijm73_1_1_20161017.bkp

ORA-19504: failed to create file "/archive/arch_test_2_473_923661675.arc"

ORA-27040: file create error, unable to create file

Linux-x86_64 Error: 13: Permission denied

Additional information: 1


failover to previous backup

RMAN-00571: ===========================================================

RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============

RMAN-00571: ===========================================================

RMAN-03002: failure of recover command at 10/23/2016 17:28:31

RMAN-20506: no backup of archived log found

RMAN-06053: unable to perform media recovery because of missing log

RMAN-06025: no backup of archived log for thread 1 with sequence 239 and starting SCN of 4539696 found to restore

RMAN-06025: no backup of archived log for thread 2 with sequence 473 and starting SCN of 4539693 found to restore


RMAN> alter database open resetlogs;

database opened


$ sqlplus / as sysdba


SQL*Plus: Release 11.2.0.4.0 Production on Sun Oct 23 17:32:51 2016


Copyright (c) 1982, 2013, Oracle.  All rights reserved.



Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, Automatic Storage Management, OLAP, Data Mining

and Real Application Testing options


SQL> select open_mode from v$database;


OPEN_MODE

--------------------

READ WRITE


SQL>


Oracle 18c 설치 Single

오라클 18c가 릴리즈 되었는데 설치 방법이 약간 바뀌었다.


18c는 2018.08.21 기준, 리눅스와 솔라리스 버전만 릴리즈 되었다.



해당 예제는 리눅스 7버전에 설치를 진행 한다.



리눅스 7의 Oracle 설치를 위한 기본 설치 패키지



Server with GUI

Hardware Monitoring Utilities

Large Systems Performance

Network file system client

Performance Tools

Compatibility Libraries

Development Tools


# vi /etc/hosts


# yum update -y




자동 셋업


# yum install -y install oracle-database-preinstall-18c




수동 셋업


# vi /etc/sysctl.conf


fs.file-max = 6815744

kernel.sem = 250 32000 100 128

kernel.shmmni = 4096

kernel.shmall = 1073741824

kernel.shmmax = 4398046511104

kernel.panic_on_oops = 1

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048576

net.ipv4.conf.all.rp_filter = 2

net.ipv4.conf.default.rp_filter = 2

fs.aio-max-nr = 1048576

net.ipv4.ip_local_port_range = 9000 65500



# vi /etc/security/limits.d/oracle-database-preinstall-18c.conf


oracle   soft   nofile    1024

oracle   hard   nofile    65536

oracle   soft   nproc    16384

oracle   hard   nproc    16384

oracle   soft   stack    10240

oracle   hard   stack    32768

oracle   hard   memlock    134217728

oracle   soft   memlock    134217728



패키지 설치 목록


# OL6 and OL7 (RHEL6 and RHEL7)

yum install -y bc    

yum install -y binutils

yum install -y compat-libcap1

yum install -y compat-libstdc++-33

yum install -y compat-libstdc++-33.i686

yum install -y elfutils-libelf.i686

yum install -y elfutils-libelf

yum install -y elfutils-libelf-devel.i686

yum install -y elfutils-libelf-devel

yum install -y fontconfig-devel

yum install -y glibc.i686

yum install -y glibc

yum install -y glibc-devel.i686

yum install -y glibc-devel

yum install -y ksh

yum install -y libaio.i686

yum install -y libaio

yum install -y libaio-devel.i686

yum install -y libaio-devel

yum install -y libX11.i686

yum install -y libX11

yum install -y libXau.i686

yum install -y libXau

yum install -y libXi.i686

yum install -y libXi

yum install -y libXtst.i686

yum install -y libXtst

yum install -y libgcc.i686

yum install -y libgcc

yum install -y librdmacm-devel

yum install -y libstdc++.i686

yum install -y libstdc++

yum install -y libstdc++-devel.i686

yum install -y libstdc++-devel

yum install -y libxcb.i686

yum install -y libxcb

yum install -y make

yum install -y nfs-utils

yum install -y net-tools

yum install -y python

yum install -y python-configshell

yum install -y python-rtslib

yum install -y python-six

yum install -y smartmontools

yum install -y sysstat

yum install -y targetcli

yum install -y unixODBC



그룹 및 유저 추가


# groupadd -g 54321 oinstall

# groupadd -g 54322 dba

# groupadd -g 54323 oper


# useradd -u 54321 -g oinstall -G dba,oper oracle




추가 세팅



SELinux 설정


# vi /etc/selinux/config


SELINUX=permissive


# setenforce Permissive

※ 리눅스 7 버전은 SELinux 설정 후 재구동 필요없음.



방화벽 Off


# systemctl stop firewalld

# systemctl disable firewalld



디렉토리 생성


# mkdir -p /u01/app/oracle/product/18.0.0/dbhome_1

# mkdir -p /u02/oradata

# chown -R oracle:oinstall /u01 /u02

# chmod -R 775 /u01 /u02


* u01 - 엔진

* u02 - 데이터



프로파일 설정


기존의 방식대로 해도 되고, 

아래는 18c 부터 오라클이 제공하는 방식을 설명한다.


$ mkdir /home/oracle/scripts


$ touch /home/oracle/scripts/setEnv.sh


$ cat > /home/oracle/scripts/setEnv.sh <<EOF

# Oracle Settings

export TMP=/tmp

export TMPDIR=\$TMP


export ORACLE_HOSTNAME=ol7-183.localdomain

export ORACLE_UNQNAME=cdb1

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=\$ORACLE_BASE/product/18.0.0/dbhome_1

export ORA_INVENTORY=/u01/app/oraInvenotry

export ORACLE_SID=cdb1

export PDB_NAME=pdb1

export DATA_DIR=/u02/data


export PATH=/usr/sbin:/usr/local/bin:\$PATH

export PATH=\$ORACLE_HOME/bin:\$PATH


export LD_LIBRARY_PATH=\$ORACLE_HOME/lib:/lib:/usr/lib

export CLASSPATH=\$ORACLE_HOME/jlib:\$ORACLE_HOME/rdbms/jlib

EOF


$ echo ". /home/oracle/scripts/setEnv.sh" >> /home/oracle/.bash_profile



시작, 종료 스크립트 작성


$ touch /home/oracle/scripts/start_all.sh

$ touch /home/oracle/scripts/stop_all.sh


$ cat > /home/oracle/scripts/start_all.sh <<EOF

#!/bin/bash

. /home/oracle/scripts/setEnv.sh


export ORAENV_ASK=NO

. oraenv

export ORAENV_ASK=YES


dbstart \$ORACLE_HOME

EOF



$ cat > /home/oracle/scripts/stop_all.sh <<EOF

#!/bin/bash

. /home/oracle/scripts/setEnv.sh


export ORAENV_ASK=NO

. oraenv

export ORAENV_ASK=YES


dbshut \$ORACLE_HOME

EOF



$ chown -R oracle.oinstall /home/oracle/scripts

$ chmod u+x /home/oracle/scripts/*.sh


설치 완료후에 /etc/oratab에 넣어주고, 오라클 유저로 시작/종료 할 수 있다.


~/scripts/start_all.sh

~/scripts/stop_all.sh



엔진 설치


Oracle 홈페이지에서 LINUX.X64_180000_db_home.zip 파일을 받을 수 있다.


해당 파일을 반드시 /u01/app/oracle/product/18.0.0/dbhome_1 폴더로 옮겨서 압축을 푼다.


$ cd /u01/app/oracle/product/18.0.0/dbhome_1



X매니저 나 Gnome 환경에서 GUI 방식으로 설치 한다.


$ ./runInstaller




엔진 설치 완료


DBCA는 12c와 동일하다.

CBO 와 바인드 변수, 바인드 피크

바인드 변수


바인드 변수의 장점 : 구문이 길고 조건만 다른 SQL문들을 한 개로 정리할 수 있다.

  -> 공유 풀 내의 메모리 사용량을 줄인다.

  -> 하드 파스 발생률을 줄인다.


일반적인 OLTP 시스템에서는 바인드 변수를 사용해 SQL을 작성하는 것이 필수. 따라서 옵티마이저가 바인드 변수를 어떻게 취급하는지 이해하는 것은 매우 중요한 부분.


예전버전의 오라클에서는 바인드 변수를 사용한 SQL문에서 선택도를 구하기 위해 내부에 저장된 기본값을 사용했지만, 9i 이후 버전에서는 '바인드 피크 (bind peek)'라고 하는 기능을 사용되고 있기 때문에 바인드 피크의 작동 방식을 반드시 알아두어야 한다.



바인드 피크


9i 이후 버전에서는 바인드 피크 기능이 켜져있다. 이전 버전에서는 조건절에 바인드 변수가 있을시 내부 기본값으로 행의 선택도를 결정하는데, 내부 기본값과 실제 데이터의 분포에 차이가 있으면 적절치 못한 실행 계획을 선택할 가능성이 높다.


바인드 피크란 옵티마이저가 실행 계획을 생성할 때 바인드 변수에 설정된 실제 값을 '엿보는(peek)' 기능이다. 이 기능을 이용해 리터럴 SQL을 사용할 때 처럼 값의 분포를 고려한(히스토그램도 이용) 행의 선택도를 계산할 수 있다. 사용자가 지정한 실제 값과 통계를 이용하기 때문에 좀 더 적절한 실행 계획을 선택할 수 있게 된다.


바인드 피크를 이용하게 되면, 바인드 변수를 이용한 조건절이 해당 테이블 안에 10만건이 존재 했을 경우 (전체의 10%), 10%를 히트 함으로 테이블 풀스캔을 선택한다. 같은 SQL 문에서 1만건 밖에 존재하지 않는 조건(전체의 1%)을 검색 했을 때도 10%조건에 최적화된 공유 커서가 이미 존재 하고 있어, 해당 실행계획을 다시 사용한다. 그렇지만 1%를 위해 풀스캔을 하는 것은 부적절하다. Shared Pool을 Flush 하고 다시 1% 조건을 실행 해보면 인덱스 액세스 패스를 사용한다. 이렇게 조건절의 데이터 차이가 심한 경우에는 바인드 피크를 끄는 경우가 좋을 수도 있다. 


 ● 바인드 변수를 사용 하는 목적은 같은 구문을 가진 SQL의 실행 계획을 한개로 처리하여 자원 사용의 효율을 향상하는 것에 있다.

 ● 모든 바인드값에 최적인 실행계획이 한 개일 수는 없으며, 현실적으로 사용자가 사용하는 '대부분'의 값을 좋게 만드는 성능이 있다면 사용해야 한다.

 ● 한 개의 실행계획이 '대부분'의 요구를 만족하지 못할 때 실행 계획을 여러 개로 만들 필요가 있다. 이 경우에는 리터럴로 만드는 것이 적절.

  - DW 시스템에서는 적합함

  - OLTP 시스템에서는 이런 SQL문을 가능하면 적게 할 필요가 있음.

 ● 바인드 피크를 사용할 때 예외적인 값이 입력되어 엉뚱한 실행 계획이 도출될 가능성이 있으며, '대부분'에 해당하는 값을 가져오기 위한 성능을 악화시킬수 있음. 단, '대부분'의 값에 맞춰 최적화됐을 경우, 바인드 피크가 꺼져 있을 때에는 얻을수 없었던 뛰어난 효율성을 가진 실행 계획이 도출될 가능성이 있음.

  - 특히 범위 검색의 경우

  - 히스토그램이 존재하고 있을때는 '='조건에서도 해당함.

 ● 바인드 피크를 끄면 최적 실행 계획이 도출될 확률은 줄어들지만, 실행 계획이 변경되는 위험도 그만큼 적다.

  - '=' 조건 검색은 1/NDV를 선택도로 사용하므로, 히스토그램이 없는 상태의 리터럴 SQL과 같음.

  - 범위 검색의 기본 선택도는 5%이므로 그나마 인덱스를 자주 사용하게 됨

  - 인덱스나 조인 순서를 선택할 때 최적의 선택을 하지 못할 가능성이 있음. 그 경우엔 힌트를 사용해 강제로 해야 할 필요가 있음.


바인드 피크 기능을 끄려면 _OPTIM_PEEK_USER_BINDS 파라미터를 FALSE로 변경. 



※ 바인드 변수와 EXPLAIN PLAN


EXPLAIN PLAN 이나 AUTOTRACE에서는 바인드 피크가 수행되지 않으므로 실제와 다른 실행계회이 도출되는 경우가 있음. 바인드 변수를 사용한 SQL의 실행 계획을 확인 하기 위해서는 SQL 트레이스나 V$SQL_PLAN을 사용.

'ORACLE > Operation & Admin' 카테고리의 다른 글

Datafile Resize 계산하기  (0) 2018.10.18
Listener password  (0) 2018.10.14
CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17
Oracle 8i Startup, shutdown  (0) 2018.04.09
ASM  (0) 2018.03.12
Hint 정리  (0) 2017.12.18

12c RMAN Default Configuration

$ rman target /


Recovery Manager: Release 12.2.0.1.0 - Production on Tue Apr 10 14:45:06 2018


Copyright (c) 1982, 2017, Oracle and/or its affiliates.  All rights reserved.


connected to target database: NRIS12C (DBID=4230429196)


RMAN> show all;


using target database control file instead of recovery catalog

RMAN configuration parameters for database with db_unique_name NRIS12C are:

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default

CONFIGURE BACKUP OPTIMIZATION OFF; # default

CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default

CONFIGURE CONTROLFILE AUTOBACKUP ON; # default

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default

CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default

CONFIGURE MAXSETSIZE TO UNLIMITED; # default

CONFIGURE ENCRYPTION FOR DATABASE OFF; # default

CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default

CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default

CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default

CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default

CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/12.2.0.1/db_1/dbs/snapcf_nris12c1.f'; # default



CONFIGURATIONS



RETENTION POLICY [TO NONE | TO RECOVERY WINDOW OF integer DAYS | TO REDUNDANCY integer]


얼마나 많은 full 혹은 0 백업과 control file 을 보관할지 설정한다.

만약 위의 백업이 설정된 값을 초과하면 초과된 과거의 백업은 obsolete (불필요) 한 것으로 판단한다.

기본 retention policy 는 redundancy 1 이다.

RETENTION POLICY 는 REDUNDANCY, RECOVERY WINDOW 이렇게 두 타입이 있다.


TO RECOVERY WINDOW OF integer DAYS는 시간 기반으로 RMAN에서 복구할수 있는 옵션이다. Time Window는 최근 시간부터 복구점을 가지고 늘어난다. 복구점은 integer 옵션의 값에 해당하는 기간의 어느시점으로도 복원이 가능함을 보장한다.


RETENTION POLICY 는 몇 벌의 백업본을 보관할지 정한다. 증분백업을 사용하는 경우 0 백업과 1 백업이 한벌의 백업본이다.



BACKUP OPTIMIZATION [ON | OFF | CLEAR]


동일한 파일이나 동일한 버전의 파일이 이미 백업되어 있는 특정한 환경에서 해당하는 백업을 스킵하는 기능이다.

같은 파일임을 판단하는 기준

Datafile : 반드시 동일한 DBID, checkpoint SCN, creation SCN, RESETLOGS SCN 과 시간을 가져야 한다.

           데이터 파일은 반드시 offline-normal, read-only 혹은 일반적으로 closed 된 상태이어야 한다.

Archived log : DBID, thread, sequence number 그리고 RESETLOGS SCN 과 시간이 동일해야 한다.



DEFAULT DEVICE TYPE TO [BACKUP TYPE TO [[COMPRESSED]BACKUPSET | COPY]] [PARALLELISM integer]


DEVICE TYPE : Backup의 기본 저장소로 disk 에 할지 sbt에 할지 정한다.

BACKUP TYPE TO : 백업 타입을 정한다. BACKUPSET으로 묶을수 있고, COMPRESSED 옵션으로 압축할 수 있다. 

                 COPY 옵션은 image copy를 하겠다는 의미이다. SBT 장치에는 COPY 옵션이 먹히지 않는다. 

PARALLELISM : 값으로 병렬 처리 할 수 있다.



CONTROLFILE AUTOBACKUP [ON | OFF | CLEAR]


ON / OFF 두가지 값을 가질 수 있다. 기본 값은 OFF 이다.

ON 으로 사용하는 경우 RMAN 이 control file 과 server parameter file 을 자동으로 백업한다. 

자동백업은 backup record 가 추가될 때 일어난다. 

Database 가 ARCHIVELOG 모드이면, controlfile 의 database structure metadata 가 변경될때마다 자동백업을 한다.


자동백업을 하는 경우

  - Backup 혹은 Copy 가 정상적으로 완료되었을 때

  - RMAN 프롬프트 상에서 CREATE CATALOG 가 정상적으로 완료되었을 때

  - control file 에 변경을 일으키는 경우 (DB 의 구조적인 변화들)



CONTROLFILE AUTOBACKUP FORMAT


CONTROLFILE AUTOBACKUP ON 인 경우 어떤 포맷으로 파일을 생성할지 정한다.

기본적으로 %F 를 가져가는데 이것의 의미는 다음과 같다.


%F -> c-IIIIIIIIII-YYYYMMDD-QQ


IIIIIIIIII    DBID

YYYYMMDD      백업이 생성 된 날의 time stamp

QQ            00 ~ FF 까지의 값을 가지는 십육진수 시퀀스


configure controlfile autobackup format [for device type {disk|sbt}] to ‘?/oradata/cf_%F’|’+dgroup1/%F’}

위와 같이 device type 별로 포맷을 달리 가져갈 수 있으며, Device type 도 선택가능하다.

 


DEVICE TYPE DISK PARALLELISM n BACKUP TYPE TO BACKUPSET


CONFIGURE DEVICE TYPE {sbt|disk} parallelism n [ backup type to {[compressed] backupset | copy} ];

위 설정을 통해 병렬도 할당이 가능하며, 이는 특정 Device type 에 대해서도 할당 가능하다.

backup type 은 backupset 과 copy 가 있으며, backupset 은 압축기능 (compressed) 이 사용 가능하다.

 


DATAFILE BACKUP COPIES


백업본을 중복으로 몇 벌 가질지 셋팅하는 값이다. 이 파라미터는 backupsets 에만 영향을 주며, image copies 에는 아무런 영향이 없다.

기본값은 1이다.

샘플은 다음과 같다.



Makes 2 disk copies of each datafile and control file backup set

# (autobackups excluded)

CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;


# Makes 3 copies of every archived redo log backup to tape

CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 3;


 

ARCHIVELOG BACKUP COPIES


앞서 살펴 본 DATAFILE BACKUP COPIES 와 같은 역할을 한다.



MAXSETSIZE


채널에서 생성되는 backup sets 의 사이즈를 제한한다.

 


ENCRYPTION FOR DATABASE


암호화 기능으로 그 대상은 데이터베이스 파일, 테이블 스페이스가 될 수 있으며 어떤 알고리즘을 사용할지 지정할 수 있다.

인자값으로 ON | OFF 를 사용한다.



ENCRYPTION ALGORITHM


여기에 셋팅한 값은 ENCRIPTION FOR DATABASE 를 ON 으로 사용한 경우 적용되며 사용가능한 알고리즘은 V$RMAN_ENCRYPTION_ALGORITHMS 에 리스팅되어 있다. 

기본값은 AES 128-bit 이다.



COMPRESSION ALGORITHM


11.1 이상은 zlib 가 기본 값이었으며, 11g 앞 버전은 bzip2 가 기본이었고 유일한 선택이었다.

12c에서 조회를 해보면 알고리즘과 몇버전까지 지원하는지 압축률은 어떤지 확인 할 수 있다.


SQL> select ALGORITHM_ID "ID", ALGORITHM_NAME, INITIAL_RELEASE, TERMINAL_RELEASE, 

     ALGORITHM_DESCRIPTION, ALGORITHM_COMPATIBILITY

     from v$rman_compression_algorithm;




ARCHIVELOG DELETION POLICY


기본값은 ‘NONE’ 이다. 아카이브를 자동으로 삭제하지 않는다.


다음의 예는 logs 가 테잎에 최소 두번 백업되었을 때 FRA 와 Local archiving destinations 에서 삭제될 수 있다.


configure archivelog deletion policy to backed up 2 times to sbt;


TO APPLIED ON [ALL] STANDBY 옵션을 사용하면 데이터 가드에서 스탠바이 DB에 적용된 아카이브를 자동으로 삭제한다.




SNAPSHOT CONTROLFILE NAME


controlfile 의 snapshot 을 저장할 위치를 지정한다.




RMAN OUTPUT TO KEEP FOR integer DAYS

sqlplus에서 RMAN 백업에 대한 로그를 확인할수 있는 뷰 2개가 있는데 RC_RMAN_OUTPUT과 V$RMAN_OUTPUT 이다. interger 옵션에 숫자를 정해두면 몇일치를 보관할지 설정할 수 있다.

CONFIGURE RMAN OUTPUT TO KEEP FOR 0 DAYS;

0으로 설정하면 해당 뷰들에 기록을 하지 않는다.





※ Initialize Configurations


RMAN> configure retention policy clear;


위와 같이 환경변수에 대해 clear 를 사용하면 기본 값으로 변경된다.

일부 변수에 대해서는 none 을 사용할 수 있는데 의미가 달라진다.

예를 들어 아래의 경우


CONFIGURE RETENTION POLICY TO NONE;


이는 TO CLEAR 를 지정한 것과 다른 의미를 가진다.

위의 구문은 REDUNDANCY POLICY 를 두지 않겠다는 것이며, 이는 백업본을 삭제하지 않고 쭉 가지고 있겠다란 뜻이다.

Oracle 8i Startup, shutdown

* Oracle 8i startup


$svrmgrl


SVRMGRL>connect internal


SVRMGRL>startup


SVRMGRL>exit


$lsnrctl start




* Oracle 8i shutdown


$lsnrctl stop


$svrmgrl


SVRMGRL>connect internal


SVRMGRL>shutdown (or shutdown immediate)


SVRMGRL>exit

'ORACLE > Operation & Admin' 카테고리의 다른 글

Listener password  (0) 2018.10.14
CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17
Oracle 8i Startup, shutdown  (0) 2018.04.09
ASM  (0) 2018.03.12
Hint 정리  (0) 2017.12.18
CBO와 히스토그램 정리  (0) 2017.12.07

ASM

ASM이란?


ASM은 데이터베이스 구성 시 기본이 되는 디스크를 효율적으로 관리하기 위하여 오라클 10g에서 새로 선보인 데이터베이스 서비스이다. ASM은 하나의 SMP 장비뿐만 아니라 클러스터를 구성하는 모든 노드들에 대해서도 지원이 가능하다. ASM이 관리하는 모든 디스크에 대한 업무 분산 작업을 자동적으로 처리해 줌으로써 특정 디스크에 로드가 집중되는 핫 스팟(hot spot)현상을 최소할 수 있으며 이로 인해 성능을 극대화할 수 있다. 또한 데이터가 디스크에 균등한 크기로 저장 관리되어 fragmentation 현상이 발생하지 않는다. 그리고 ASM이 관리하는 영역에서 새로운 디스크가 추가되거나 삭제될 때마다, 기존 데이터들에 대해 재구성 작업이 자동적으로 일어난다. 또한 ASM은 특정 데이터에 대한 복사본을 자기 자신의 디스크에 유지할 수 있기 때문에 소프트웨어 미러링 효과를 볼 수 있다.

 

RAC 환경에서의 ASM 인스턴스


RAC 데이터베이스처럼 ASM 인스턴스들도 자체적으로 클러스터링을 할 수 있다. 이는 이미 셋업이 되어 있는 DLM 체계를 사용해서 가능한 것이다. 일반적으로 클러스터를 이루는 하나의 노드에는 하나의 ASM 인스턴스가 뜨도록 구성한다. 그리고 RAC 구성처럼 ASM 인스턴스가 관리하는 디스크는 모든 노드에서 인식 가능하도록 구성해야 한다. 데이터베이스 인스턴스는 오직 동일 노드에 있는 ASM 인스턴스와 상호 통신하게 된다. 만약 동일 노드에 서로 다른 데이터베이스 인스턴스가 존재할 경우, 그들은 그 노드에 있는 하나의 ASM 인스턴스를 공유하게 되는 것이다.

 

특정 디스크 그룹은 서로 다른 데이터베이스 파일을 저장할 수 있다. 이처럼 RAC 환경이 아닌 상태에서 서로 다른 데이터베이스가 동일한 디스크 그룹에 접근하는 것이 가능하다. 또한 하나의 데이터베이스는 동일한 ASM 인스턴스에 의해 관리되는 여러 개의 디스크 그룹에 그 데이터베이스 파일을 저장할 수도 있다.



Scalability

ASM imposes the following limits:

  • 63 disk groups in a storage system
  • 10,000 ASM disks in a storage system
  • 4 petabyte maximum storage for each ASM disk
  • 40 exabyte maximum storage for each storage system
  • 1 million files for each disk group
  • Maximum files sizes as shown in the following table:

Disk Group Type

Maximum File Size

External redundancy

35 TB

Normal redundancy

5.8 TB

High redundancy

3.9 TB

 

 

ASM을 설치하기 위한 최소 설정


1.     ASM에 사용할 디스크가 필요합니다.

2.     커널 버전에 맞는 ASMLib 파일이 필요합니다.

3.     Initialization Parameters for ASM Instances

4.     수동으로 ASM을 구성을 위해 init파일을 작성을 합니다. 최소 다음의 내용을 작성해야 합니다.

 

Name

Description

INSTANCE_TYPE

Type은 반드시 ASM으로 구성해야 합니다.

 

Note: 반드시 포함되어야 하는 최소한의 옵션입니다.모든 변수에서 기본이 되는 값입니다.

ASM_POWER_LIMIT

디스크의 기본이 되는 power해당되는 값입니다.

Default: 1, Range: 0 11

 

See Also: "Tuning Rebalance Operations"

ASM_DISKSTRING

ASM_DISKSTRING 디스크의 순서를 생각 할 수 있습니다. Diskstring을 아래와 같이 기재하면 자동으로 인식하게 됩니다.

/dev/rdsk/*

/dev/rdsk/*s3,/dev/rdsk/*s4

위의 내용을 다음과 같이 간단히 할 수도 있습니다.:

/dev/rdsk/*s[34]

기본 값은 NULL이고 필수사항이 아닙니다기재하지 않으면 기본값으로 설정됩니다.

 

See Also: "Improving Disk Discovery Time"

ASM_DISKGROUPS

ASM instance 시작 시에 자동으로 Mount할 디스크 그룹의 목록을 기재하는 항목입니다. 기본 값은 NULL입니다. 만일 설정값에 아무 값도 없다면 no disk 상태로 마운트됩니다. 설정 값이 static이 아닌 dynamic으로 되어 있기 때문에 spfile에 기록해서 자동으로 ASM에 추가할 수도 있습니다.

 

Note: Issuing the ALTER DISKGROUP...ALL MOUNT or ALTER DISKGROUP...ALL DISMOUNTcommand does not affect the value of this parameter.

 

 

 

 


 

ASM의 장점들

 

1. 디스크 I/O의 효과적인 분산

스토리지를 추가하면 이전 스토리지안에 있던 자료들이 자동으로 rebalance되어서 자료들이 분산됩니다.

 

2. VLDB지원(Very Large DB)

 

 

ASM Disk Group


ASM에서는 디스크를 여러개 묶어서 디스크 그룹으로 관리하는데, 1개의 그룹에는 최소 2개의 디스크가 있어야 합니다.

데이터가 들어올 때 AU라는 단위로 나누어서 각 디스크그룹별로 분산해서 저장하게 되는데,

AU(Allocation Unit)

   1) COARSE grained 방식 : 1MB단위로 기록되고, 주로 data, archivelog 파일에 사용

   2) FINE grained 방식 : 128KB단위로 기록되고, 주로 redo, control, flashback log 파일에 사용

의 두가지 옵션을 가집니다.

(11g  ASM부터는 AU의 종류가 1/2/4/8/16/32/64 MB로 다양하게 지원되어,

DB운영계획에 따라 적절히 지정하여 성능개선을 할 수 있습니다.)

 

 

Rebalance


Filesystem을 사용하게 되면 디스크그룹 내에 새 디스크가 추가되거나 제거되면 성능개선을 하기 위해서는

DBA가 직접 기존 디스크의 내용을 분산하거나, 이동시켜야 합니다.

 

ASM을 이용하게 되면 이러한 rebalance작업은 자동으로 ASM에서 수행하게 되고,

DB부하에 따라 rebalance에 얼마나 많은 CPU%를 배당할지도 지정할 수 있습니다.

 

alter diskgroup testdb_dg1 add disk '/dev/sdf1' rebalance power 11;

(1~11 : 1 rebalance되는 속도가 가장느리고, 11이 가장 빠름. 11로 갈수록 rebalance하는데 더 많은 CPU부하를 일으킵니다.)

 

 

ASM에서의 Restrict 옵션


관리자가 disk group 유지보수를 하기 위해 restrict 옵션을 제공하고, 이 옵션으로 디스크그룹을 mount할 경우 일반사용자는 접속할 수 없게되어,

유지관리성능을 더 향상시킬 수 있습니다.

alter diskgroup data mount restrict;

   유지보수종료 후 -->  alter diskgroup data dismount;  --> alter diskgroup data mount;


ASM Instance : 디스크그룹에 대한 정보를 수집해서 Database Instance에 제공, ASMB가 교두보역할

      ORACLE_SID=+ASM 으로 해당 인스턴스에 접속해서 mount, shutdown 할 수 있음

RBAL process : 디스크추가 및 삭제 시 디스크그룹에 대한 Rebalance담당, ASM Instance의 요청이 있을 경우 디스크를 열고 닫는 프로세스

ARBn : RBAL의 명령을 받아 실질적으로 작업을 수행하는 process



ASM parameter

instacne_type: ASM (default: rdbms)
db_unique_name: +asm
asm_power+limit: 1(low)~11(high) 설정 가능. ASM 데이터 리밸런싱 속도 조정 레벨 값 (기본값 1)
asm_diskgroups: ASM 인스턴스 시작시 구동되는 디스크 그룹
asm_diskstring: ASM에 사용된 디스크가 포함된 물리적 경로
asm_preferred_read_failure_groups:I/O 실패가 발생한 그룹을 명시.

ASM SGA 및 주요 parameters
 : ASM Instance 를 통해서 입 출력이 되기 때문에 관련 파일과 파라미터들이 있다.
 
주요파라미터
 - db_cache_size : ASM Instance 가 사용할 cache 크기 결정. 오라클권장값 64M
 - shared_pool : ASM Instance를 관리하는 용도로 사용. 오라클권장값 128M
 - Large_pool : Extent Maps 을 저장하는 용도. 오라클권장값 64M
 
※ 참고
$ORACLE_HOME/dbs/init+ASM.ora
내용
 
*.asm_diskgroups='DATA','FRA'
+ASM.asm_diskgroups='DATA','FRA','NEW_ASM'#Manual Mount
*.background_dump_dest='/home/oracle/admin/+ASM/bdump' → alert log file 저장 경로 지정
*.core_dump_dest='/home/oracle/admin/+ASM/cdump' → core dump 를 저장할 경로 지정
*.instance_type='asm'
*.large_pool_size=12M
*.remote_login_passwordfile='SHARED'
*.user_dump_dest='/home/oracle/admin/+ASM/udump'
 
▶ 위 파라미터 외 다른 파라미터를 잘못 지정 할 경우 ORA_15021 에러 발생 - ASM Instance 가 구동 되지 않는다.

col "Parameter Name" for a40
col "Instance Value" for a20

select 
   a.ksppinm "Parameter Name", 
   c.ksppstvl "Instance Value"
from 
   x$ksppi a, 
   x$ksppcv b, 
   x$ksppsv c
where 
   a.indx = b.indx 
and 
   a.indx = c.indx
and 
   ksppinm like '%asm%'
order by 
   a.ksppinm;


Parameter Name Instance Value
---------------------------------------- --------------------
_asm_acd_chunks 1
_asm_admin_with_sysdba FALSE
_asm_allow_appliance_dropdisk_noforce FALSE
_asm_allow_lvm_resilvering TRUE
_asm_allow_only_raw_disks TRUE
_asm_allow_system_alias_rename FALSE
_asm_appliance_config_file
_asm_ausize 1048576
_asm_automatic_rezone TRUE
_asm_avoid_pst_scans TRUE
_asm_blksize 4096
_asm_check_for_misbehaving_cf_clients FALSE
_asm_compatibility 10.1
_asm_dba_batch 500000
_asm_dba_spcchk_thld 20000
_asm_dba_threshold 0
_asm_dbmsdg_nohdrchk FALSE
_asm_diag_dead_clients FALSE
_asm_direct_con_expire_time 120
_asm_disable_amdu_dump FALSE
_asm_disable_async_msgs FALSE
_asm_disable_multiple_instance_check FALSE
_asm_disable_profilediscovery FALSE
_asm_disable_smr_creation FALSE
_asm_disable_ufg_dump FALSE
_asm_disk_repair_time 14400
_asm_emulate_nfs_disk FALSE
_asm_emulmax 10000
_asm_emultimeout 0
_asm_evenread 2
_asm_evenread_alpha 0
_asm_evenread_alpha2 0
_asm_evenread_faststart 0
_asm_fail_random_rx FALSE
_asm_fd_cln_idle_sess_twait 10000000
_asm_fd_cln_on_fg TRUE
_asm_fob_tac_frequency 9
_asm_force_quiesce FALSE
_asm_global_dump_level 267
_asm_hbeatiowait 15
_asm_hbeatwaitquantum 2
_asm_imbalance_tolerance 3
_asm_instlock_quota 0
_asm_iostat_latch_count 31
_asm_kfdpevent 0
_asm_kfioevent 0
_asm_kill_unresponsive_clients TRUE
_asm_libraries ufs
_asm_log_scale_rebalance FALSE
_asm_lsod_bucket_size 67
_asm_max_cod_strides 5
_asm_max_redo_buffer_size 2097152
_asm_maxio 1048576
_asm_partner_target_disk_part 8
_asm_partner_target_fg_rel 4
_asm_primary_load 1
_asm_primary_load_cycles TRUE
_asm_random_zone FALSE
_asm_rebalance_plan_size 120
_asm_rebalance_space_errors 4
_asm_repairquantum 60
_asm_reserve_slaves TRUE
_asm_root_directory ASM
_asm_runtime_capability_volume_support FALSE
_asm_secondary_load 10000
_asm_secondary_load_cycles FALSE
_asm_serialize_volume_rebalance FALSE
_asm_shadow_cycle 3
_asm_skip_rename_check FALSE
_asm_skip_resize_check FALSE
_asm_storagemaysplit FALSE
_asm_stripesize 131072
_asm_stripewidth 8
_asm_sync_rebalance FALSE
_asm_usd_batch 64
_asm_wait_time 18
_asmlib_test 0
_asmsid asm
_ges_diagnostics_asm_dump_level 11
_lm_asm_enq_hashing TRUE
asm_diskgroups DATA, ACFS
asm_diskstring /dev/asm*
asm_power_limit 1
asm_preferred_read_failure_groups


ASM datafile name 변경

ASM에서 Datafile 이름은 랜덤숫자가 붙은 형식으로 끝나는데, 이것을 유저친화적 형식으로 알아보기 쉽게 바꾼다면, alias를 사용해야 한다.
데이터 파일을 바로 생성하는 것이 아닌 기존 파일을 이용한 alias 생성방법.

alter diskgroup disk_group_1 
   add alias 
 '+DISK_GROUP_1/oratst1/datafile/my_system_dbf'
   for 
 '+DISK_GROUP_1/oratst1/datafile/system.1122.764387443';


ASM datafile Copy

$ rman target /

 

Recovery Manager: Release 10.2.0.5.0 - Production on Tue Feb 28 17:50:37 2012

Copyright (c) 1982, 2007, Oracle.  All rights reserved.

connected to target database: TESTDB (DBID=2559693415)

 

RMAN> copy datafile '+DATA/testdb/datafile/ts_new.266.776453331' to '+FRA';

 

Starting backup at 28-FEB-12

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: sid=143 devtype=DISK

channel ORA_DISK_1: starting datafile copy

input datafile fno=00005 name=+DATA/testdb/datafile/ts_new.266.776453331

output filename=+FRA/testdb/datafile/ts_new.260.776454711 tag=TAG20120228T175149 recid=1 stamp=776454711

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03

Finished backup at 28-FEB-12

 

RMAN> copy datafile '+DATA/testdb/datafile/ts_new.267.776453579' to '+FRA';

 

Starting backup at 28-FEB-12

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile copy

input datafile fno=00006 name=+DATA/testdb/datafile/ts_new.267.776453579

output filename=+FRA/testdb/datafile/ts_new.261.776454737 tag=TAG20120228T175217 recid=2 stamp=776454738

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01

Finished backup at 28-FEB-12

 

※ 참고 - 주의!!!!!


 : RMAN에서 복사해주면 경로만 바뀌는게아니라 파일이름도 함께바뀐다. 


SQL> alter database rename file '+DATA/testdb/datafile/ts_new.266.776453331'

  2  to '+FRA/testdb/datafile/ts_new.266.776453331';

alter database rename file '+DATA/testdb/datafile/ts_new.266.776453331'

*

ERROR at line 1: ← 그런파일 없다고 에러난다.

ORA-01511: error in renaming log/data files

ORA-01141: error renaming data file 5 - new file '+FRA/testdb/datafile/ts_new.266.776453331' not found

ORA-01110: data file 5: '+DATA/testdb/datafile/ts_new.266.776453331'

ORA-17503: ksfdopn:2 Failed to open file +FRA/testdb/datafile/ts_new.266.776453331

ORA-15173: entry 'ts_new.266.776453331' does not exist in directory 'datafile'


▶ 위의 copy과정에 진하게 표시해 놓은 부분을 보면 +FRA로 경로가 이동된 파일의 파일 이름도 달라 졌음을 확인할 수 있다. 



ASM에서 pfile 수정


os filesystem 에다가 만든 pfile 을 수정하고 다시 asm 저장공간에 spfile로 만들려면 


SQL> create spfile='+DATA' from pfile;

SQL> exit

$asmcmd

asmcmd> ls parameterfile

spfile.260.672234945

spfile.267.776334921 <-- 요걸로 alias 만듬


asmcmd> rmalias spfileasmdb.ora

asmcmd> mkalias +DATA/TESTDB/PARAMETERFILE/spfile.267.776334921 spfiletestdb.ora



ASM 에서 디스크 추가 제거


$ export ORACLE_SID=+ASM

$ sqlplus / as sysasm;

ASM Disk중 사용 안 하는 것 조회

+ASM> 

set line 200
col path for a15

select group_number, mount_status, path, total_mb
from v$asm_disk where mount_status='CLOSED';

ex)
GROUP_NUMBER MOUNT_STATUS   PATH              TOTAL_MB
------------ -------------- --------------- ----------
0               CLOSED            ASM1                 102400
0               CLOSED            ASM2                 102400
0               CLOSED            ASM3                 102400

ASM Disk 추가

+ASM> alter diskgroup data add disk 'ORCL:ASM1' rebalance power 5;

ASM Disk 상태 조회
+ASM> select group_number, disk_number, name, mount_status, path, total_mb from v$asm_disk;

GROUP_NUMBER DISK_NUMBER NAME       MOUNT_STAT PATH              TOTAL_MB
------------ ----------- ---------- ---------- --------------- ----------
           0           4            CLOSED     /dev/raw/raw6           54
           0           5            CLOSED     /dev/raw/raw5          486
           0           6            CLOSED     /dev/raw/raw4          486
           0           7            CLOSED     /dev/raw/raw3          486
           0           8            CLOSED     /dev/raw/raw2          486
           0           9            CLOSED     /dev/raw/raw1          486
           1           0 DATA_0000  CACHED     /dev/raw/raw10      126849
           1           2 DATA_0002  CACHED     /dev/raw/raw8       126849
           1           3 DATA_0003  CACHED     /dev/raw/raw9       126849
           1           1 DATA_0001  CACHED     /dev/raw/raw7       126849
           1           1 ASM1       CACHED     /dev/asm/asm1       102400

ASM2,3 추가

ASM 디스크 상태조회

2) ASM Disk Group에 디스크 추가
+ASM> alter diskgroup DATA add disk 'ASM1' rebalance power 10;
+ASM> alter diskgroup DATA add disk 'ASM2' rebalance power 10;
+ASM> alter diskgroup DATA add disk 'ASM3' rebalance power 10;

3) 13:30 - asm 디스크 삭제 (구 스토리지의 디스크 삭제 후 rebalance)
+ASM> alter diskgroup data drop disk DATA_0000;
+ASM> alter diskgroup data drop disk DATA_0001;
+ASM> alter diskgroup data drop disk DATA_0002;
+ASM> alter diskgroup data drop disk DATA_0003;

명령실행후 diskgroup altered. 메시지가 보여지나 rebalancing 작업이 내부적으로 진행중이며 다음 v$asm_operation view를 통해 ACTIVE한 상태인지 확인할 수 있습니다.

+ASM> select name,header_status,state,free_mb from v$asm_disk;

NAME             HEADER_STATUS            STATE                FREE_MB 
---------------- ------------------------ -------------------- ------------ 
DATA_0000        MEMBER                   NORMAL               126849
DATA_0001        MEMBER                   NORMAL               126849
DATA_0002        MEMBER                   NORMAL               126849
DATA_0003        MEMBER                   DROPPING             126849     → DROP 진행중

내부적 rebalancing 작업이 완료되면 수행중인 OPERATION 이 없어지며 v$asm_disk view에DISK DATA_0003이 없어진 것을 확인할 수 있습니다.


'ORACLE > Operation & Admin' 카테고리의 다른 글

CBO 와 바인드 변수, 바인드 피크  (0) 2018.05.17
Oracle 8i Startup, shutdown  (0) 2018.04.09
ASM  (0) 2018.03.12
Hint 정리  (0) 2017.12.18
CBO와 히스토그램 정리  (0) 2017.12.07
옵티마이저 기본기능  (0) 2017.11.14

Hint 정리

1. 최적화 목표(GOAL) 제어힌트

          

 ALL_ROWS : 쿼리의전체 결과를 모두 수행 하는것에 대한 최적화를 목표로 최저비용의 실행 계획을 수립하도록 유도.


 CHOOSE : 엑세스 하는 테이블의 통계정보 유무에 따라 규칙기준 또는비용기준을 적용하여 최적화 수행.

              통계정보를 참조할 수 있는 경우 ALL_ROWS 방식으로 처리.


 FIRST_ROWS : 최적 응답시간을 목표로 최저 비용의 실행 계획을 수립하도록 유도.


 RULE : 규칙기준 옵티마이져를 이용하여 최적화를 요구.



2. 조인순서 조정을 위한 힌트

          

 ORDERED : FROM절에 기술한 순서대로 조인을 하도록 유도. 

           LEADING 힌트와 함께 쓰면 LEADING힌트는 무시.

           ORDERED는 엑세스 순서만 제시.

           조인방법을 유도하는 힌트. USE_NL,USE_MERGE와 함께 쓰는게 일반적. 

           ex>

           SELECT /*+ ORDERED USE_NL(A,B) */

           FROM TAB1 A , TAB2 B;

  

 LEADING : FROM절의 테이블 순서와 상관없이 조인순서를 제어.

           ex>

           SELECT /*+ LEADING(B,C) */

           FROM TAB1 A , TAB2 B , TAB3 C;

 

 

3. 조인방법 선택용 힌트

          

 USE_NL : NESTED LOOP 조인을 유도하는 힌트. 조인 순서가 아닌 조인 방식을 유도.

  

 NO_USE_NL : NESTED LOOP 조인을 제외한 방식으로 유도. NESTED LOOP가 최적일 경우 무시 가능.

  

 USE_NL_WITH_INDEX : NESTED LOOP 조인에서 외측 루프의 처리주관 인덱스를 지정할때 사용.

  

 USE_HASH : 해쉬 조인 방식으로 수행 되도록 유도.

  

 NO_USE_HASH : 해쉬 조인 방식을 제외한 다른 조인 방식으로 유도.

  

 USE_MERGE : SORT MERGE 조인 방식으로 수행 되도록 유도.

 

 

4. 병렬처리 관련힌트

          

 PARALLEL : 엑세스 할때와 DML 처리할때 SQL의 병렬처리를 유도하는 힌트.

  

 NOPARALLEL : PARALLEL 옵션이 부여된 테이블 엑세스시 해당 테이블의 PARALLEL 파라페터를 무시하고, 병렬처리를 하지 않고 수행 하도록 유도.

  

 PQ_DISTRIBUTE : 병렬 조인의 속도를 향상시키기 위해 슬페이브 프로세스-생산자 와 소비자-프로세스 사이에서 조인할 테이블의 로우를 서로 주고 받는 할당작업의 방법을 정의하는 힌트.

 

 PARALLEL_INDEX : 파티션 인덱스에 대한 인텍스 범위 스캔을 병렬로 수행하기 위한 병렬도를 지정하는 힌트.

 

 NOPARALLEL_INDEX : 병렬 인텍스 범위 스캔을 하지않게 하는 힌트.

 

 

5. 엑세스수단 선택을위한 힌트

          

 FULL : 힌트 내에 정의된 테이블을 풀스캔 방식으로 유도.

  

 HASH : 해쉬 클러스터 테이블을 엑세스 할때 해쉬 스캔 방식으로 유도.

  

 CLUSTER : 클러스터링 테이블 엑세스시 클러스터 인덱스 스캔 방식으로 유도.

  

 INDEX : 인덱스 범위 스캔에 의한 테이블 엑세스를 유도. 뷰의 경우 뷰 내의 테이블의 인덱스 스캔을 지정 할 수도 있다.

  

 NO_INDEX : 지정한 인덱스외에 다른 엑세스를 고려하도록 유도. 테이블만 정의하면 모든 인덱스를 제외.

  

 INDEX_ASC : 인덱스 컬럼값의 오름차순으로 범위스캔 하게 유도.

  

 INDEX_DESC  : 인덱스 컬럼값의 내림차순으로 범위스캔 하게 유도.

  

 INDEX_COMBINE : 2개 이상의 인덱스를 비트맵 인덱스로 변경/결합하여 엑세스 하는 방식으로 유도. 

                        다른 타입의 인덱스도 변경/결합 가능.

  

 INDEX_FFS : 전체범위를 스캔 하는 방식으로 유도. 멀티 블록을 스캔.

  

 INDEX_JOIN : 2개 이상의 인덱스들로 조인을 수행하도록 유도. 인덱스만으로 쿼리를 처리할수 있어야 함.

 

 INDEX_SS : 인덱스 스킵 스캔방식으로 엑세스 하도록 유도.

  

 NO_INDEX_SS : 스킵 스캔을 제외한 다른 엑세스방법을 유도.

  

 INDEX_SS_ASC : 인덱스 스킵 스캔방식으로 스캔 하는 경우 오름차순으로 인덱스를 읽도록 함.

  

 INDEX_SS_DESC : 인덱스 스킵 스캔방식으로 스캔 하는 경우 내림차순으로 인덱스를 읽도록 함.

 

          

6. 쿼리 형태변형을 위한힌트

          

 USE_CONCAT : OR(IN)연산자를 별도의 실행단위로 분리. 각각의 최적 엑세스경로를 수립후 연결 하는 실행 계획을 유도.

                    처리주관 조건이 OR 일경우만 사용가능. 잘못 사용시 비효율 발생.

  

 NO_EXPAND : OR(IN)연산자를 연결실행계획으로 처리되지 않도록 유도.

  

 REWRITE : 쿼리재작성(Query Rewrite)을 실행 하도록 하는 힌트.

           

               주)쿼리재작성(Query Rewrite) 란? 

               쿼리 수행시 테이블 엑세스 방법과 실체 뷰 엑세스 방법중 유리한 것을 선택하도록 쿼리를 변형하는 것.

  

 NO_REWRITE : 쿼리재작성(Query Rewrite)을 하지 않도록 하는 힌트.

  

 MERGE : 뷰 병합이 일어나지 않을때 적용 가능.

           

               주)뷰 병합 이란?

               뷰의 엑세스를 최적화 하기 위해 뷰 쿼리에 사용된 원래 테이블을 최적으로 엑세스하도록 문장을 변형시키는 것.

  

 STAR_TRANSFORMATION : 스타변형조인을 수행하도록 요구하는 힌트.

 

 FACT : 스타변형조인에서 팩트 테이블을 지정하기 위해 사용하는 힌트.

  

 UNNEST : 서브 쿼리와 메인 쿼리를 합쳐 조인 형테로 변형 하도록 하는 실행계획을 유도.

 

          

7. 기타힌트

 

 APPEND : INSERT문에서 사용하는 힌트. INSERT 작업을 'DIRECT-PATH' 방식으로 수행시켜 

              SGA를 거치지 않고 직접 저장 공간에 입력 시킴. APPEND 힌트는 반드시 최고수위점 다음 위치에 데이터를 저장한다.

 

 CACHE : 전체 테이블 스캔 방식으로 읽혀진 블록을 메모리내에 머물수 있도록 하는 힌트. 크기가 작은 테이블에 유용.

 

 NOCACHE : LRU리스트의끝에 위치하도록 유도해서 메모리에서 우선적으로 제거되도록 하는 힌트.

  

 CARDINALITY : 옵티마이져에게 카디널리티 값을 제시하여 실행 계획 수립에 참조하도록 하는 힌트.

 

 CURSOR_SHARING_EXACT : CURSOR_SHARING 과 관련하여 실행계획 공유 비율을 높일수 있다.

 

 DRIVING_SITE : 원격 테이블과 조회시 쿼리가 수행될 사이트를 지정하여 분산쿼리를 최적화하는 힌트.

  

 DYNAMIC_SAMPLING : 통계 정보를 가지고 있지 않을 경우 통계 정보를 동적 표본화 하는 기능을 단위 SQL에 적용하는 힌트.

  

 PUSH_PRED : 뷰 외부의 조인 조건을 뷰쿼리 내로 삽입하는 힌트.

  

 NO_PUSH_PRED : 뷰 외부의 조인 조건을 뷰내로 삽입하지 않도록 함.

  

 PUSH_SUBQ : MERGE 되지 않은 서브쿼리를 최대한 먼저 수행하도록 요구하여 수행 속도를 향상.

           

 QB_NAME : 쿼리 블록에 이름을 부여하여 다른 힌트에서 참조 할 수 있도록 함.

  

 REWRITE_ON_ERROR : 쿼리 재생성을 실행 할 수 없는 경우 ORA-30393 에러를 유발하여 쿼리 수행을 중단시킴.

'ORACLE > Operation & Admin' 카테고리의 다른 글

Oracle 8i Startup, shutdown  (0) 2018.04.09
ASM  (0) 2018.03.12
Hint 정리  (0) 2017.12.18
CBO와 히스토그램 정리  (0) 2017.12.07
옵티마이저 기본기능  (0) 2017.11.14
RMAN 마지막 백업 확인  (0) 2017.04.05

Instance recovery 와 Media Recovery

◆ Instance recovery



- 인스턴스 리커버리는 SMON에 의해서 자동으로 이루어 진다.

- 서버가 갑자기 죽거나, 비정상 적인 DB 종료 상태일때

- Redo 안의 파일을 이용해서 복원을 진행한다.



◆ Media Recovery


 - 미디어 리커버리는 두가지 타입으로 나뉜다

  1) Datafile media recovery

  2) Block media recovery


 - Datafile media recovery 는 컨트롤 파일이나 데이터파일이 깨지거나 손실된것을 복구 하는데 사용.

 - Block media recovery는 모든 데이터 파일안의 개별 블록을 복구하고 복원하는데 사용.



RAC에서 Datafile을 파일시스템 경로에 생성 했을때 ASM으로 이동 방법

◆ RAC에서 Datafile을 파일 시스템 경로에 생성 했을때 ASM으로 이동 방법


TABLESPACE_NAME      FILE_NAME

-------------------- ------------------------------------------------------------

SYSTEM               +DATA/nris/datafile/system.260.960750649

SYSAUX               +DATA/nris/datafile/sysaux.261.960750661

UNDOTBS1             +DATA/nris/datafile/undotbs1.262.960750671

UNDOTBS2             +DATA/nris/datafile/undotbs2.264.960750681

USERS                +DATA/nris/datafile/users.265.960750685

IMSI                 D:\ORADATA\IMSI.DBF


이렇게 잘못 만들었을때 DB는 반드시 문제가 생김.



C:\> rman target /


복구 관리자: Release 11.2.0.4.0 - Production on 화 12월 12 02:03:05 2017


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.


대상 데이터베이스에 접속합니다: NRIS (DBID=3002066671)


RMAN> copy datafile 'D:\ORADATA\IMSI.DBF' to '+DATA';


backup을(를) 17/12/12에서 시작 중

복구 카탈로그 대신 대상 데이터베이스 제어 파일을 사용하고 있습니다.

채널을 할당했습니다: ORA_DISK_1

ORA_DISK_1 채널: SID=63 인스턴스=nris1 장치 유형=DISK

ORA_DISK_1 채널: 데이터 파일 복사 시작 중

입력 데이터 파일 파일 번호=00006 이름=D:\ORADATA\IMSI.DBF

출력 파일 이름=+DATA/nris/datafile/imsi.286.962503455 태그=TAG20171212T020414 RECID=1 STAMP=962503456

ORA_DISK_1 채널: 데이터 파일 복사 완료. 경과 시간: 00:00:03

backup을(를) 17/12/12에서 완료



sqlpus 로 접속해서 


C:\Users\Administrator>sqlplus / as sysdba


SQL*Plus: Release 11.2.0.4.0 Production on 화 12월 12 02:04:40 2017


Copyright (c) 1982, 2013, Oracle.  All rights reserved.



다음에 접속됨:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

Data Mining and Real Application Testing options


SQL> alter database datafile 'd:\oradata\imsi.dbf' offline;


데이타베이스가 변경되었습니다.


SQL> alter database rename file 'D:\oradata\IMSI.dbf' to '+DATA/nris/datafile/imsi.286.962503455';


데이타베이스가 변경되었습니다.


SQL> select tablespace_name, file_name from dba_data_files;


TABLESPACE_NAME      FILE_NAME

-------------------- ----------------------------------------------------------------------

SYSTEM               +DATA/nris/datafile/system.260.960750649

SYSAUX               +DATA/nris/datafile/sysaux.261.960750661

UNDOTBS1             +DATA/nris/datafile/undotbs1.262.960750671

UNDOTBS2             +DATA/nris/datafile/undotbs2.264.960750681

USERS                +DATA/nris/datafile/users.265.960750685

IMSI                 +DATA/nris/datafile/imsi.286.962503455



그리고 

D:\oradata\imsi.dbf 로 가서 예전 데이터파일은 삭제한다.



CBO와 히스토그램 정리

◆ CBO와 히스토그램 정리


 - 기본적으로 옵티마이저는 컬럼값 안에 최소값과 최대값 사이의 값이 균등하게 분포되고, 모든 값은 같은 수만큼 존재 한다고 가정한다. 그러므로 실제 값이 편중되어 있을 때 잘못된 액세스 패스를 선택 할 수 도 있다. 


 - 옵티마이저 통계를 수집할 때 컬럼값 히스토그램을 생성하는 것으로 올바른 액세스 패스를 선택할 가능성을 높일 수 있다. 


 - NDV가 적을 경우 빈도 분포 히스토그램을 만들면 정확한 선택도를 계산 할 수 있다.


 - NDV가 많을 경우에도 높이 균형 히스토 그램을 만들수 있다. 정확성은 분도 빈포 히스토그램보다 떨어지지만, 적절한 액세스 패스를 선택하기 위한 정보는 충분히 얻을 수 있다.



 1) 빈도 분포 히스토그램 (Frequency)


 - 오라클에서는 최대 254개의 버킷을 지정하여 컬럼값 히스토그램을 생성 할 수 있음.

 - 지정한 버킷 수 이하라면 '빈도 분포' 히스토그램이 만들어진다.

 - 빈도분포 히스토그램은 각 값이 몇 건이나 있는지 정확하게 기록 한다.

 - 256 종류 이상 (패킷0을 포함한 255 종류의 값이 기록 가능)의 값을 가진 컬럼에는 생성 불가능.

 - 버킷을 제한 없이 늘리면 히스토그램 생성 시간이 길어지고, 히스토그램 정보가 들어있는 딕셔너리 테이블도 대량으로 소비하게 된다. 



 2) 높이 균형 히스토그램 (Height Balanced)


 - 빈도분포 만큼 정확하지는 않지만, 편중된 값을 검출하기 위해 사용.

 - 정렬한 데이터를 지정한 버킷 수로 순서에 따라 균등하게 입력해 나가며, 각 버킷 마지막 값(ENDPOINT_VALUE)을 기록. 각 버킷에 같은 건수만 들어간다. 여러 버킷의 ENDPOINT_VALUE가 같다면, 이 값이 다른 값들보다 많이 존대 한다는 증거. 이렇게 여러 버킷의 ENDPOINT_VALUE가 되는 값을 '포뮬러값' 이라고 한다.

 - 같은 포뮬러값이 존재 하는 경우, 마지막 버킷 정보만 보관하고, 같은 포뮬러값의 이전 버킷의 정보는 생략.

 - 버킷 0은 특수한 버킷으로 최소값을 나타냄.

 - 마지막 ENDPOINT_VALUE 값은 최대값을 나타냄.

 - 포뮬러값이 존재하는경우 ENDPOINT_NUMBER의 값이 누락 된다. 



 ※ 히스토그램을 사용할 때 주의점


 1) 높이 균형 히스토그램의 경우 '=' 조건으로 포뮬러값 이외의 치우침은 찾아낼 수 없다. 포뮬러값을 찾아내기 위해서는 적절한 사이즈의 버킷수가 필요.


 2) NDV가 적으나 다른 값에 비해 수가 더욱 적은 임의의 값을 검색할 때, 인덱스 액세스를 선택하도록 하고 싶을 경우에는 빈도 분포 히스토그램이 필요.


 3) 문자형 데이터의 경우에는 히스토그램에 칼럼값으로 보관되는 것은 32 Byte까지이며, 첫 글자부터 동일 하게 32 Byte (한글은 16글자) 라면 히스토그램상에서는 같은 값으로 취급한다. 



'ORACLE > Operation & Admin' 카테고리의 다른 글

ASM  (0) 2018.03.12
Hint 정리  (0) 2017.12.18
CBO와 히스토그램 정리  (0) 2017.12.07
옵티마이저 기본기능  (0) 2017.11.14
RMAN 마지막 백업 확인  (0) 2017.04.05
DB의 실패한 로그인 확인하는 방법  (0) 2016.10.06

옵티마이저 기본기능

옵티마이저 기본 기능



1. RBO와 CBO의 차이



 RBO (Rule Based Optimizer) 규칙 기반 옵티마이저


 - Oracle 9i까지 사용하던 방식으로 Oracle 10g서 부터는 지원되지 않는다.


 RBO의 장점 


  1) 기능이 한정적이고 쉽기 때문에 배우기가 쉽다.

  2) 규칙을 외어버리면 튜닝이 쉽다.

  3) 오래전부터 사용된 기능이기 때문에 기존 지식을 사용 할 수 있다.

  4) 운영중에 SQL 실행계획이 거의 변하는 일이 없기 때문에 액세스 패스가 변경되어 성능이 떨어지는 장애가 발생하지 않는다.


 RBO의 단점


  1) 데이터 변동을 따라가지 못한다.

  2) SQL문 작성시 항목순서나 인덱스 만드는 순서가 중요하기 때문에 코드의 수정이나 인덱스 관리의 문제가 원인이 되어 성능       에 영향을 미치는 경우가 많다.

  3) 버전이 올라가면서 강화된 옵티마이저의 여러 기능 혜택을 받을수 없다. 



 CBO (Cost Based Optimizer) 비용 기반 옵티마이저


 - 내부적으로 통계정보를 참조하며 액세스 패스를 유연하게 최적화하는 기능.

 - CBO는 ANALYZE(통계수집)을 할 필요가 있으며, 통계를 최저한만 수집해서는 적절한 실행 계획을 얻지 못한다.



2. SQL문 처리에서 옵티마이저의 역할


 SQL문의 흐름


 - SQL문의 처리에는 소프트 파스와 하드 파스 두가지 방법이 있다.

 - 옵티마이저가 관여하는 경우와 관여하지 않는 경우로 나뉜다.


 소프트 파스


 - 실행한 SQL문은 파서에 의해 파스(Parse) 된다.

 - 파서는 SQL문을 컴포넌트 단위로 분해하여 문법적으로 틀리지 않았는지를 확인.

 - SGA에 캐시 되어 있는지를 조사. 캐시되어 있는 경우 SQL문을 즉시 실행가능


 하드 파스


 - SGA에 캐시가 없으면 SQL은 처음 실행되었거나 SGA에서 캐시 아웃된 상태. 이럴때 하드 파스 (Hard Parse)가 일어난다.

 - 하드 파스의 결과물로 옵티마이저가 '쿼리 실행 계획'을 만듬.

 - 실행 계획을 로우 소스 생성기가 받은후, 필요한 데이터 구조를 생성.

 - 로우 소스 생성기의 결과물을 이용해 SQL을 실행. 

 - DDL이나 UPDATE의 경우 실행 단계에서 작업이 완료되나, SELECT는 이후 Fetch 처리를 수행.



3. 옵티마이저가 수행하는 쿼리


 1) 옵티마이저가 가장 먼저 실행하는 처리는 쿼리의 변환(변형)

 - 작성된 SQL문을 다양한 형태로 변형한 후, 선택 가능한 실행 계획을 늘릭 위해 수행.

 2) 에스티메이터가 변환된 쿼리를 이용해 기초 비용을 예측하고 플랜 생성기가 실행 계획의 생성한 후, 다시 에스티메이터가 비용을 계산한다.

 - 계획의 비용을 예측할때에는 데이터 딕셔너리에 보관된 옵티마이저 통계를 이용.

 - 통계를 사전에 수집하지 않은 경우에는 다이내믹 샘플리을 수행하거나, 내부의 기본값이 사용되는 경우도 있음.


* 옵티마이저 통계에 포함된 정보

 

 테이블 통계

  - 건수

  - 블록 수

  - 평균 행 길이


 칼럼 통계

  - NDV(Number of distinct Value): 칼럼값의 종류 (Distinct count)

  - 칼럼 내의 NULL 수

  - 데이터 분포 (최댓값/최소값/히스토그램)

 

 인덱스 통계

  - 리프 블록 수

  - 레벨 (트리의 깊이)

  - 클러스터링 팩터


 시스템 통계

  - I/O 성능

  - CPU 성능


'ORACLE > Operation & Admin' 카테고리의 다른 글

Hint 정리  (0) 2017.12.18
CBO와 히스토그램 정리  (0) 2017.12.07
옵티마이저 기본기능  (0) 2017.11.14
RMAN 마지막 백업 확인  (0) 2017.04.05
DB의 실패한 로그인 확인하는 방법  (0) 2016.10.06
오라클 라이센스별 차이  (0) 2016.04.06

Oracle 12c R2 RAC 설치 #2

Grid 설치



oracle user로 접속


$ export SOFTWARE_LOCATION=/media/sf_12.2.0.1/

$ cd /u01/app/12.2.0.1/grid

$ unzip -q $SOFTWARE_LOCATION/linuxx64_12201_grid_home.zip


주의! 


기존처럼 설치 폴더 압축을 풀면 gird 라는 폴더가 생기는 것이 아니라, 해당 압축 폴더를 바로 $GRID_HOME 경로에 압축을 풀어주는 것임. 



root 유저로 rpm 설치


su -

# 1번 노드.

cd /u01/app/12.2.0.1/grid/cv/rpm

rpm -Uvh cvuqdisk*


# 2번 노드.

scp ./cvuqdisk* root@ol6-122-rac2:/tmp

ssh root@ol6-122-rac2 rpm -Uvh /tmp/cvuqdisk*

exit



GUI 에서 실행


$ cd /u01/app/12.2.0.1/grid

$ ./gridSetup.sh




DATABASE 설치


11g 와 동일.

Oracle 12c R2 RAC 설치 #1

설치 환경


Esxi 5.5, 

Oracle Linux 6.9 x86_64

Oracle 12c R2 (12.2.0.1)


리눅스6 설치 옵션


SWAP 4GB+

방화벽 사용중지

SELinux 설정 변경 (permissive or disabled)

해당 패키지 그룹 설치

  • Base System > Base
  • Base System > Hardware monitoring utilities
  • Base System > Large Systems Performance
  • Base System > Network file system client
  • Base System > Performance Tools
  • Base System > Perl Support
  • Servers > Server Platform
  • Servers > System administration tools
  • Desktops > Desktop
  • Desktops > Desktop Platform
  • Desktops > Fonts
  • Desktops > General Purpose Desktop
  • Desktops > Graphical Administration Tools
  • Desktops > Input Methods
  • Desktops > X Window System
  • Applications > Internet Browser
  • Development > Additional Development
  • Development > Development Tools


자동 설정


# yum install oracle-database-server-12cR2-preinstall -y

# yum install ntp -y



직접 설정


# groupadd oinstall

# groupadd dba

# useradd -g oinstall -G dba oracle

# passwd oracle



# vi /etc/sysctl.conf


fs.file-max = 6815744

kernel.sem = 250 32000 100 128

kernel.shmmni = 4096

kernel.shmall = 1073741824

kernel.shmmax = 4398046511104

kernel.panic_on_oops = 1

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 262144

net.core.wmem_max = 1048576

net.ipv4.conf.all.rp_filter = 2

net.ipv4.conf.default.rp_filter = 2

fs.aio-max-nr = 1048576

net.ipv4.ip_local_port_range = 9000 65500


# sysctl -p



# vi /etc/security/limits.d/oracle-database-server-12cR2-preinstall.conf


oracle   soft   nofile    1024

oracle   hard   nofile    65536

oracle   soft   nproc    16384

oracle   hard   nproc    16384

oracle   soft   stack    10240

oracle   hard   stack    32768

oracle   hard   memlock    134217728

oracle   soft   memlock    134217728


# yum -y install ksh,libaio-devel,unixODBC, unixODBC-devel

# yum -y update



# vi /etc/hosts


127.0.0.1       localhost.localdomain   localhost

# Public

192.168.56.201   ol6-122-rac1.localdomain        ol6-122-rac1

192.168.56.202   ol6-122-rac2.localdomain        ol6-122-rac2

# Private

192.168.1.201   ol6-122-rac1-priv.localdomain   ol6-122-rac1-priv

192.168.1.202   ol6-122-rac2-priv.localdomain   ol6-122-rac2-priv

# Virtual

192.168.56.203   ol6-122-rac1-vip.localdomain    ol6-122-rac1-vip

192.168.56.204   ol6-122-rac2-vip.localdomain    ol6-122-rac2-vip

# SCAN

#192.168.56.205   ol6-122-scan.localdomain ol6-122-scan

#192.168.56.206   ol6-122-scan.localdomain ol6-122-scan

#192.168.56.207   ol6-122-scan.localdomain ol6-122-scan



박화벽 중지


# service iptables stop

# chkconfig iptables off



NTP 설정


# vi /etc/sysconfig/ntpd

OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


# service ntpd restart

# chkconfig ntpd on



Grid 설치 폴더 생성


# mkdir -p /u01/app/12.2.0.1/grid

# mkdir -p /u01/app/oracle/product/12.2.0.1/db_1

# chown -R oracle:oinstall /u01

# chmod -R 775 /u01/



Oracle user 접속 후 프로파일 설정


$ vi .bash_profile


# Oracle Settings

export TMP=/tmp

export TMPDIR=$TMP


export ORACLE_HOSTNAME=ol6-122-rac1.localdomain

export ORACLE_UNQNAME=CDBRAC

export ORACLE_BASE=/u01/app/oracle

export GRID_HOME=/u01/app/12.2.0.1/grid

export DB_HOME=$ORACLE_BASE/product/12.2.0.1/db_1

export ORACLE_HOME=$DB_HOME

export ORACLE_SID=cdbrac1

export ORACLE_TERM=xterm

export BASE_PATH=/usr/sbin:$PATH

export PATH=$ORACLE_HOME/bin:$BASE_PATH


export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib


alias grid_env='. /home/oracle/grid_env'

alias db_env='. /home/oracle/db_env'


$ vi grid_env

export ORACLE_SID=+ASM1

export ORACLE_HOME=$GRID_HOME

export PATH=$ORACLE_HOME/bin:$BASE_PATH


export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib


$ vi db_env

export ORACLE_SID=cdbrac1

export ORACLE_HOME=$DB_HOME

export PATH=$ORACLE_HOME/bin:$BASE_PATH


export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib



공유 스토리지 Block device 설정


# fdisk /dev/sdb

 n, p, 1, Enter, Enter, w 



Udev 설정


# vi /etc/scsi_id.config

options=-g


# /sbin/scsi_id -g -u -d /dev/sdb1

36000c299ab492a9c2ff010df22555c9f


# vi /etc/udev/rules.d/99-oracle-asmdevices.rules

KERNEL=="sd?1", SUBSYSTEM=="block", PROGRAM=="/sbin/scsi_id -g -u -d /dev/$parent", RESULT=="36000c299ab492a9c2ff010df22555c9f", SYMLINK+="oracleasm/asm-disk1", OWNER="oracle", GROUP="dba", MODE="0660"



Block Device 파티션 테이블 불러오기


# partprobe /dev/sdb1



Udev Rule 다시 불러오기


# udevadm control --reload-rules


# ls -al /dev/oracleasm/*

lrwxrwxrwx. 1 root root 7 Mar  8 21:11 /dev/oracleasm/asm-disk1 -> ../sdb1




2번 노드도 똑같이 설정.

LGWR 대기에 따른 원인 분석 및 튜닝

1. LGWR 기록 지연 현상

 - Disk I/O 지연으로 오라클이 대기하는 경우 발생하는 이벤트 세가지중 하나.

 - 백그라운드 프로세스의 대기 이벤트, log file parallel write(로그 파일에 로그 기록)의 시간이 길어짐.

 - 서버 프로세스의 커밋을 기다리는 이벤트, log file sync(LGWR에 기록을 요청하고 회신을 기다림)의 시간이 길어짐.


2. DB의 성능과 디스크I/O

 - 우선 OS성능과 I/O성능은 별개임을 알아야 한다.

 - I/O성능은 단순하게 분석 할 수 없으며, 여러가지 상황을 고려 해야한다.

 - 디스크는 용량이 커지다보니 사용되는 디스크의 숫자는 줄어들고 있으나, IOPS(1초당 IO횟수)는 향상되지 않아, RDBMS의 관점에서 물리적 I/O는 거의 향상되지 않는다. 디스크의 개수가 줄어들다보니 병행액세스를 이용한 I/O성능을 향상하지 못하고, 사이즈당 I/O성능도 떨어지게 된다.

 - RDBMS에서 디스크에 기록할때, OS의 버퍼캐쉬, 스토리지의 캐쉬, 디스크의 캐시 순으로 기록한다. 그렇기 때문에 OS나 스토리지, 디스크의 캐시 성능에 의해서도 속도가 좌우되며, I/O의 구조상 오라클에 가까운 계층에서 캐시에 히트할수록 고속으로 처리한다.

 - I/O에서 특히 주의 하지않으면 안되는 것이 병렬도인데, 처리할 때 병렬도가 높아 순간적으로 큐가 생겼다가 사라짐을 반복해서 응답시간이 나빠지는 경우가 있다. 

 - I/O지연이 발생하는 것은 오라클에서도 알수 있지만, OS에서도 반드시 정보를 수집해야 한다. 세션수가 많거나, 대기시간이 길거나, 응답시간이 짧아도 처리량은 동일하기 때문에 RDBMS의 I/O는 인큐가 쌓여 대기시간이 늘어나도, 실제 OS에서는 I/O가 많지 않다고 나오는 경우도 있다.


3. I/O 성능의 판단

 - AWR 또는 Statspack, OS의 sar, iostat 같은 명령어를 사용하여 분석한다.

 - log file parallel write의 경우 같은 이벤트가 v$session_wait에 반복되어 표시되므로, P1,P2,P3가 같은지 확인해서 대기 여부를 판단해야 한다.

 - 부하가 없던 시간대의 응답시간에 비해 크게 나빠지지 않았는가 여부를 확인해야 한다.

  

4. LGWR의 대기 원인 분석

 - AWR이나 Statspack을 통해 LGWR의 대기 이벤트가 어디에서 부터 발생하는지 찾아야 한다.

 - 다음은 Statspack의 60분간의 top 5 time Events 이다.

  

  Top 5 Timed Events

  ~~~~~~~~~~~~~~~~~~                                       % Total

  Event                        Waits          Time (s) Ela Time

  --------------------------- ------------    -------- --------

  log file sync                1,350,499      27,021    50.04

  db file sequential read      1,299,154      13,633    25.25

  CPU time                                     7,034    13.03

  io done                      3,487,217       3,225     5.97

  latch free                     115,471       1,325     2.45

  

  Statspack은 1800초 가량 돌면서, 8 CPU에서 거의 14,400 CPU seconds를 사용 할 수 있다.

  이 서버안에 하나의 DB만 존재한다면, CPU의 사용량은 7034/14,400 : 50% 이다. 

  (statspack CPU Time/total CPU time)

  또 한, 60분간 log file sync가 27021 초의 대기시간을 가졌고, 27021/3600 = 7.5 평균 7.5프로세스들이 log file sync 이벤트를 발생했다. 이것은 중심이 되는 병목현상임을 나타낸다.

  

  만약에 SID 3이 LGWR를 발생했다면,

  

  select sid, event, time_waited, time_waited_micro

  from v$session_event where sid=3 order by 3

  SQL> /

  

     SID EVENT                          TIME_WAITED TIME_WAITED_MICRO

  ------ ------------------------------ ----------- -----------------

  ..

       3 control file sequential read        237848  2378480750

       3 enqueue                             417032  4170323279

       3 control file parallel write         706539  7065393146

       3 log file parallel write             768628  7686282956

       3 io done                           40822748  4.0823E+11

       3 rdbms ipc message                208478598  2.0848E+12

  

   rdbms ipc message가 가장 높게 나타나지만 일반적으로 무시할수있는 이벤트이고, 

   그 다음으로 높게 나타난 io done의 경우, LGWR의 I/O call complete와 LGWR의 기록이 동기식 기록를 하고난 후의 비동기식 I/O요청이다.

   oracle session snapper.sql 을 이용하면 SID 3 세션의 1초동안 일어난 LGWR을 확인할수 있다.

   

   ------------------------------------------------------------------

   SID, SNAPSHOT START  ,SEC, TYPE, STATISTIC            ,    DELTA,

   ------------------------------------------------------------------

   3, 20080513 11:44:32,   1, STAT, messages sent        ,        9,

   3, 20080513 11:44:32,   1, STAT, messages received    ,      153,

   3, 20080513 11:44:32,   1, STAT, redo wastage         ,    39648,

   3, 20080513 11:44:32,   1, STAT, redo writes          ,      152,

   3, 20080513 11:44:32,   1, STAT, redo blocks written  ,     1892,

   3, 20080513 11:44:32,   1, STAT, redo write time      ,       82,

   3, 20080513 11:44:32,   1, WAIT, rdbms ipc message    ,   169504,

   3, 20080513 11:44:32,   1, WAIT, io done              ,   813238,

   3, 20080513 11:44:32,   1, WAIT, log file parallel write ,  5421,

   3, 20080513 11:44:32,   1, WAIT, LGWR wait for redo copy ,     1,

   

   아니면 Level 12의 10046 trace를 통해 확인 할 수 있다.

   

   WAIT #0: nam='rdbms ipc message' ela= 7604 p1=223 p2=0 p3=0

   WAIT #0: nam='log file parallel write' ela= 35 p1=2 p2=16 p3=2

   WAIT #0: nam='io done' ela= 0 p1=0 p2=0 p3=0

   WAIT #0: nam='io done' ela= 639 p1=0 p2=0 p3=0

   WAIT #0: nam='io done' ela= 0 p1=0 p2=0 p3=0

   WAIT #0: nam='io done' ela= 605 p1=0 p2=0 p3=0

   WAIT #0: nam='io done' ela= 1 p1=0 p2=0 p3=0

   WAIT #0: nam='io done' ela= 366 p1=0 p2=0 p3=0

   

   다음은 Statspack의 특정 컬럼만을 조회한 항목이다.

   

   Statistic                             Total     per Second

   ------------------------------- ----------- --------------

   redo blocks written                 230,881        2,998.5

   redo buffer allocation retries            0            0.0

   redo entries                        285,803        3,711.7

   redo log space requests                   0            0.0

   redo log space wait time                  0            0.0

   redo ordering marks                       0            0.0

   redo size                       109,737,304    1,425,159.8

   redo synch time                      40,744          529.1

   redo synch writes                    38,141          495.3

   redo wastage                      5,159,124       67,001.6

   redo write time                       6,226           80.9

   redo writer latching time                 4            0.1

   user calls                          433,717        5,632.7

   user commits                         38,135          495.3

   user rollbacks                            1            0.0

   workarea executions - multipass           0            0.0

   

   1) 5,632 user calls / 495.3 user commits 의 값으로 초당 실행시간 평균을 구할 수 있다.

   2) LGWR에 의해 3000 redo block 을 썼다는 걸 알수 있는데, 솔라리스처럼 1block에 512bytes라면 초당 1.5mb/s 인것이다.

   3) redo가 1.4mb/s로 갱신 된다면 16mbps에 근접한다.

   4) 3000 redo block에서 38,155 commit이 일어났다.

   

   위의 redo 사이즈는 일반적으로 작은 사이즈가 아니지만, 초당 500 commit을 처리하기 위해서는 더 커야한다.

   

   적절한 사이즈의 redo 인가 확인 한 후, 다음으로 고려해야 할 사항은 CPU에 의한 LGWR 대기 현상이다.

   커밋 빈도 확인을 하고, 높다면 foreground 프로세스에서 일어나는 log file sync 이벤트만을 찾아 OS에서 LGWR의 CPU사용량을 체크한다.

   

   그다음은 아주 적게 발생하는 것중 하나인데, 인스턴스 프리징현상이 있는 경우 v$sysstat을 20초 간격으로 캡쳐하고, Oracle-supplied tool, LTOM을 이용하여 iostat를 캡쳐 한다.


   23-MAR-2007-04:29:43:Redo blocks written:1564176614:Delta: 8253

   23-MAR-2007-04:30:14:Redo blocks written:1564176614:Delta:    0

   23-MAR-2007-04:30:44:Redo blocks written:1564205771:Delta:29157   

  

   위와 같이 Commit 처리량이나, redo 사이즈 CPU사용량에 영향이 없음에도 log file parallel write, log file sync 가 크게 나타난다면 하드웨어의 I/O문제라고 파악 할 수 있다.

   

   r/s  w/s kr/s kw/s wait actv wsvc_t asvc_t %w  %b device

   0.0  0.0  0.0  0.0  0.0  1.0    0.0    0.0  0 100 d6

   0.0  0.0  0.0  0.0  0.0  1.0    0.0    0.0  0 100 d2

   0.0  0.0  0.0  0.0  0.0  1.0    0.0    0.0  0 100 d1

   0.0  0.0  0.0  0.0  0.0  9.0    0.0    0.0  0 100 d0

   0.0  0.0  0.0  0.0  0.0  3.0    0.0    0.0  0 100 d13

   0.0  2.0  0.0 24.0  0.0  2.0    0.0 1000.7  0 100 d12

   0.0  0.0  0.0  0.0  0.0  1.0    0.0    0.0  0 100 d11

  

   %b는 I/O가 디스크에 의존한 %를 알려주는데 요즘엔 디스크의 여러 이유로 인해 비지율을 전적으로 신뢰 할 수 없다.

      

   r/s     reads per second

   w/s     writes per second

   Kr/s    kilobytes read per second

   Kw/s    kilobytes written per second

   wait    average number of transactions waiting for service

           (queue length)

   actv    average number of transactions  actively  being serviced

           (removed  from  the queue but not yet completed)

   svc_t   average service time, in milliseconds

   %w      percent of time there are transactions  waiting for service

           (queue non-empty)

   %b      percent of time the disk is busy  (transactions in progress)

   

   wsvc_t  average service time in wait queue, in milliseconds

   asvc_t  average service time active transactions, inmilliseconds


   I/O를 체크했을때 LGWR이 발생할 당시 I/O의 속도가 15ms 보다 크게 나온다면 디스크 속도가 떨어진다고 할 수 있다.

   I/O자체가 늦어 LGWR에 대기가 발생하는 경우는 I/O 대역폭을 올려 해결 하는 수 밖에 없다.

   OS와 스토리지 간의 지연을 찾거나, 그밖의 디스크I/O문제, 여러 상황을 고려하고 문제를 풀어나가야 한다.

   스토리지 cache의 히트율이나, OS버퍼 cache의 영향도 고려 해야 하기 때문에 단순히 RDBMS 엔지니어 혼자 판단하기는 쉽지 않다. 

   

   

Log file sync check.sql

oracle session snapper.sql


  1. 안녕하세요

    만나서 반갑습니다

    안녕하세요

    만나서 반갑습니다

ORA-04031

이 에러의 원인은 크게 3가지로 나뉘어 진다.

1. 다수의 사용자로 인한 SharedPoolSize부족문제

2. 구동중인 App에 비해 현저히 부족한 SharedPool사용으로 인한 문제

3. 덩치 큰 SQL 구동을 위한 연속된 SharedPool할당 불가로 인한 문제

이중 1,2는 같은 맥락에서 접근할 수 있으므로 크게 2가지라고 볼 수도 있다.

이 문제는 OTN 에서 꽤나 유명한 에러로서 아래와 TechBulletin에는 아래와 같이 언급되어 있다.

No. 10095

ORA-4031 조치 방법 과 DBMS_SHARED_POOL STORED PROCEDURE 사용법
==============================================================

Purpose
-------

다음과 같은 작업 수행 시 Oracle 이 Shared pool 에서 연속적인 메모리 부분을 찾지 못해 ORA-4031 에러를 발생시키는 것을 볼 수 있다.

. PL/SQL Routine
. Procedure 수행 시
. Compile 시
. Forms Generate 또는 Running 시
. Object 생성하기 위해 Installer 사용 시

본 자료에서는 이러한 에러에 대한 대처 방안을 설명 하고자 한다.

Problem Description
-------------------

Error 발생의 주된 원인은 Shared Pool의 사용 가능한 Memory 가 시간이 흐름에 따라 작은 조각으로 분할되어 진다는 것이다. 그래서 큰 부분의
Memory 를 할당하려 한다면 Shared Memory가 부족하다는 ORA-4031 Error가 발생한다. 즉, 전체적으로는 많은 양의 사용 가능한 Space가 있다 하더라도
충분한 양의 연속적인 공간이 없으면 이 Error가 발생한다.

1. Shared Pool과 관련된 인스턴스 파라미터
다음 3가지 파라미터는 본 자료를 이해 하는데 매우 중요하다.

* SHARED_POOL_SIZE - Shared Pool 의 크기를 지정 한다. 정수를 사용하며 "K" 나 "M" 을 덧붙일 수 있다.

* SHARED_POOL_RESERVED_SIZE - 공유 풀 메모리에 대한 대량의 연속 공간 요청에 대비해서 예약하는 영역의 크기를 지정한다. 이 영역을 사용하기
위해서는 SHARED_POOL_RESERVED_MIN_ALLOC 보다 큰 영역 할당 요청이어야 한다. 일반적으로 SHARED_POOL_SIZE 의 10% 정도를 지정한다.

* SHARED_POOL_RESERVED_MIN_ALLOC - 예약 메모리 영역의 할당을 통제한다.
이 값보다 큰 메모리 값이 할당 요청되었을 때 공유 풀의 free list 에 합한 메모리 공간이 없으면 예약된 메모리 공간의 리스트에서 메모리를 할당해 준다.
이 값은 8i부터는 내부적으로만 사용된다.

Workaround
-----------
Re-start the instance

Solution Description:
---------------------
이 Error 해결방안을 살펴 보면 다음과 같다.

1. 혹시 알려진 제품 문제에 해당 되지 않는지 확인 한다.

* BUG 1397603: ORA-4031 / SGA memory leak of PERMANENT memory occurs for buffer handles. (Workaround: _db_handles_cached=0, Fixed: 8172,901 )
* BUG 1640583: ORA-4031 due to leak / cache buffer chain contentionfrom AND-EQUAL access. (Fixed: 8171,901 )
* BUG 1318267: INSERT AS SELECT statements may not be shared when they should be if TIMED_STATISTICS. It can lead to ORA-4031. (Workaround: _SQLEXEC_PROGRESSION_COST=0, Fixed: 8171, 8200)
* BUG 1193003: Cursors may not be shared in 8.1 when they should be (Fixed: 8162, 8170, 901)


2. Object를 Shared Pool에 맞추어 Fragmentation을 줄인다.
(Dbms_Shared_Pool Procedure 이용)

다음은 크기가 크고 빈번히 access되는 package들임.

standard packages
dbms_standard
diutil
diana
dbms_sys_sql
dbms_sql
dbms_utility
dbms_describe
pidl
dbms_output
dbms_job


3. Shared Pool 을 효율적으로 사용하도록 Application Program을 조절한다.


4. 메모리 할당을 조정한다.

우선 다음 쿼리로 library cache 문제인지 shared pool reserved space 문제인지 진단한다.

SELECT free_space, avg_free_size, used_space, avg_used_size, request_failures, last_failure_size FROM v$shared_pool_reserved;

만일 REQUEST_FAILURES is > 0 and LAST_FAILURE_SIZE is > SHARED_POOL_RESERVED_MIN_ALLOC
이면 ORA-4031 은 Shared Pool 의 연속 공간 부족의 결과이다.

해결책: SHARED_POOL_RESERVED_MIN_ALLOC 값을 증가 시켜서 shared pool reserved space 에 올라가는 오브젝트의 수를 줄인다. 그리고
SHARED_POOL_RESERVED_SIZE 와 SHARED_POOL_SIZE 를 충분히 확보해 준다.

만일 REQUEST_FAILURES is > 0 and LAST_FAILURE_SIZE is < SHARED_POOL_RESERVED_MIN_ALLOC
이거나
REQUEST_FAILURES is 0 and LAST_FAILURE_SIZE is < SHARED_POOL_RESERVED_MIN_ALLOC
이면 ORA-4031 은 library cache 내의 연속된 공간 부족의 결과 이다.

해결책: SHARED_POOL_RESERVED_MIN_ALLOC 을 줄여서 shared pool reserved space 를 보다 쉽게 사용할 수 있도록 해준다. 그리고 가능하면 SHARED_POOL_SIZE 를 증가시킨다.


5. DBMS_SHARED_POOL STORED PROCEDURE 사용법

이 stored package는 dbmspool.sql을 포함하며 7.0.13 이상 version에서 사용가능하다. 이는 다음과 같이 3가지 부분으로 나누어 진다.

Procedure sizes(minsize number):-> Shared_Pool_size 안에서 정해진 Size 보다 큰 Object를 보여준다.

Procedure keep(name varchar2, flag char Default 'P'):
-> Object (Only Package)를 Shared Pool 에 유지한다. 또한 일단 Keep한 Object는 LRU Algorithm에 영향을 받지 않으며 "Alter System Flush Shared_Pool" Command 에 의해 Package 의 Compiled
Version 이 Shared Pool에서 Clear되지 않는다.

Procedure unkeep(name varchar2):-> keep() 의 반대 기능이다

이 Procedure들과 사용법에 대해 보다 더 자세한 정보를 위해서는 $ORACLE_HOME/rdbms/admin/dbmspool.sql script 또는 오라클 레퍼런스 매뉴얼을 참조하기 바람.


Reference Documents
-------------------
Diagnosing and Resolving Error ORA-04031.

위의 내용과 관련하여 SharedPoolSize 조절 방법은 아래와 같다.

이미 공지의 사실이지만 서두로 언급하면 Oracle은 Background Process와 SGA영역으로 구분된다.

그중 SGA는 SharedPool과 RedoLogBuffer, BufferCache로 이루어져 있다.

이중 SharedPool은 SQL Area와 Data Structure로 이루어져 있다.

SharedPool Size를 산정하는 방법은 아래와 같다.

계산 공식        

Session당 최대메모리사용량(Max Session Memory) * 동시 접속하는 User의 수 
+  Shared SQL 영역으로 사용되는 메모리양         
+  Shared PLSQL을 위해 사용하는 메모리 영역          
+  최소 30%의 여유 공간 

계산 예제         

  (1) 적당한 user session에 대한 session id를 찾는다.        
         
        SQLDBA>  select sid from v$process p, v$session s          
             where p.addr=s.paddr and s.username='SCOTT';         

              SID         
           ----------         
               29         
        1 rows selected.         

  (2) 이 session id에 대한 maximum session memory를 찾는다.        
         
        SQLDBA> select value from v$sesstat s, v$statname n          
            where s.statistic# = n.statistic#          
            and n.name = 'session uga memory max' and sid=29;         

           VALUE              
           -----------         
            273877                 
        1 rows selected.         
         
  (3) Total shared SQL area를 구한다.        
         
        SQLDBA>  select sum(sharable_mem) from v$sqlarea;         

        SUM(SHARAB         
        ---------------------         
               8936625         
        1 row selected.         
         
  (4) PLSQL sharable memory area를 구한다.         
         
        SQLDBA>  select sum(sharable_mem) from v$db_object_cache;         

        SUM(SHARAB         
        ------------------         
            4823537         
        1 row selected.         
         
         
  (5) Shared pool size를 계산한다.         
                 
             274K shared memory  *  400 users         
        +      9M Shared SQL Area              
        +      5M PLSQL Sharable Memory          
        +      60M Free Space (30%)              

        =    184M Shared Pool            
                 
          
   이 예제에서는 Shared pool의 size는 184M가 적당하다고 할 수 있다. 이때 Free Space(60M) 계산 방법은 전제 184 M 에 대한 30 % 정도의 추정치 이다.        
         
Shared Memory부족 (ORA-4031)에 대한 대처

 다음과 같은 방법으로 에러를 피해 갈 수 있다.- "Sys.dbms_shared_pool.keep" procedure사용.        

[참고] 위 package를 사용하려면 ?/rdbms/admin/dbmspool.sql,prvtpool.sql를 수행시켜 package를 create시킨 후 사용한다.        
    (자세한 사항은 bulletin 10095,Oracle7 Server Tuning 4장12를 참조한다.)         
         

ORACLE_HOME/dbs/initSID.ora에 보시면 Processes=???값과 sessions=?????라는
값에 좌우가 되는데 시스템에서 허락되는
User별 process값이 있고 이 범위내에서 허용이 된다.
SQL> show parameter process;

NAME TYPE VALUE
------------------------------------ ------- ------------------------------
aq_tm_processes integer 0
db_writer_processes integer 1
job_queue_processes integer 0
log_archive_max_processes integer 1
processes integer 300
SQL> show parameter session;

NAME TYPE VALUE
------------------------------------ ------- ------------------------------
java_max_sessionspace_size integer 0
java_soft_sessionspace_limit integer 0
license_max_sessions integer 0
license_sessions_warning integer 0
mts_sessions integer 330
session_cached_cursors integer 0
session_max_open_files integer 10
sessions integer 335
SQL>

SCN Headroom 이슈사항

SCN Bump UP이 이슈 
이 장애는 오라클 데이터베이스 버전이나 패치 적용 여부에 따라 작게는 원격 트랜잭션(distributed transaction) 거절(rejection)을, 크게는 데이터베이스 셧다운까지 야기시켜 문제가 됐다. 
단발성으로 끝나지 않기 때문에 가볍게 볼 수 없는 문제라고 할 수 있다. 
이에 SCN Bump UP이 무엇인지 알아보고 이를 예방하기 위한 대책과 방안에 대해 살펴본다.
우선 SCN이 무엇인지 살펴보자. 
SCN은 System Change Number로, 오라클 데이터베이스에서 Ordering의 근간이라고 할 수 있다. 
데이터베이스 내부가 변경됐을 때의 논리적 시점, 즉 타임스탬프라고 할 수 있다. 
쿼리 및 데이터베이스 변경사 항을 추적하는 데 SCN이 이용되며, 이를 통해 정확한 복구(recovery)가 가능하다. 
DBA가 SCN을 직접 활용하는 경우로는 플래시백 쿼리(Flashback Query), 데이터베이스 복구, 로그마이너(LogMiner)가 있다. SCN은 6바이트(48비트)로 구성돼 있다. 시퀀스(sequence)처럼 증가하는 방식인데, 최대 상한값은 281,474,976,710,656(약 281조, 2^48)이다. 
이 값은 시간 배분 방식의 배급제 체계를 이용해서 증가하므로 초당 16K(또는 32K)로 늘어난다. SCN은 앞으로 사용 가능한 최대 상한선인 MAX SCN 값(281조)와 현 시점에서 유효하게 사용할 수 있는 Maximum Reasonable SCN 값이 있다. 
실질적으로 사용 가능한 값의 범위(Maximum Reasonable SCN – Current SCN )는 'SCN Headroom' 이라고 부르며, Maximum Reasonable SCN의 경우 Reasonable SCN Limit라고도 불린다. SCN이 증가하는 케이스는 크게 두 가지가 있다.
<그림 1> SCN HEADROOM

● CASE 1 : 로컬 내부 프로세싱으로 인해 증가하는 경우 'Intrinsic SCN rate' 라고 한다. 

● CASE 2 : Extrinsic SCN rate는 외적 요소로 증가된 경우를 말한다. 대표 적으로 DB Link 작업 수행 시 증가되는 경우인데, 이를 흔히 SCN Propagation이 됐다고 말한다. 

분산 트랜잭션(distributed transaction) 환경에서는 Call 단위로 SCN을 전파(propagation)하는데, 트랜잭션에 참여했던 모든 DB 중에서 가장 큰 SCN으로 동기화된다. 
SCN 동기화의 경우 보통 분 산 트랜잭션의 시작과 끝인데, Heavy Traffic의 경우 동기화 작업 이 빈번하게 일어난다.
<리스트 1> DB Link로 조회와 갱신이 일어나면 가장 큰 SCN 값이 전파된다. 

조회 전 
##ORACLE A ## 
SQL> SELECT current_scn FROM v$database; 

CURRENT_SCN 
----------- 
2918527 

## ORACLE B## 
SQL> SELECT current_scn FROM v$database; 

CURRENT_SCN 
----------- 
3377931 

# A에서 B로 DBLINK을 이용하여 조회,갱신 
# ORACLE A


 SCN 헤드룸(Headroom) Bump Up 관련 내용


컴퓨터 네트워크에서 시간이 지속적으로 동기화되는 것과 비슷하게, 두 데이터베이스 간에 데이터베이스 링크를 통해서 서로 통신을 할 때는 두 데이터베이스에서 사용 중인 가장 큰 SCN을 값을 택해서 각자의 SCN값을 동기화한다. 그래서 몇몇 경우엔 데이터베이스들이 SCN 헤드룸이 빠르게 줄어드는 상황을 경험하곤 한다. 이것은 해당 데이터베이스의 버그 때문이 아니라, 그 데이터베이스가 연결된 한 두군데 이상의 데이터베이스에서 그 버그가 이미 활성화되었기 때문이다. 


현재 최대 SCN을 넘어서는 SCN은 언제나 그 데이터베이스가 거부해버리기 때문에, 500년 이상 오라클 데이터베이스를 운영할 수 있도록 SCN을 제공하는 것은 어느 경우에도 영향을 받지 않았다.



 SCN 헤드룸(Headroom) Bump Up 관련 조치 방법


- January 2012 CPU (및 관련 PSU)을 적용한다.

- 적용 후 scnhealthcheck.sql을 이용하여 SCN 헤드룸(Headroom) 상태에 대해 확인한다.

  (Patch:13498243 및 마스터 노트: SCN 이슈 (문서 ID 1902993.1) 참고하여 진행.)

ORA-10873:FILE 1 NEEDS TO BE EITHER TAKEN OUT OF BACKUP MODE OR MEDIA RECOVERED

원인: DB가 Backup 모드에 들어간 상태에서 종료 되었을때 Startup을 하면 발생.


$ sqlplus / as sysdba


SQL> startup mount;

SQL> select * from v$backup;


쳐보면 데이터 파일들의 상태가 Active로 되어 있다.


SQL> alter database end backup;

SQL> alter database open;



해주면 끝.


RAC라면 1번 노드는 위 방식으로 올려주고,

나머지 노드는 sqlplus 에서 startup 또는 OS에서 srvctl 명령으로 올려준다.