DB 점검 도중, 약 60만건의 테이블에(담당자가 메인테이블이라고..) index가 20개 이상이 걸려 있는 것을 확인했다.

 

그리고 대부분 index들이 결합인덱스보다는 단일인덱스 인 것을 확인하고,

담당자에게 모두 필요한 index라고 물어보니

필요에 의해서 해당 테이블과 연관된 담당자들에 의해서 생성한 거라고,

자기도 잘 모른다고 하더군...

 

흠...내가 소속 DBA가 아닌 파견도..아닌 협력업체...DBA이다 보니..

이러지도 저러지도 못하는 상황..

 

보고는 하였지만..그래도 나는 DBA의 지부심이 있기에!!!내가 주체가 되어...제안....

"우리 INDEX 모니터링 걸어서 불필요한 거는 제거하고,

필요한 거는 새로 걸자고 제안....

 

index monitoring 관련 쿼리를 확인해 봤다.

 

1. index monitoring 여부 확인

 

-- 해당 user 라면 아래 쿼리를 이용하여 확인이 가능

SELECT table_name,
       index_name,
       monitoring
FROM   v$object_usage
WHERE  table_name = UPPER('&1')
AND    index_name = DECODE(UPPER('&2'), 'ALL', index_name, UPPER('&2'));

 

--나는 DBA다!!!!

col owner for a10
col index_name for a20
col table_name for a20

 

SELECT U.NAME OWNER,
IO.NAME INDEX_NAME,
T.NAME TABLE_NAME,
DECODE(BITAND(I.FLAGS, 65536), 0, 'NO', 'YES') MORNITORING,
DECODE(BITAND(OU.FLAGS, 1), 0, 'NO', 'YES') USED,
OU.START_MONITORING,
OU.END_MONITORING
FROM SYS.USER$ U,
SYS.OBJ$ IO,
SYS.OBJ$ T,
SYS.IND$ I,
SYS.OBJECT_USAGE OU
WHERE I.OBJ# = OU.OBJ#
AND IO.OBJ# = OU.OBJ#
AND T.OBJ# = I.BO#
AND U.USER# = IO.OWNER#;

 

-- v$object_usage는 자신의 index 만 확인 가능하기에 이 점 유의!!

 

2. index에 모니터링이 걸려 있지 않으면 아래 쿼리를 이용하여 명령문을 만들 수 있다.

 

-- owner 와 table_name 을 입력해야 함

 

SELECT 'ALTER INDEX "' || i.owner || '"."' || i.index_name || '" MONITORING USAGE;'
FROM   dba_indexes i
WHERE  owner      = UPPER('&1')
AND    table_name = DECODE(UPPER('&2'), 'ALL', table_name, UPPER('&2'));

 

 

 

 

3. 다시 체크한 결과 (위의 index monitoring 으로 조회)

 

 

 

4. index에 모니터링이 걸려 있는 것에 대해 해제 하는 명령어

 

 
SELECT 'ALTER INDEX "' || i.owner || '"."' || i.index_name || '" NOMONITORING USAGE;'
FROM   dba_indexes i
WHERE  owner      = UPPER('&1')
AND    table_name = DECODE(UPPER('&2'), 'ALL', table_name, UPPER('&2'));

 

 

이렇게 하여 일단 체크를 진행하기 시작했다.

 

여기서 반은 걷어 냈으면 하는 바램이...

 

 

 

반응형

'Oracle > DBA' 카테고리의 다른 글

[Oracle] Process / Session 모니터링  (0) 2016.01.17
[펌][ORACLE] ORA-에러  (0) 2015.12.22
[Oracle] Partition Local Index 테스트  (0) 2015.12.02
[ORACLE] ASM 에 Datafile 추가  (1) 2015.11.25
[Oracle] OWI Latch & Lock 정리  (0) 2015.11.24

아흐..

지난 주 스터디 하면서 자신있게 Partition Table 과 관련하여 발표 도중

Partition Local index 에서 맨붕이 와버렸다..


그래도 내가 알려주는거에 대한 책임감(??변명..) 때문에 다음에 다시 발표하겠다 한 후 

이제서야 테스트 하면서 결과에 대해서 공유해 본다.


1. 파티션 테이블 생성


SQL> create table test_a

(col1 number,

col2 number,

col3 varchar2(20))

Partition by range (col1, col2)

(Partition part_test_a_1 values less than (10, 100),

Partition part_test_a_2 values less than (20, 200) ,

Partition part_test_a_3 values less than (30, 300) ,

Partition part_test_a_4 values less than (40, 400) );


2. Local Index 생성
(여기서 맨붕이 왔다. 내가 테스트한 부분은 아래와 같이 생성하였으며 이렇게 생성해야만 하는걸로 알고 있었다..)

SQL> create Index ix_test_a on test_a(col1, col2) Local

(Partition in_test_a_1 ,

Partition in_test_a_2 ,

Partition in_test_a_3 ,

Partition in_test_a_4 );


조회해 보면 아래와 같다



하지만 책에는 아래와 같이 나와 있다.

SQL> create index ix_test_a on test_a(col1, col2) local;



확인해 보면 partition_name 만 틀릴 뿐 나머지는 동일하다.


partition name 은 어떻게 되는걸까?

Table를 다시 생성해 본다


SQL> create table test_c

(col1 number,

col2 number,

col3 varchar2(20))

Partition by range (col1, col2)

(Partition test_c_1 values less than (10, 100),

Partition test_c_2 values less than (20, 200) ,

Partition test_c_3 values less than (30, 300) ,

Partition test_c_4 values less than (40, 400) );


SQL> create index ix_test_c on test_c(col1, col2) local;



Index Partition_Name은 명시해 줄 경우 명시된 partition 이름으로 가며, 

명시안하는 경우 Partition Table의 partition name을 따라가는 것을 확인할 수 있다.



왜 이렇게 쉬운 부분에서 멘붕이 오냐고 질책할 수 있지만...내 잘못입니다...ㅠㅠ

테스트 꼭 해보고 책도 한번씩 쿼리 다 작성해서 결과확인 후 진행 하도록 하겠습니다.

죄송합니다.ㅠ


한가지 더 테스트로 Local index 를 명시하되, 파티션 table과 동일한 갯수로 생성을 안하면 어떻게 되는걸까,


SQL> create Index ix_test_a on test_a(col1, col2) Local

(Partition in_test_a_1 ,

Partition in_test_a_2 ,

Partition in_test_a_3);



우리가 책에서 배웠듯이 에러가 발생한다.


아래는 내가 어떤 자료를 보고 정리한 내용이다.



구분

적용 기준 및 고려 사항

비 파티션

-       파티션 키 칼럼이 조건절에 누락되면 여러 인덱스 파티션을 액세스해야 하므로 비효율적. 특히, OLTP 환경에서 성능에 미치는 영향이 크므로 비파티셔닝 전략이 유용할 수 있음


-       NL Join 에서 파티션 키에 대한 넓은 범위검색 조건을 가진 Inner 테이블 액세스 용도로 인덱스 파티션이 사용된다면 효율적 -> 비파티션 인덱스 사용을 고려


-       파티션 인덱스를 이용하면 sort order by 대체 효과 상실. Sort 연산을 대체함으로써 부분범위 처리를 활용하고자 할 땐 비파티셔닝 전략이 유용


-       테이블 파티션 이동, 삭제 등의 작업 시 unusable 되므로 적용 시 주의

Global Prefixed

     - 인덱스 경합 분산에 효과적


     - 여러 Local 인덱스 파티션을 액세스하는 것이 비효율적일 때 대안으로 활용 가능


     - 테이블 파티션 이동, 삭제 등의 작업 시 unusable 되므로 적용 시 주의

Local Prefixed

-       관리적 특면에서 유용 : 테이블 파티션에 대한 추가, 삭제 등의 작업이 빈번할 때


-       이력성 데이터를 주로 관리하는 DB 환경에 효과적


-       파티션 키 칼럼이 “=” 조건으로 사용될 때 유용


-       파티셔닝 칼럼에 대한 검색 조건이 없으면, 인덱스 선두 칼럼이 조건절에 누락된 것이므로 정상적인 사용이 불가 (Index Full Scan 으로는 선택 가능)


-       파티션 키 칼럼(=인덱스 선두 칼럼)Like, Between, 부등호 같은 범위검색 조건일 때 불리

Local Non Prefixed

-       관리적 측면에서 유용 : 테이블 파티션에 대한 추가, 삭제 등의 작업이 빈번할 때


-       이력성 데이터를 주로 관리하는 DB 환경에 효과적


-       파티션 키 칼럼이 조건절에 사용될 때 유용


-       파티셔닝 칼럼에 대한 검색 조건이 없으면 인덱스 파티션 전체를 액세스하는 비효율이 발생할 수 있으므로 주의


-       파티션 키 칼럼이 범위검색 조건으로 자주 사용된다면 Local Prefixed 보다 Local NonPrefixed가 유리. 그렇더라도 좁은 범위검색이어야 함



반응형

'Oracle > DBA' 카테고리의 다른 글

[펌][ORACLE] ORA-에러  (0) 2015.12.22
[Oracle] Index monitoring  (0) 2015.12.14
[ORACLE] ASM 에 Datafile 추가  (1) 2015.11.25
[Oracle] OWI Latch & Lock 정리  (0) 2015.11.24
[펌][Oracle] 대용량 자료전환 시 튜닝 포인트 - Hash join  (0) 2015.11.19

가끔 Datafile 옮길...일이 없지만..

이번 운영 확인하다 보니, datafile 이 엔진쪽에...헉!!!!


HA 장비라서 엔진쪽에 있으면 안되는데...왜???누가???


에휴...고객사 장비라 누가 건든지 알수 없으니..

더 큰 문제가 생기기 전에 옮겨줘야겠다..


1. Database 로 진행 (DB Shutdown 필요)

2. Tablespace 로 진행 (DB Shutdown 필요 없음)


1. Database 로 진행

- Tablespace 및 Datafile 확인

- DB shutdown 후 Mount 로 startup 진행


SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.


SQL> startup mount

ORACLE instance started.


Total System Global Area  612368384 bytes

Fixed Size                  2079480 bytes

Variable Size             176162056 bytes

Database Buffers          427819008 bytes

Redo Buffers                6307840 bytes

Database mounted.


- 해당 Datafile 를 이동 후 rename 진행


SQL> alter database rename file 'E:\MASDBDEV\HG1.dbf' to 'E:\HG1.dbf';


- Database open 진행


SQL> alter database open;

Database altered.


- 확인

SQL> select file_name, tablespace_name from dba_data_files order by 2;


FILE_NAME                                TABLESPACE_NAME

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

E:\MASDBDEV\HG2.DBF                      HG

E:\HG1.DBF                               HG

E:\MASDBDEV\IMSI01.DBF                   IMSI

E:\MASDBDEV\SYSAUX01.DBF                 SYSAUX

E:\MASDBDEV\SYSTEM01.DBF                 SYSTEM

E:\MASDBDEV\TEST01.DBF                   TEST

E:\MASDBDEV\UNDOTBS01.DBF                UNDOTBS1

E:\MASDBDEV\USERS01.DBF                  USERS




2. Tablespace 로 진행


- Tablespace 및 Datafile 확인



- 옮기고자 하는 Datafile 의 Tablespace 를 offline 진행


SQL> alter tablespace HG offline;


- Offline 이 후 해당 Datafile 를 이동 후 rename 진행


SQL> alter tablespace HG rename datafile 'E:\HG1.dbf' to 'E:\MASDBDEV\HG1.dbf';


- Rename 까지 완료 되면 다시 online 진행


SQL> alter tablespace HG online;


- 옮겨 졌는지 확인 후 Test로 Talbe 를 Select 해 보자.


혹시라도 Tablespace offline 이 후 Table를 select 하면 아래와 같이 오류가 나니 가급적 업무 시간에는 진행하지 말자.


ERROR at line 1:

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

ORA-01110: data file 7: 'E:\HG1.DBF'



또한, SYSTEM, Rollback segment혹은 Temporary segment를 포함하는 테이블스페이스는 안되므로 이때는 Database로 진행


ERROR at line 1:

ORA-01541: system tablespace cannot be brought offline; shut down if necessary


오늘도 기초를 한번 더 상기해 보자!!

반응형

+ Recent posts