모든 사용자 프로세스는 먼저 Redo Log Buffer가 생성 되어야만 Redo record Block을 변경할 수 있다.  즉, 첫 redo allocation latch를 할당 받고 난 다음 redo copy latch를 요구한다. 사용자 프로세스가 redo log buffer를 할당 받기 위해선 ‘redo allocation latch’ 를 먼저 할당 받고 ‘redo copy latch’를 획득 하여야 한다. ‘redo allocation latch’는 하나의 instance에 단지 하나만이 존재 하며, 'redo copy latch'는 Default로 CPU*2로 설정되어 있다. 다중 사용자 환경에서 이 redo allocation latch에 대한 경합을 줄이는 것(즉 사용자 프로세스당 redo allocation latch의 사용 시간을 최대한으로 줄이는 것)이 성능 향상에 도움이 된다.

l    Redo entry의 기록절차
1.    redo allocation latch획득으로 Log Buffer Position 확보
2.    redo copy latch획득
3.    redo log buffer allocation
4.    release redo allocation latch
5.    redo entry를 redo log buffer로 복제
6.    release redo copy latch



'Oracle Database' 카테고리의 다른 글

Latch  (0) 2009.04.07
Database Writer (DBWR)  (0) 2009.04.07
EXADATA  (0) 2009.03.20
Automatic Optimizer Statistics Collection  (0) 2009.03.20
Oracle 11g New Feature : OLTP table comperssion  (0) 2009.03.09

오라클에서 완벽하게(!) 최적화된(!) 새로운 storage 제품이 나왔답니다.
한번 읽어보세요..

Exadata Architecture

ORACLE EXADATA STORAGE SERVER


2009.11.06 update
벌써 exadata v2가 발표되었네요.
v1과는 달리 SUN 장비에 OLTP용 머신으로 2009 OOw에서 발표되었습니다.
자세한 내용은 아래에..





oracle 10g에서 소개된 Automatic Optimizer Statistics Collection 기능에 대해 간단히 얘기해보겠습니다. 대부분 이 기능을 끄고 안쓰는 걸로 알고 있는데 요놈 때문에 optimizer가 plan을 바꿔 곤란한 경우가 가끔 생기기도 합니다. 하지만 어찌 보면 굉장히 매력적인 기능이 아닐 수 없습니다. 대부분 데이터 베이스가 엄청 커져서 analyze 하는 시간도 오래 걸릴 뿐 아니라 더이상 오라클에서는 RULE base는 지원안한다고 하니..

그래서 지금은 안쓰지만 언젠가 쓰게될 요 기능에 대해 좀 알아보죠..

그러면 언제 automatic optimizer statistics collection이 시작 되며, 얼마나 수행될까요?
dba_scheduler_jobs를 보면 gather_stats_job이라는 job으로 등록되어 있습니다. 요 넘은 기본으로 저녁 10시 부터 8시간 동안, 또 토요일 00시 부터 2일 간 수행되게 되어 있죠.

만약 평일 8시간, 주말 2일간 수행을 다 못하면 어찌 될까요?
만약 수행 중 다 끝나지 않은 table의 statistic 정보는 원복 하게 됩니다.  그럼 다음날 에 다시 하겠죠? 아마 ~

그럼 얘는 뭘 보고 대상을 선정할 까요?
10g는 기본적으로 monitoring 기능이 enable 되어 있습니다. dba_tables 등의 view를 보면 monitoring이라는 column에 YES로 기본으로 박혀있죠.. dba_tab_modifications에 해당 table의 변경 내역을 저장하고 변경 내역이 10% 이상이 되면 STEAL 상태가 되어 Automatic Optimizer Statistics Collection의 대상이 됩니다.. 그리고 job이 수행되면 dba_tab_modifications의 데이터는 cleanup 됩니다.








RMAN 을 벌려놓긴 했는데, 테스트 할 여유가 요즘 별로 없네요.. 일단.. 미루고.. ^^;


오늘 oracle 11g new feature 인 OLTP table compression을 테스트 할 기회가 있어 간단히 정리해 보겠습니다. oracle 9i R2 에서 oracle 은 table compression 기능을 추가했죠. 이미 다른 database에서는 일반화 되어 있었었다죠?  oracle 9i에서는 bulk loading, insert에 대해서만 compression을 지원했습니다. 즉, parallel insert나 sql loader를 이용한 direct loading, 또 Create Table As Select (CTAS)에 대해서만 지원했습니다.

Table compression은 많은 row를 저장하고 있는 대량의 데이터를 위한 기능인데, 대부분의 이러한 테이블은 bulk loading 보다는 batch 작업을 통해 생성되거나 history성 table들이라 이러한 table들은 "move compress"로 다시 compress하는 과정이 추가로 필요하게 되죠..

Oracle 11g에서는 일반적인 DML에 대해서도 compress를 할수 있게 되었습니다. 단지 compress option을 줄때 "for all operations" option을 추가 해 주면 되죠. 물론 이전의 기능으로 사용하려면 "for direct_load operations" option을 주면 됩니다.

create table compress_for_dire compress for direct_load operations as ...
create table compress_for_dire compress for all operations as ...

ps1)
오늘 테스트를 했더니 두 option 다 block의 row가 꽉 차기 전까지는 일반 block과 구조가 동일한 것 같더군요. block 내 row가 꽉차는 시점에 symbol table이 생성되며 compress가 이루어 지는 듯 합니다..

ps2)
"direct_load operations" option을 준 table에 insert  select ( /*+ append */ 빼구) 주니까 당연히 compress는 안됩니다.... 만 일반 table 보다 row가 더 많이 들어가더군요..

왜그럴까?
아시는 분?





RMA을 사용하기에 앞서 몇몇 고려할 사항들이 있습니다.

- Recovery Catalog 사용여부

Recovery Catalog는 RMAN에 의해서 사용되어지고 유지관리 되는 저장소입니다.
RMAN은 recovery catalog에 저장되어 있는 정보를 사용해서 요청되어진 Backup 과 Restore의 실행을 어떻게 할지를 결정하게 되는데, 이 catalog의 사용 여부가 우선 결정되어야 합니다. catalog 없이 RMAN 을 사용할 때의 단점은 recovery catalog 의 overhead 가 없는 대신, Point-In-Time recovery가 어려우며, control file 손상시에 recovery 할 수 없고, stored script 를 사용할 수 없습니다. 오라클에서는 RECOVERY CATALOG 사용을 권장합니다.

- Flash recovery area 사용.

oracle 10g에서 제공하는 flash recovery area는 rman에 의해 자동으로 관리됩니다.
물론 일반 disk나 tape으로도 backup이 가능하나, flashback database 등의 새로운 기능 등을 사용하려면 flash recovery area를 사용하는 것이 바람직합니다. 물론 disk 공간이 backup strategy에 충분할 정도는 있어야 겠죠.

- Backup Strategy

RMAN은 incremental backup이 가능하므로 full backup, incremental backup으로 backup strategy를 미리 정해야 합니다. 물론 저녁마다 full backup이 가능하다면 특별한 backup 전략은 필요 없겠지만요. (당신이 그러한 경우라면... 좋은 환경에서 일하시는 겁니다 ㅋ)

 * 백업 전략은 이전 post ( oracle - recovery manager (RMAN)) 를 참고

- RMAN configuration.

RMAN 관련한 default configuration 입니다.
(note 305565.1 Persistent Controlfile configurations for RMAN in 9i and 10g. 참고)

- CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
Backup 보관 주기나 backup본의 갯수를 설정합니다.

- CONFIGURE BACKUP OPTIMIZATION OFF;
이미 backup 된 동일한(checkpoint SCN등) datafile, archived redolog, backup set이 있다면 skip 합니다.

- CONFIGURE DEFAULT DEVICE TYPE TO DISK; 
default backup device를 설정합니다.

- CONFIGURE CONTROLFILE AUTOBACKUP OFF; 
RMAN의 BACKUP이나 COPY 명령등의 수행후 자동으로 control file backup을 수행합니다.

- CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';
autobackup되는 control file의 기본 format을 변경합니다.

- CONFIGURE DEVICE TYPE DISK PARALLELISM 1;
특정 device에 automatic channel allocation 될때 channel의 갯수를 지정합니다.

- CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
DATAFILE, CONTROL FILE의 backup set의 copy본 갯수를 지정합니다.

- CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; 
ARCHIVELOG FILE의 backup set의 copy본 갯수를 지정합니다.

- CONFIGURE MAXSETSIZE TO UNLIMITED; 
backupset의 maximum size를 설정합니다.

- CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; (10g only)
flash recovery area의 archived redo log에 대한 삭제 여부를 설정합니다.

- CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/opt/oracle/product/ora10g/dbs/snapcf_db10g.f';
RMAN은 resync시 생성되는 임시 snapshot control file의 이름을 지정한다.

RMAN에 관련된 configuration은 다음의 명령으로 확인 가능합니다.

RMAN> Show all;

CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1; # 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 SNAPSHOT CONTROLFILE NAME TO '/u02/app/oracle/product/9.2.0/dbs/snapcf_V9201.f'; # default

그럼 다음 POST에선 RMAN 셋팅 방법에 대해 posting 하겠습니다.. ^^







RMAN 시작전에 알아야 할 몇몇 것(!) 들..

RMAN은 oracle8에서 처음 소개된 oracle에서 제공하는(!) backup & recovery tool 입니다.

Database files, Archive logs, 그리고 Control files들을 Backup하고 Restore하기 위하여 사용되어지며, Complete 또는 Incomplete Database Recovery 수행이 가능합니다. 또 10g 부터인가는 database의 validation check 까지 해 준다는 군요. (output을 보니 거의 DBV와 비슷한 내용인 것 같지만..)

다음은 RMAN에서 사용하는 주요 용어와 개념들 입니다.

- Target database
backup,restore,recovery action 이 수행될 대상 데이타베이스 입니다.

- Recovery Catalog
RMAN에서 사용하는 Information 저장장소입니다.
target database 의 물리적 스키마, datafile 과 archivelog 의 backup sets 과 pieces,
backup script 등을 포함하고 있습니다.

- channel
allocation channel 은 target database 의 backup,restore,recover에 대한 server process 초기화를 합니다. 즉, 이 channel은 disk 를 포함 기타 OS device를 지정하게 되며, 이에 따라 parallelization 의 degree 가 결정됩니다.

- Backup sets
하나 또는 그 이상의 Datafiles 또는 Archivelogs를 포함하며, 
Backup pieces의 Complate Set으로, Full 또는 Incremental Backup으로 구성 됩니다.
Oracle proprietary format을 사용합니다.

- Backup Pieces
하나의 Backup Set은 하나 또는 그 이상의 Backup Pieces로 구성이 되어지며,
각 Backup Piece는 Single Output File로  O/S의 File system Size의 제한을 갖고 있습니다.

[RMAN backup 내역 예]

RMAN> list backupset of database;
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
21046   Full    957M       DISK        00:04:04     06-MAY-03  
        BP Key: 21047   Status: AVAILABLE   Tag: FULL_DB_SUNDAY_NIGHT
        Piece Name: /home1/kcshin/rman/backup/db_t493300635_s31_p1

  List of Datafiles in backup set 21046
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/system01.dbf
  2       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/undotbs01.dbf
  3       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/example01.dbf
  4       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/indx01.dbf
  5       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/tools01.dbf
  6       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/users01.dbf
  7       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/oem_repository.dbf
  8       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/kcshin01.dbf

- Image Copies
Single file( datafile, archivelog or controlfile)의 Copy 본으로 O/S의 copy와 매우 유사합니다.
Backup set이나 Backup Piece가 아니며, Compression이 수행되지 않는 제한이 있습니다.

[RMAN backup 내역 예]

RMAN> list copy of datafile '/home2/oradata/ORA920/kcshin01.dbf';
List of Datafile Copies
Key     File S Completion Time Ckp SCN       Ckp Time        Name
------- ---- - --------------- ----------    --------------- ----
21070   8    A 06-MAY-03       7238179754301 06-MAY-03       /home1/kcshin/rman/backup/datafile8.f

- Full Backup Sets
하나 또는 그 이상의 Datafiles에 대한 Backup으로 Datafile의 모든 사용되어진 Block을 포함합니다.
미사용 Block은 Backup되지 않으며, 압축형태로 저장됩니다.

[RMAN backup 내역 예]

RMAN> list backupset of database;
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
21046   Full    957M       DISK        00:04:04     06-MAY-03  
        BP Key: 21047   Status: AVAILABLE   Tag: FULL_DB_SUNDAY_NIGHT
        Piece Name: /home1/kcshin/rman/backup/db_t493300635_s31_p1

  List of Datafiles in backup set 21046
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/system01.dbf
  2       Full 7238179754301 06-MAY-03 /home2/oradata/ORA920/undotbs01.dbf

- Incremental Backup Sets
하나 또는 그 이상의 Datafiles에 대한 Backup으로
같거나 낮은 Level의 이전 Backup이후 변경되어진 부분만 Backup을 하며, 압축형태로 저장됩니다.

[RMAN backup 내역 예]

RMAN> list backupset of database;
List of Backup Sets
===================
BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
21229   Incr 0  276M       DISK        00:01:06     06-MAY-03
        BP Key: 21232   Status: AVAILABLE   Tag: TAG20030506T155613
        Piece Name: /home1/kcshin/rman/backup/sunday_level0_493314973
  List of Datafiles in backup set 21229
  File LV Type Ckp SCN    Ckp Time  Name
  ---- -- ---- ---------- --------- ----
  1    0  Incr 7238179759787 06-MAY-03 /home2/oradata/ORA920/system01.dbf
  4    0  Incr 7238179759787 06-MAY-03 /home2/oradata/ORA920/indx01.dbf
  7    0  Incr 7238179759787 06-MAY-03 /home2/oradata/ORA920/oem_repository.dbf

- Recovery window
현재 시점과 recovery 가능한 가장 오래된 시점 사이를 나타내는 retention policy를 말합니다..

- SBT
System backup to tape

- Flash Recovery Area
control file, online redo log copies, archived logs, flashback logs 같은 recovery 와 관련된 file 들을 저장하기 위해 사용할 수 있는 선택적인 디스크 영역입니다.  오라클과  RMAN은 이러한 파일들은 flash recovery area 에 자동으로 관리합니다. 물론 일정 보관주기 설정이 가능하며, tape 등의 backup device로 backup이 가능합니다. flash recovery area는 target database에 설정됩니다.








가끔 database를 운영하다 보면 멀정히 잘 돌던 SQL이 plan이 바뀌어서 응답 시간이 터무니 없이 느려지곤 해 이로 인해 운영 장애가 발생하기도 하죠.

"같은 SQL을 같은 환경에서 사용하는데, SQL이 왜 느려지냐 ? "

뭐 이런 얘기를 DB 운영하는 사람이라면 가끔 들었을 법한 애기 입니다.
대개 이런 얘기는 높은 분들이 하기때문에 설명하기도 귀찮고 해서
그냥 "글쎄요.." 하고 넘어가기도 하는데,

사실 따지고 보면 데이터도 바뀌고, 변수값도 바뀌기 때문에
엄밀히 말하자면 같은 환경은 아닙니다.

bind peeking 기능으로 인해 hard parse 단계의 변수값에 영향을 받기도 하고,
automatic optimizer statistic collection 기능으로 인해 statistic 정보가 바뀔수도 있고,
dynamic sampling에 따라서 block 정보에 의해서도 바뀔수도 있죠.


이런 현상을 막으려면 부지런히 analyze 정보를 update 해주면 이러한 현상을 좀 줄어들 수도 있겠지만, 요거는 plan을 고정하기 보다는 plan을 최적화 한는 방법이죠.
뭐 잘되면 더 좋은 성능을 내겠지만,

그러나 다들 공감하시겠지만 성능 좋아진건 별로 눈에 띄지 않죠.
높은 분들도 잘 모르시고... ㅋㅋ

만약 특정 sql의 plan을 변경되지 않게 하기 위해서는 여러 방법이 있겠지만,
크게 outline을 사용하거나 hint를 sql에 적용하는 방법을 많이 사용합니다.

그러나 가끔 hint를 사용했는데, plan이 바뀌는 경우가 있는데, 이러한 경우는 대부분 hint를 꼼꼼히 부여하지 않아 optimizer가 hint를 무시하게 됩니다.

hint를 지정할때는 1) join method 2) join order 3) access method 를 전부 다 기술해 줘야 합니다.
요넘의 optimizer에게 일을 시키려면 절대 빠져나갈 구멍을 주면 안됩니다.. ㅋㅋ





가끔 오라클이 대량 작업 중에 죽거나 abort로 내렸을 경우
alert log에 보면 다음과 같이 SMON이 transaction rollback을 하는 메세지를 볼 수 있다.

SMON: about to recover undo segment 4
SMON: mark undo segment 4 as available
                    :


"음 .. 뭔가 큰 transaction이 있었군.."
"어? 왜 아직도 안끝나지? 언제 끝나는 거야? "


다음의 SQL은 rollback 대상 extent size를 확인할 수 있는 sql 문입니다.
이외에 undo segment header dump로 확인하는 방법도 있긴하지만,
요게 시간 산정하기는 더 편하겠지요..


select KTUXEUSN,KTUXESLT,KTUXESQN,KTUXERDBF,KTUXERDBB,KTUXESTA,KTUXESIZ
from x$ktuxe
where KTUXEUSN in (select segment_id from dba_rollback_segs where segment_name = '_SYSSMU156$')
and KTUXESTA = 'ACTIVE';



'Oracle Database' 카테고리의 다른 글

oracle 11g documents library  (0) 2009.01.18
대용량의 transaction rollback, 얼마나 걸릴까요?  (0) 2009.01.18
Oracle 9i online documents  (0) 2009.01.18
oracle 10g documents library  (0) 2009.01.18
Oracle AWR 이란?  (0) 2009.01.07

오라클 9i online documents 입니다.

Oracle 9i release 1 online documents
Oracle 9i release 2 online documents




오라클 10g documents library 입니다.

* oracle 10g release 2 (10.2) documents library 
* oracle 10g release 1 (10.1) documents library





오라클에서는 oracle의 성능을 측정하기 위한 몇몇 script를 제공해 왔습니다.

기본적으로 제공되던 script 들은 oracle version에 따라 utlbstat/utlestat, statspack, awr report 등의 형태로 제공되고 있습니다.

utlbstat/utlestat은 시작시점과 끝시점에 수행하여 구간의 데이터를 OS상의 text file로 출력하고,
oracle 8i 부터 제공되었던 statspack은 job이나 cron에 등록하여 구간별 데이터를 얻을 수 있게 되었습니다. awr report는 oracle 10g부터 제공되었으며, sql 수행정보등 level에 따라 좀더 다양한 성능관련 정보들을 보여 줍니다.

awr report는 기본적으로 60분 간격으로 7일간의 데이터를 수집, 보관합니다. 이 데이터는 SYSAUX tablespace에 보관되며, 다음의 performance view에 데이터를 저장하게 됩니다.

V$ACTIVE_SESSION_HISTORY - Displays the active session history (ASH) sampled every second.
V$METRIC - Displays metric information.
V$METRICNAME - Displays the metrics associated with each metric group.
V$METRIC_HISTORY - Displays historical metrics.
V$METRICGROUP - Displays all metrics groups.

DBA_HIST_ACTIVE_SESS_HISTORY - Displays the history contents of the active session history.
DBA_HIST_BASELINE - Displays baseline information.
DBA_HIST_DATABASE_INSTANCE - Displays database environment information.
DBA_HIST_SNAPSHOT - Displays snapshot information.
DBA_HIST_SQL_PLAN - Displays SQL execution plans.
DBA_HIST_WR_CONTROL - Displays AWR settings.

AWR report를 생성하기 위해서는 $ORACLE_HOME/rdbms/admin 밑에 있는 awr로 시작하는 몇몇 script를 수행하여 성능 보고서를 얻게 됩니다. 주로 awrrpt.sql이나 awrsqrpt.sql로 특정 구간의 성능데이터나 특정 구간에서의 SQL 수행정보를 얻곤 하죠.



다음은 awr관련 script 들입니다.

1)The awrrpt.sql SQL script generates an HTML or text report that displays
statistics for a range of snapshot Ids.

2)The awrrpti.sql SQL script generates an HTML or text report that displays
statistics for a range of snapshot Ids on a specified database and instance.

3) The awrsqrpt.sql SQL script generates an HTML or text report that displays
statistics of a particular SQL statement for a range of snapshot Ids. Run this report
to inspect or debug the performance of a SQL statement.

4) The awrsqrpi.sql SQL script generates an HTML or text report that displays
statistics of a particular SQL statement for a range of snapshot Ids on a specified SQL.

5) The awrddrpt.sql SQL script generates an HTML or text report that compares
detailed performance attributes and configuration settings between two selected
time periods.

6) The awrddrpi.sql SQL script generates an HTML or text report that compares
detailed performance attributes and configuration settings between two selected
time periods on a specific database and instance.

awr을 control 하기 위한 몇몇 procedure가 제공되는데,
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_setting 은 interval이나 보관기간에 대한 설정을 위해 사용되며, DBMS_WORKLOAD_REPOSITORY.create_baseline는 성능 판단의 기준이 되는 baseline을 만들때 사용됩니다.

자세한 procedure 사용법은 다음과 같습니다.

How to Modify the AWR SNAP SHOT SETTINGS:
=====================================

BEGIN
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
    retention => 43200,        -- Minutes (= 30 Days). Current value retained if NULL.
    interval  => 30);          -- Minutes. Current value retained if NULL.
END;
/

Creating the Baseline:
======================

BEGIN
  DBMS_WORKLOAD_REPOSITORY.create_baseline (
    start_snap_id => 10,
    end_snap_id   => 100,
    baseline_name => 'AWR First baseline');
END;
/

Dropping the AWR baseline:
==========================

BEGIN
  DBMS_WORKLOAD_REPOSITORY.drop_snapshot_range(
(row_snap_id=>40,
High_snap_id=>80);
END;
/

Creating SNAPSHOT Manually:
===========================

BEGIN
  DBMS_WORKLOAD_REPOSITORY.create_snapshot();
END;
/

awr report는 수행 주기와 보관주기를 잘 선택해 놓으면, 정작 중요할 때 긴히 써먹을 수 있으니, SYSAUX tablespace 공간 아까워하지 말고, 좀 넉넉히 셋팅하는 것이 좋습니다..

위의 내용은 metalink.oracle.com의 아래 문서를 참조했습니다.

note 748642.1 What is AWR( Automatic workload repository ) and How to generate the AWR report?





DB 관리하면서 가장 긴장되는 순간이 ..
당연히 recovery를 수행해야 하는 순간이죠...

잘못하면 데이터 다 날라가거나,
아니면 restore하는데, 10여시간씩 걸리는데,
한번 잘못 명령어 날리면 ..

상상만 해도 끔찍하죠..ㄷㄷ

다음의 dictionary view는 recovery시 꼭 챙겨봐야 할 dictionary view 입니다.
돌다리도 두들겨 보고 건넙니다.. ^^


DBA_DATA_FILES, V$DATAFILE

: 해당 datafile의 현황 및 현재 상태를 check할 수 있다.

V$DATAFILE_HEADER

: 해당 datafile의 fuzzy 상태를 확인할 수 있다. 만약 fuzzy 상태라고 하면 v$backup에서 정상적으로 end backup이 수행되었는지,
추가로 archive log를 적용해야 하는지의 판단이 필요하다.

V$BACKUP

: 최종에 Online Backup받은 file들에 대한 정보를 가지고 있다.
즉, Hot Backup이 수행되고 있는 Tablepsace가 아직 Backup Mode로 있는지 아니면 Backup이 완료 된 상태인지 확인 할 수 있다.
만약 Online Backup을 수행 하면서 ALTER TABLESPACE ~ END BACKUP; 을 수행하지 않았다면 STATUS가 ACTIVE로 남아있게 되며, 
해당 file을 Backup받은 후에 ALTER TABLESPACE ~ END BACKUP command를 실행하지 않은 것이므로 즉시 ALTER TABLESPACE ~ END BACKUP command 를 실행해야 한다.

(fuzzy bit에 대한 자세한 내용..)

v$logfile, v$log

: archive log의 현황및 상태를 확인할 수 있다.

v$archived_log, V$LOG_HISTORY

: archive된 archive log의 정보를 controlfile로 부터 보여준다.

v$controlfile

: controlfile의 현황 정보를 확인할 수 있다.

v$tablespaces

: tablespace의 현황 정보를 확인할 수 있다.

V$RECOVERY_LOG

: media recovery를 위해 적용해야할 archive log의 정보를 확인할 수 있다.

V$RECOVER_FILE

: recovery가 필요한 datafile 정보를 확인할 수 있다.
 
V$RECOVERY_FILE_STATUS

: recovery를 수행하고 있는 oracle process에게 각각의 datafile의 recovery 정보를 보여준다. 다른 세션에서는 정보가 보이지 않는다.

V$RECOVERY_PROGRESS

: v$session_longops의 subview로 해당 recovery 작업 시간 산정등 recovery operation을 tracking 할때 사용한다.

V$RECOVERY_STATUS

: recovery를 수행하고 있는 oracle process에게 현재의 recovery process의 statistic 수치를 보여준다. 다른 세션에서는 정보가 보이지 않는다.



'Oracle Database' 카테고리의 다른 글

oracle 10g documents library  (0) 2009.01.18
Oracle AWR 이란?  (0) 2009.01.07
dba_ view와 v$ view (oracle dictionary view & dynamic performance view)  (0) 2009.01.03
oracle 10g RAC & CRS  (1) 2008.12.31
Oracle SQL plan 확인하는 방법  (0) 2008.12.16

오라클 모니터링 할 때 모니터링 툴을 많이 사용하시죠.
oracle의 Sql Developer, 웨어밸리의 Orange, 퀘스트의 TOAD, 엑셈의 MaxGuage, 데이타헤븐의 Intuvision,..

GUI tool을 사용하면 한눈에 시스템 전체를 파악하기 용이하고, 마우스 클릭 몇번으로 금방 정보를 확인할 수 있습니다. 그러나 oracle의 data dictionary view나 dynamic performance view의 모든 내용을 포함하기는 어렵고, 또 다 포함하고 있다고 해도 그에 대한 사용 방법에 대해 사용자가 인지하고 있긴 어렵죠.

일반적으로 DBA 들이 주로 사용하는 dictionary view는 열손가락 꼽을 정도 밖에 안되지 않을까 합니다. dba_users, dba_tablespaces, v$tablespace, dba_data_files, v$filestat, v$sysstat, v$session_wait ... (음, 10개는 넘겠군요.. )

그런데 dictionary view를 보면 dba_로 시작하는 view와 v$로 시작하는 view 들이 있습니다.
(물론, all_ 이나 user_, gv$로 시작하는 view 들도 있긴 하죠)

dba_ view와 v$ view의 차이점을 무얼까요?




이 차이에 대해 평소에 별로 생각해 본적이 없어 google에서 찾아 봤더니 oracle faq's blog에 잘 설명 되어 있네요.

Oracle FAQ's

V$% views return data from memory structures. Data is lost when the instance is restarted.
DBA_% tables return data from the database's data dictionary (SYSTEM tablespace). Data persists across instance restarts.

v$ view는 memory structure data를 보여주며, dba_ table(?)은 system tablespace 상의 data dictoinary data를 보여줍니다. 10g에서 awr 관련 view들이 만들어져서 dba_hist view 등에서 memory structure statistic data를 system tablespace에 저장해서 보여주기도 하죠.

다음의 HP's oracle blog에는 좀더 자세한 내용이 실려 있습니다..

HP's Oracle Blog

V$ & DBA_

Static Data Dictionary Views and Dynamic Performance Views are the core of database administration. They are of crucial importance. Whoever wants to learn Oracle database administration has to get familiar with these views.

The Data Dictionary tables contain meta data on objects, privileges, roles, users etc.
Whenever you issue DML statements Oracle consults its data dictionary to make sure a table is there, it has the right columns and you have privileges on it. And whenever you issue DDL statements Oracle updates its data dictionary.
All information needed by an instance on its database is kept in the data dictionary. Except some storage related information which is in the datafile headers and some information in controlfile and spfile which is needed at instance startup.

At runtime the oracle instance stores information about itself, about its CPU, memory or I/O performance, wait statistics and everything else which is going on at the instance in dynamic performance tables. Dynamic performance tables are non persistent. You can’t see past instance startup. After shutdown or instance crash all information contained in dynamic performance tables is lost. *1)

Through static dictionary views users can get at information kept in data dictionary tables.
And through dynamic performance views users can look at non persistent runtime information contained in dynamic performance tables.

But why are those views that important, you might ask? All information necessary for database administration can be found in those static dictionary views. And basically all information necessary for instance diagnostic and tuning can be obtained through those dynamic performance views at runtime.

Of course, GUI tools like Enterprise Manager or SQL Developer offer the same information
in a more user friendly manner. But all those GUI tools rely on static dictionary views and dynamic performance views.

As a DBA you will likely get into situations where there is no GUI tools available. At times you will be alone with your SQL*Plus skills. Your mastery of data dictionary and performance views will make all the difference!

동감입니다 !
tool을 사용하는 것이 더 효율적이라 생각하실지 모르지만
마지막엔 DBA가 직접 sqlplus에서 dictionary view들을 query해야 하는 경우가 허다하죠..

너무 툴에 익숙해지지 마세요.. ^^




왜 필요할 때 마다 이건 기억이 안나지.. 참..

현재 수행한 SQL의 plan을 확읺는 방법 2가지입니다..
select * from table(dbms_xplan.display);

SQL> desc dbms_xplan
FUNCTION DISPLAY RETURNS DBMS_XPLAN_TYPE_TABLE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 TABLE_NAME                     VARCHAR2                IN     DEFAULT
 STATEMENT_ID                   VARCHAR2                IN     DEFAULT
 FORMAT                         VARCHAR2                IN     DEFAULT

explain plan
for
sql ..

utlxpls.sql 수행
select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial'));

SQL> desc dbms_xplan
FUNCTION DISPLAY RETURNS DBMS_XPLAN_TYPE_TABLE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 TABLE_NAME                     VARCHAR2                IN     DEFAULT
 STATEMENT_ID                   VARCHAR2                IN     DEFAULT
 FORMAT                         VARCHAR2                IN     DEFAULT

FUNCTION DISPLAY_AWR RETURNS DBMS_XPLAN_TYPE_TABLE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 SQL_ID                         VARCHAR2                IN
 PLAN_HASH_VALUE                NUMBER(38)              IN     DEFAULT
 DB_ID                          NUMBER(38)              IN     DEFAULT
 FORMAT                         VARCHAR2                IN     DEFAULT

FUNCTION DISPLAY_CURSOR RETURNS DBMS_XPLAN_TYPE_TABLE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 SQL_ID                         VARCHAR2                IN     DEFAULT
 CURSOR_CHILD_NO                NUMBER(38)              IN     DEFAULT
 FORMAT                         VARCHAR2                IN     DEFAULT

FUNCTION PREPARE_RECORDS RETURNS DBMS_XPLAN_TYPE_TABLE
 Argument Name                  Type                    In/Out Default?
 ------------------------------ ----------------------- ------ --------
 PAR1                           VARCHAR2                IN
 PAR2                           VARCHAR2                IN




active session들의 현재 wait event와 sql 정보를 buffer get 기준으로 보여주는 sql script 입니다.
세션 모니터링의 기본이죠..

<내용>
set pagesize 250
col sid for 9999
col waiting_on for a90
col serial# for 999999
col prg for a19
col OraPid for 9999
col command for a9
col aa Heading "DB-User" for a8
col bb Heading "OS-Pid" for a7

set pau off
select to_char(sysdate,'MM/DD HH24:MI:SS') dat,s.sid SID,s.serial#,sql_hash_value,
decode(s.command,
        '0','NO',
        '1','Cr Tab',
        '2','Insert',
        '3','Select',
        '6','Update',
        '7','Delete',
        '9','Create Idx',
        '10','Drop Idx',
        '15','Alter Tbl',
        '24','Create Proc',
        '32','Create Link',
        '33','Drop Link',
        '36','Create RBS',
        '37','Alter RBS',
        '38','Drop RBS',
        '40','Alter TBS',
        '41','Drop TBS',
        '42','Alter Sess',
        '45','Rollback',
        '47','PL/SQL Exe',
        '62','Anal Table',
        '63','Anal Index',
        '85','Truncate') Command,
substr(s.machine,1,8)||'['|| substr(s.program, 1, 9)||']' prg,
round(q.buffer_gets/q.executions,2) getperexec,
substr(
rtrim(w.event) || ': ' ||
rtrim(p1text,' ') || ' ' || to_char(p1) || ',' ||
rtrim(p2text,' ') || ' ' || to_char(p2) || ',' ||
rtrim(p3text,' ') || ' ' || to_char(p3),1,75) ||',waiting:'||wait_time  as waiting_on
from  v$session s, v$session_wait w,v$sqlarea q
where w.wait_time = 0
and w.sid = s.sid
and s.sql_hash_value = q.hash_value
and event not like '%pmon timer%'
and event not like '%smon timer%'
and event not like '%rdbms ipc message%'
and event not like '%SQL*Net message%'
and event not like '%lock manager wait for%'
and event not like '%slave wait%'
and event not like '%io done%'
and event not like '%pipe get%'
and event not like '%wakeup time manager%'
and event not like '%queue messages%'
order by getperexec
/




tablespace를 만들떄 local managed tablespace를 많이 사용하시죠?
예전의 dictionary-managed 방식에 비해 LMT는 많은 이점이 있죠..
뭐 이점이 있다기 보다는 dictionary-managed 방식의 단점이라고 보는게 더 타당할 지 모르겠네요..^^;

LMT의 extent 관리 방식에는 uniform size와 system managed 방식이 있습니다.
간단히 말하자면, uniform size는 extent size를 정해서 해당 tablespace에 생성되는 segment 들은 동일한 extent size로 설정되게 되고, system managed 방식은 extent size에 대한 설정을 oracle에서 관리해 주는 거죠..

system managed 방식을 쓰면 extent size에 대해 크게 신경을 안써도 되니 좋긴 한데, 오라클에서 어떻게 extent를 관리할까요?

심심해서 함 해봤는데, 엄청난 매카니즘이 숨겨 있더군요.. ㅋ


처음에 64k로 extent가 생성됩니다. 다음 extent도 64K가 생성되죠.. 뭐 이렇게 16개가 만들어지고,
다음은 1024K로 extent가 생성된후... 64개까지 만들어 지고...
..

이런 식으로 extent가 할당되면 1024K가 생성될 때 즈음이면
1024K 이하의 extent는 영원히 짜투리로 남을 수도 있겠죠?


LOCALLY MANAGED TABLESPACE IN ORACLE8I ...





+ Recent posts