'Oracle'에 해당되는 글 3건

  1. 2015.03.03 [Oracle] Partition Split
  2. 2014.11.28 [Oracle] 11g Parameter
  3. 2013.07.10 [Oracle 공식입장] DB 형상 변경과 업무의 상관관계

[Oracle] Partition Split

|

Partition Table 에 대해서 Split 하는 방법

상황
- RANGE Partition Table에서 2015년 03월 Partition을 생성하지 않고 2015년도 Partition을 생성한 경우

1. Split 할 Partition에 대해서 건수 확인
SELECT COUNT(1) AS CNT
FROM [OWN].[TAB] PARTITION(P201504);

2. [Split이전] Partition 에 대한 정보 확인
SELECT TABLE_OWNER,
TABLE_NAME,
PARTITION_NAME,
TABLESPACE_NAME,
HIGH_VALUE
FROM DBA_TAB_PARTITIONS
WHERE TABLE_NAME = '[TAB]';

3. Split Partition
ALTER TABLE [OWN].[TAB]
SPLIT PARTITION P201504 AT ('20150399999999')
INTO (PARTITION P201503, PARTITION P201504_02);

4. Partition Name 변경
ALTER TABLE [OWN].[TAB]
RENAME PARTITION P201504_02
TO P201504;

5. [Split이후]Partition 에 대한 정보 확인
SELECT TABLE_OWNER,
TABLE_NAME,
PARTITION_NAME,
TABLESPACE_NAME,
HIGH_VALUE
FROM DBA_TAB_PARTITIONS
WHERE TABLE_NAME = '[TAB]';

6. Split한 Partition 에 대해 연결된 Local Index Rename
ALTER INDEX [OWN].[TAB]_PK
RENAME PARTITION P201504_2 TO P201504;
ALTER INDEX [OWN].[TAB]_IX01
RENAME PARTITION P201504_2 TO P201504;

7. UNUSABLE Index에 대해서 Rebuild
ALTER INDEX [OWN].[TAB]_PK
REBUILD PARTITION P201503 ONLINE;
ALTER INDEX [OWN].[TAB]_PK
REBUILD PARTITION P201504 ONLINE;
ALTER INDEX [OWN].[TAB]_IX01
REBUILD PARTITION P201503 ONLINE;
ALTER INDEX [OWN].[TAB]_IX01
REBUILD PARTITION P201504 ONLINE;

8. Split이후 Partition에 대해서 건수 확인
SELECT COUNT(1) AS CNT
FROM [OWN].[TAB] PARTITION(P201503);

And

[Oracle] 11g Parameter

|
Google Docs에 정리


db_block_size
- Oracle Database Block Size로 I/O 기준이 됨
- 8192/8192 (Default/Recommand)

db_file_multiblock_read_count
- Table Scan시 최소의 I/O 양으로 OLTP 성(8), 배치성(16 or 32)
- ?/16 (Default/Recommand)

disk_asynch_io
- Oracle Datafile에 대한 async I/O 처리하여 성능개선
- TRUE/TRUE(Default/Recommand)

db_keep_cache_size
- Keep Buffer에 유지하여 특정 Object에 대한 DISK I/O 성능 이슈 발생 설정
- 0/0(Default/Recommand)

db_cache_advice
- 검증, 성능/부하 테스트 단계까지 on, 운영 단계에서 Off 권고
- statistics_level에 따라 설정/off(Default/Recommand)

result_cache_max_size
- SQL Query 의 결과에 대해 저장되며, 0으로 설정할 경우 result cache disable
- Shared Pool Size 내에서 할당 됨. Shared Pool Size 산정 시 고려
- 성능/검증 Test를 통해 Disable할지 고려
- shared_pool_size에 자동 / default (Default/Recommand)

db_writer_processes
- RAC 및 부하가 큰 DB의 Data File에 대한 I/O가 높을 경우 4로 Tunning
- Async I/O 설정을 전제로 함.
- CPU가 적으나 대량 I/O 인 경우 설정
- 1/cpu_count / default (Default/Recommand)

open_cursors
- Session당 Open 가능한 cursor
- 일반적으로 500 이상 발생 시 Application 검증 필요
- 개발 단계시 모니터링 항목
- 300/300 (Default/Recommand)

session_cached_cursors
- 동일 SQL이 잦은 Parsing이 발생할 때 설정 시 유리
- LRU로 관리 됨.
- 50 / 50 (Default/Recommand)

db_name
- Database 이름

db_domain
- 128자 이내로 세팅
- 숫자, _, $ 미사용

background_dump_dest
- Alert로그 및 Background Process 관련 Trace 위치
- OS 설정에 따름 / (/log/diag/rdbms/db명/SID명/trace) (Default/Recommand)

core_dump_dest
- UNIX에서만 사용되는 파라미터
- Oracle Core 파일 떨어지는 위치
- OS 설정에 따름 / (/log/diag/rdbms/db명/SID명/cdump) (Default/Recommand)

max_dump_file_size
- Log 저장 영역 여유율을 고려하여 설정
- UNLIMITED / UNLIMITED (Default/Recommand)

statistics_level
- 자동 튜닝, 분석 Data 수집 기본 기능
- TYPICAL / TYPICAL (Default/Recommand)

timed_statistics
- time 관련 통계 정보 수집
- statistics_level 에따라 설정 / TRUE (Default/Recommand)

db_block_checking
- Data, Memory Corruption 방지
- DB 정합성 유지를 위해 적용 검토 필요함.
- True 설정 시, 약 1% ~ 10% overhead
- FALSE/FALSE (Default/Recommand)

db_block_checksum
- Memory Corruption 방지
- Default 는 Typical 이며 약 1% ~ 2%의 overhead
TRUE 는 약 5% 의 overhead
- DML 전에도 Checksum 확인
- DB 정합성 유지를 위해 적용 검토 필요함.
- Typical / FALSE (Default/Recommand)

user_dump_dest
- user process에 의해 debugging 되는 trace 파일 떨어지는 곳
- OS설정에 따라 감 / (/log/diag/rdbms/DB명/SID명/trace) (Default/Recommand)

diagnostic_dest
- Bdump, Udump에 대응되는 정보가 저장되는 경로
- OS설정에 따라 감 / (/log) (Default/Recommand)

distributed_lock_timeout
- 분산 Transaction에 대한 Lock 대기 시간이 필요시 대기 시간 튜닝
- Global transaction timeout < session timeout < distributed_lock_timeout (DB설정)
- OS설정에 따라 감 / 1000 (Default/Recommand)

db_files
- datafile 가능 한 수
- OS설정에 따라 감 / 2000 (Default/Recommand)

audit_file_dest
- audit trail 걸때 지정되는 위치
- OS설정에 따라 감 / (/log/diag/rdbms/DB명/SID명/adump)

nls_timestamp_format
- timestamp format 세팅
- nls 설정에 따름 / YYYY-MM-DD HH24:MI:SS:FF6 (Default/Recommand)

nls_timestamp_tz_format
- timestamp timezone format 세팅
- nls 설정에 따름 / timezone 필요시 설정 (Default/Recommand)

nls_data_format
- data format 세팅
- nls 설정에 따름 / YYYY-MM-DD (Default/Recommand)

job_queue_processes
- 오라클 내부에서 수행되는 Job(dbms_job) 을 위해 생성되는 Job Process 최대 개수
- 1000/1000 (Default/Recommand)

optimizer_mode
- first_rows_n(1, 10, 100, 1000) : 옵티마이저가 각 rows 값들이 나오기 위한 cost_based 사용
- all_rows : 옵티마이저가 해당 결과값을 나오기 위한 cost_based 사용
- Index Scan 또는 Full Table Scan을 해야하는지 선택
- all_rows / all_rows (Default/Recommand)

optimizer_dynamic_sampling
- 주기적인 통계정보 수립, SQL 수행 시 통계정보가 없는 테이블에 대해 통계정보 수집
- DBA가 주기적으로 모든 테이블에 대해 통계정보 수집
- 샘플 블록 개수가 64개로 적절한 실행계획을 기대하기 어려움
- 샘플 블록 개수를 늘이면 파싱이 오래 거림, 반복적인 샘플링 발생
- 동적 샘플링 정보는 저장하지 않음
- 2 / 0 (Default/Recommand)

optimizer_index_caching
- Cost-based Optimizer가 Nested Loop 성으로 수립되도록 수집하도록 유도
- 0 / 0 (Default/Recommand)

optimizer_index_cost_adj
- Access Path 수립 시 Index 에 대한 친화도를 조절
- 낮을 수록 Index 사용
- 100 / 100 (Default/Recommand)

optimizer_secure_view_merging
- SYS유저가 생성한 Dict View를 타 유저가 참조하는 경우 성능 저하 발생
- Query Rewrite 사용하기 위해 반드시 FALSE 설정
- TRUE / FALSE (Default/Recommand)

parallel_adaptive_multi_user
- PX 사용 시 다중 사용자의 성능을 향상시키는 알고리즘 사용
- TRUE : Query 수행되는 시점의 System Load에 따라 자동으로 Parallel Degree 를 줄여서 Query 수행
32 -> 16 -> 8 ....
- 가능한 Parallel을 보장하기 위해 FALSE 로 세팅
- TRUE/FALSE (Default/Recommand)

parallel_force_local
- PX(Parallel Execution)을 한 인스턴스로 고정함
- 필요시, Session 단위 변경 실시
- FALSE / TRUE (Default/Recommand)

parallel_execution_message_size
- 만약 Top 5 Timed Events에 PX qref latch가 상위에 올라오는 경우 16384byte 상위 검토 필요함
- 16384 / 16384 / (Default/Recommand)

sga_target
- ASMM(Automatic Shared Memory Management) 기능으로 모니터링 후 SGA 튜닝하여 고정 할 지 결정
- 대용량 메모리인 경우 50% 검토
- 0 / 전체 메모리의 30% 할당 (Default/Recommand)

sga_max_size
- 최대 SGA SIZE 값으로 sga_target으로만 설정함

db_cache_size
- db_cache_size 설정 후 V$DB_CACHE_ADVICE 뷰 참고해서 튜닝
- 미 설정 후 튜닝하여 설정

shared_pool_size
- "ASM" 사용 시 증가.
- db_cache_size 늘리는 경우 같이 늘려줘야 함.
- RAC인 경우 GES, GCS 추가 사용함
- 미 설정 후 튜닝하여 설정

shared_pool_reserved_size
- 대량 shared pool 5%
- 자동 설정에 따른 5% / 튜닝하여 설정 검토

java_pool_size
- java class, method 사용을 위한 메모리 영역

lock_sga
- Memory 사용률이 높은 경우 TRUE 권고(80% 이상 가능 시)
- FALSE/FALSE (Default/Recommand)

large_pool_size
- Memory의 약 1% 할당
- 만약, Parallel 을 다수 사용하며, MTS, RMAN을 사용 시 늘린다.
- PUMP 사용이 만흥 DB에 한해 1GB이상 설정

log_buffer
- 오라클 Internal 알고리즘에 의해 세팅됨

log_checkpoints_to_alert
- checkpoint 시작 종료 시간을 alert log 통해 볼수 있음.
- 적용 권장
- FALSE / TRUE (Default/Recommand)

log_archive_format
- %t : thread number
- %r : resetlogs ID
- %s : log sequence number
- %S : log sequence number 이나 없는값은 0으로 채움
- %T : thread number이나 없는 값은 0으로 채움
- %a : activation ID
- %d : database ID
- OS설정에 따라 감 / arch_DB명%t_%s_%r.arc (Default/Recommand)

fast_start_mttr_target
- Instance Recovery 시 복구를 600초 내에 끝낼 수 있도록 설정하는 값
- 단, write complete waits, Incremental Checkpoint 이벤트가 빈번히 발생하는 경우, 값을 늘리도록 함.
- 0 / 0 (Default/Recommand)

log_archive_dest_1
- Archive File 떨어질 위치
- 공유 영역

log_archive_dest_2
- Archive File 떨어질 위치
- Local 영역

audit_sys_operations
- Sys user가 어떤 것을 Operation 하는 지 보는 Parameter
- FALSE / TRUE (Default/Recommand)

sec_case_sensitive_logon
- Login ID, Password에 대한 Case Sensitive설정
- 11g 이상 부터
- TRUE / FALSE

07_DICTIONARY_ACCESSIBILITY
- select any table 권한으로 SYS Schema의 Object를 조회하도록 설정
- FALSE/FALSE (Default/Recommand)

remote_login_passwordfile
- NONE : 패스워드 파일 무시, OS에 의해서 권한을 부여 받음.
- EXCLUSIVE : 패스워드 파일 사용, SYS or NON-SYS 계정을 넣음. 1개DB 내 1개 Instance 사용
- EXCLUSIVE / EXCLUSIVE (Default/Recommand)

audit_trail
- Oracle audit 기능의 사용 시 로그 생성 문제로 시스템 부하 발생
- 10g=NONE, 11g=DB로 Default정책 변경
- NONE / NONE (Default/Recommand)

processes
- Oracle 프로세스 개수
- 만약 대형 시스템인 경우 5000이상 늘리며,
또한 Fail-Over 고려하여 2~3배 수 설정
- 100 / 2000 (Default/Recommand)

pga_aggregate_target
- Memory-intensive SQL operators에 사용
(sort, group by, hash-join, bitmap merge, bitmap create)
- 메모리 사용률 확인 필요
- 향후 부하테스트 이후 조정 참고사항 임
- 메모리 과다 낭비 하지 않도록 조정 필요
- 10MB or 20% SGA

workarea_size_policy
- PGA방식의 sort사용
- 효율적인 Memory 사용과 성능을 위해 권고
- AUTO / AUTO (Default/Recommand)

undo_management
- UNDO space 관리를 위해 자동
- AUTO / AUTO (Default/Recommand)

undo_tablespace
- 전체 DB의 5% 할당

recyclebin
- Recycle BIN DROP 시 유용하게 사용 가능
- on / on (Default/Recommand)

cluster_database
- Single : FALSE / RAC : TRUE

instance_number
- rac 인 경우

local_listener
- listener.ora에 기입되어 있는 network 및 address 명으로 기입 함
- 같은 machine 내에 있는 Instance 의 listener 임
- tnsnames.ora 에도 등록해야 함
- 해당 기능을 세팅하면 pmon이 listener 상태를 모니터링 함

global_txn_process
- 11g New Feature
- Global Distributed Trancation에 대한 Instance별 관리
- default 권고

thread
- RAC에서 Instance가 사용하는 redo thread number

spfile
- rman 사용 시 spfile로 전환하며, pfile형태로 관리

deferred_segment_creation
- 실제 데이터 추가 되기 전까지 segment 생성 지연
- TRUE/FALSE (Default/Recommand)

control_file_record_keep_time
- control file content에 대한 보관기간으로 Archive File에 대한 정보를 저장하기 위해 백업정책에 따라 결정
- 7 / 40 (Default/Recommand)

log_archive_min_succeed_dest
- archive 다중화 구성 시 destination의 여러가지 문제로 특정번호 지정하여 성공시 계속 사용 가능하는 옵션
- 1 / 1 (Default/Recommand)

_optim_peek_user_binds
- 초기 Plan 수립 시 특정 bind에 대하여 Peaking하여 반영하는 기능
- 안정적인 Plan 수립을 위해 기능 Disable
- 예상 실행 계획과 실제 실행 계획이 다를 수 있음.
- TRUE / FALSE (Default/Recommand)

_fast_full_scan_enabled
- Index 전체를 읽어 Index를 사용하는 의미가 없음
- 업무 SQL에서 Index Fast Full Scan이 유용한 경우는 없음
- 필요시 Hint 로 유도
- TRUE / FALSE (Default/Recommand)

_optimizer_adaptive_cursor_sharing
- Bind Variable Peaking와 동일한 문제
- SQL하나에 서로 다른 실행계획이 다수 발생
- Cursor 과다 생성으로 Shared Pool 부족할 수 있음
- TRUE / FALSE (Default/Recommand)

_optimizer_join_factorization
- UNION / UNION ALL 은 대부분 실행 계획 부리를 목적으로 작성
- Join Factorization은 실행 계획 분리를 방해
- TRUE / FALSE (Default/Recommand)

_optimizer_skip_scan_enabled
- Data 분포가 특별한 케이스에서만 효과 있음
- 대부분의 경우 성능을 악화.
- TRUE/ FALSE (Default/Recommand)


And

[Oracle 공식입장] DB 형상 변경과 업무의 상관관계

|

DB 형상 변경과 관련한 업무 영향도.

※ 형상 변경이란 DDL(Create,Alter,Drop)로서 DB Object(테이블,파티션,인덱스,시퀀스,Procedure...)에 대한 구조 변경 SQL을 의미

 

본 내용에서는 테이블/인덱스에 대한 변경이 업무에 미치는 영향에 한정하여 설명합니다.

 

오라클은 데이타의 정합성, 일관성과 Structure 보호를 위해 내부적으로 "Lock"이라는 기술을 사용하며, Lock은 크게 3가지로 나뉘닙다.

1. DML Locks : 데이타 보호                   => row locks

               ex) INSERT,UPDATE,DELETE,MERGE,SELECT ... FOR UPDATE,LOCK TABLE

2. DDL Locks : 유저 Objects의 Structure 보호 => table, view, sql area

               ex) CREATE ..., DROP ..., ALTER ...

3. System Locks : Internal DB Structure 보호 => latch, mutex

 

이중에서 DDL Lock이 업무에 미치는 영향은 다음과 같습니다.

첫째, DDL 명령 실행 단계로 명령문 수행이 실패하는 경우입니다.

      대부분의 DDL 문장은 Lock 획득을 위해서 관련된 Object에 대해서 배타적인 Lock을 요구합니다.

      이 얘기는 트랜잭션으로 인한 DML Lock이 없어야 되며, 트랜잭션이 지속적인 상황에서는

      DDL 문장이 수행되지 못하고 아래와 같은 오류가 발생합니다.

      ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired

      이를 위한 대응 방안으로 오라클은 "ddl_lock_timeout"이라는 파라미터로 일정시간(0~1,000,000초)동안

      내부적으로 계속 DDL 수행을 시도할 수 있습니다.

      ex) alter session set DDL_LOCK_TIMEOUT=30;

      따라서 빈번한 트랜잭션이 발생하는 DB에서는 Lock 획득 실패 가능성이 있으며, 이럴경우에는 

      DDL 문장 수행을 위해서 일시적인 업무 중지등 별도의 Downtime(PM)이 필요합니다.

 

둘째, DDL 명령이 수행되는 동안의 Lock 발생입니다.

      통상적인 경우에는 DDL 문장이 짧지만 일부 상황에서는 장시간 소요될 수 있습니다.

      이런경우 명령이 완료될때까지 관련된 Object를 참조하는 모든 트랜잭션이 Lock될 수 있습니다. ==> Hang

      ex) alter table T (add col_x varchar2(100) default 'a');   ==> default 값 지정

          create index IND1 on tab1 (col1, col2, col3);          ==> index NON online

          alter table T drop partition T1 update global indexes; ==> update index

      따라서 장애 예방을 위해서는 동일한 Case를 개발 시스템에서 테스트하여 소요 시간 및 

      영향도를 파악하여 PM 수립후 진행할 필요가 있습니다.

 

셋째, DDL 명령이 완료된 이후의 트랜잭션 Wait 현상입니다.

      DDL 명령 수행시 관련 Object를 참조하는 SQL Area의 LCO(Library Cache Object)에 대해서

      invalid 상태로 변경되고, 모든 SQL 수행은 Hard Parsing을 필요로 할 수 있습니다.

      SQL 수행시 파싱 단계에서 해당 SQL에 대한 LCO 획득이 필요하며, 빈번하게 사용되는 SQL의 경우

      Library Cache와 관련된 대기 Event를 장시간 대기할 수 있으며, 심각한 경우에는 DB Restart가 필요할 수 있습니다.

      ex) library cache pin, library cache lock, library cache load lock

      따라서 트랜잭션이 많은 경우에는 Parsing을 유발할 수 있는 DDL 사용 자제를 권고합니다.

 

결론적으로

모든 DDL 문장은 다양한 위험 요소를 내포하고 있으므로, 유사한 개발/테스트 환경에서 충분한 검증을 실시하고,

가급적이면 PM 시간을 확보하여 수행하시기를 권고합니다.

만약 PM이 불가능한 상황이라면 트랜잭션이 최소인 시간을 선택하여 수행하시되 위에 언급된 상황에 대비한

Contingency Plan이 필요합니다.


From. 오라클 공식입장 박기종 부장


'02.IT Stroy > 022.Database' 카테고리의 다른 글

[Oracle] Partition Split  (0) 2015.03.03
[Oracle] 11g Parameter  (0) 2014.11.28
And
prev | 1 | next