달력

09

« 2018/09 »

  •  
  •  
  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  •  
  •  
  •  
  •  
  •  
  •  
* 대량 배치작업에서 해당 오류 발생 프로시저가 더이상 진행를 하지 못하고 스톱되었다.
* 여기저기 찾아보니 append insert 한 데이터는 바로 읽지를 못한다고 하는데.....

* 실험
-- 테이블 하나를 만들고..
create table ttt1 (idx number);

-- 페러럴로 데이터를 쳐넣어봅시다.
insert /*+ append parallel(2) */ into ttt1 select level from dual connect by level <= 100000

-- commit 하지 않고 바로 조회
select *from ttt1;

ORA-12838 cannot read/modify an object after modifying it in parallel

생각지도 않은 대량의 데이터 처리 작업에서 commit을 하지 않고 트랜잭션이 끝나고 그결과에 따라서
commit / rollback 을 하려했는데 문제가 있다.

임시테이블같은곳에 넣고 작업을 해서 처리완료.

Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설
2011.05.04 09:09

Test1. CLOB -> VARCHAR로 변경 Oracle/Oracle testing2011.05.04 09:09

테스트 환경 
OS : Oracle Enterprise Linux 5.5 (x64) ( Vmware )
DB : ORACLE 11g R2 Ent. 
Storage Type : Ext3 ( FileSystem )

기존 CLOB 데이터가 있는 대량의 데이터가 있다.
이 데이터를 어디서든 활용을 하기위해서 
데이터를 좀더 빠른 상태로 구축하기위한 DW 작업을 해야하는 상황이 왔다.

CLOB 을 개선해야하는 상황이다.

사실 난 개발하면서 CLOB을 별로 좋지 않게 생각을 했다.
개발에서도 단순하게 컬럼데이터를 가져오는 형태로 개발을 할수가 없다.
아무리 못해도 1줄이 더 가면 갔지 줄지는 않는다.

여하튼 내 상황에서는 

clob 데이터의 data length 를 확인해보니.
최대 6000 최소 2~300 ? 정도? 
평균 1000이 약간 안된다.(물론 Byte) 

그래서 결정했다.

1000바이트씩 자르기로 했다.
nvarchar 형태의 데이터니.

nvarchar2(2000) 으로 두고 기존 clob 데이터를 자르면서 그에 대한 시퀀스값을 만들었다.
그리고 1개의 데이터에 대해서 여러개의 row 생성해야하기에 테이블 하나에 1,2,3,4... .를 넣어서 
묻지마 조인을 했다.

                  select  idx

    ,seq

                       ,result

                 from ( select   seq

                                    ,case when ct_len  + 990 <= seq * 990 then null else 1 end hwpoint 

                                    ,substr(ct ,(seq -1) * 990 + 1 ,990)  result

                                    ,skey

                                from  (   select  row_number() over (partition by idx order by idx) seq

                                                     ,length(ct) ct_len

                                                     ,ct

                                                     ,idx

                                              From  ct, stNumber ) )

               where hwpoint = 1 ;                 


-  substrb 도 쓸만했으나 바이트로 자르고나서 다시 붙이니까 문자들이 종종 사라진다.
끝부분이 잘리면서 약간 안맞는듯하다.
-  substr 을 가지고 자르게 되면 unicode같은 경우는 byte 가 되니 약간의 여유를 두고 자르기를 했다. 난 990 으로. 자르기를 시도.

-  자르고 난뒤 not null 인 컨텐츠들만 select 하면 문제가 없을줄 알았는데 막상 자르니 null 이 아니다.
('fadsfadsf' 의 데이터를 substr을 하고 빈 값을 또 자르면 null 아니고 무언가 값이 자꾸 남아서 위처럼 case 문으로 자른 데이터 길이가 전체 데이터보다 작다 /크다로 구분해서 (hwpoint) select 를 했다.


결과.

위 처럼 데이터를 자르고나서 테이블에 넣고 기존에 clob 데이터와 비교를 했다.
물론 plan를 봐야겠다. 
DW작업이라 FTS 가 많을 터라. 인덱스도 없이 그냥 select 를 해서 읽혀지는 것을 보기로 했다.

case 1. - clob 데이터가 있는 테이블 full scan

Execution Plan

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

Plan hash value: 1602174258


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

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT  |      | 29911 |  3037K|  1112   (1)| 00:00:16 |

|   1 |  TABLE ACCESS FULL| CT   | 29911 |  3037K|  1112   (1)| 00:00:16 |

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



Statistics

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

       1935  recursive calls

         12  db block gets

      30896  consistent gets

       2984  physical reads

          0  redo size

  102966406  bytes sent via SQL*Net to client

   48876214  bytes received via SQL*Net from client

      59824  SQL*Net roundtrips to/from client

         41  sorts (memory)

          0  sorts (disk)

      29911  rows processed


case 2. - nvarchar 로 자른 데이터가 있는 테이블 full scan

Execution Plan

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

Plan hash value: 530917727


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

| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT  |      |     1 |  1092 |   497   (1)| 00:00:07 |

|   1 |  TABLE ACCESS FULL| CT  |     1 |  1092 |   497   (1)| 00:00:07 |

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



Statistics

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

        338  recursive calls

          0  db block gets

       1365  consistent gets

       1327  physical reads

          0  redo size

        665  bytes sent via SQL*Net to client

        513  bytes received via SQL*Net from client

          1  SQL*Net roundtrips to/from client

          5  sorts (memory)

          0  sorts (disk)

          0  rows processed


뭐 당연한 결과다.
CLOB 부르는게 어찌 비용이 싸겠는가.
아무리 DW 지만 clob 은 이래저래 -_- 거시기 하다.


 
Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설

시골에 가있는 동안 . 새벽에 11g에서 테스트를 하나 했다.
대단한 테스트는 아니고.

11g에서 트랜잭션을 일으켜서
주요 PROCESS 에서 발생하는 이벤트 구경하기를 했다.

그런데 ㅡ_ㅡ;;; 이짓을 하다가 db를 날렸다.
백업도 안했는데 DB를 날려서 다시 create db작업을 한 과정을 작성한다.

사실 아래 테스트는 내가 회사다니면서 
직접 일을 저지른 일이다. ㅡ_ㅡ;;;;

O/S : Linux 64Bit Centos5
Oracle Version : 11g R2

총 3개의 세션에서 일을 시키고 그 과정을 trace를 했다.
세션 1.  -- select 문 order 많이 한
begin
        for i in 1..10000000 loop
        execute immediate 'select *from sh.sales order by 1,2,3,4,5 desc';
        end loop;
end;
/

세션 2. -- update and rollback
begin
        for i in 1..1000000 loop
        execute immediate 'update sh.sales set amount_sold = '||i;
        rollback;
        end loop;
end;
/

세션 3. -- memory 초기화
begin
        for i in 1..100000 loop
        execute immediate 'alter system flush buffer_cache';
        execute immediate 'alter system flush shared_pool';
        end loop;
end;
/


3개의 세션에서 작업을 진행하면서
CKPT, LGWR , DBWR, SOMN, ARC 에서 이벤트를 구경했다.

많이 보여진 이벤트순으로 나열한것이다.

::: LGWR :::
1. log file parallel write
2. control file sequential read
3. log file single write
4. LGWR wait for redo copy
5. enq: CF - contention

::: CKPT :::
1. control file sequential read
2. control file parallel write
3. db file sequential read
4. db file single write
5. latch: cache buffers chains
6. latch: cache buffers lru chain
7. latch free

::: DBWR :::
1. control file sequential read
2. db file async I/O submit
3. Disk file operations I/O
4. latch free
5. latch: cache buffers lru chain
6. latch: object queue header operation
latch: cache buffers chains

::: SMON :::
1287049654689186  SYS_FBA_FA
1287049654689992  insert smon_scn_time
1287049654690709  cdef$
1287049654691248  hist_head$
1287049654693582  cdef$
histgrm$
lock table sys.mon_mods$ in exclusive mode nowait
update sys.mon_mods$
hist_head$
lock table sys.mon_mods$ in exclusive mode nowait
update sys.mon_mods$
lock table sys.mon_mods$ in exclusive mode nowait
update sys.mon_mods$
lock table sys.col_usage$ in exclusive mode nowait
update sys.col_usage$
insert into sys.col_usage$
obj$

::: ARC :::
1. latch free
2. Disk file operations I/O
3. control file sequential read
4. ARCH wait for archivelog lock
5. log file sequential read
6. control file parallel write
7. Log archive I/O

ORA-19815: WARNING: db_recovery_file_dest_size of 4070572032 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.

2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.

3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.

4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 47035392 bytes disk space from 4070572032 limit
*** 2010-10-14 19:30:08.446 4132 krsh.c
ARC0: Error 19809 Creating archive log file to '/u02/flash_recovery_area/ORCL/archivelog/2010_10_14/o1_mf_1_89_%u_.arc'
*** 2010-10-14 19:30:08.446 2747 krsi.c
krsi_dst_fail: dest:1 err:19809 force:0 blast:1


DDE: Problem Key 'ORA 312' was flood controlled (0x1) (no incident)
ORA-00312: online log 2 thread 1: '/u02/oradata/orcl/redo02.log'
*** 2010-10-14 19:30:08.453 4529 kcrr.c

DDE rules only execution for: ORA 312
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
----- START DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (Async) -----
Successfully dispatched
----- END DDE Action: 'DB_STRUCTURE_INTEGRITY_CHECK' (SUCCESS, 0 csec) -----
Executing ASYNC actions
----- END DDE Actions Dump (total 0 csec) -----
*** 2010-10-14 19:32:11.774 4529 kcrr.c

#######################################################################################
위와 같은 이벤트들이 발생하고 에러가 떨어지는모습을 봤다.
순식간에 많은 트랜잭션이 발생하여 대량의  로그가 발생하여 풀발생.

::: 상황발생 :::
1. 아카이브 작업 실패!

짧은시간에 큰 트랜잭션을 시도했더니. 아카이브를 쓰면서 너무 많이쓰다가 쓰기를 포기했나보다.
죽지도 않는다 ㅡ_ㅡ;;;

2. shutdown abort 시도 완료.

예상대로

3. SQL> startup
ORACLE instance started.

Total System Global Area  839282688 bytes
Fixed Size                  2217992 bytes
Variable Size             478152696 bytes
Database Buffers          352321536 bytes
Redo Buffers                6590464 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 20784
Session ID: 125 Serial number: 5


SQL> select status from v$instance;
ERROR:
ORA-03114: not connected to ORACLE


SQL>

실패;;;;


4. recover database until cancel;
alter database open resetlogs;

alert 로그를 보니.

Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_21014.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 47035392 bytes disk space from 4070572032 limit
ARCH: Error 19809 Creating archive log file to '/u02/flash_recovery_area/ORCL/archivelog/20
10_10_14/o1_mf_1_90_%u_.arc'
RESETLOGS after complete recovery through change 1360520
Resetting resetlogs activation ID 1260103569 (0x4b1ba791)
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_21014.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log'
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_21014.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 2 of thread 1 is not current copy
ORA-00312: online log 2 thread 1: '/u02/oradata/orcl/redo02.log'
Thu Oct 14 20:41:32 2010
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_21104.trc:
ORA-00316: log 1 of thread 1, type 0 in header is not log file
ORA-00312: online log 1 thread 1: '/u02/oradata/orcl/redo01.log'
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_21014.trc:
ORA-00367: checksum error in log file header
ORA-00322: log 3 of thread 1 is not current copy
ORA-00312: online log 3 thread 1: '/u02/oradata/orcl/redo03.log'
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_21104.trc:
ORA-00316: log 2 of thread 1, type 0 in header is not log file
ORA-00312: online log 2 thread 1: '/u02/oradata/orcl/redo02.log'
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m000_21104.trc:
ORA-00316: log 3 of thread 1, type 0 in header is not log file
ORA-00312: online log 3 thread 1: '/u02/oradata/orcl/redo03.log'
Checker run found 7 new persistent data failures
Thu Oct 14 20:41:33 2010
Setting recovery target incarnation to 3
Thu Oct 14 20:41:33 2010
Assigning activation ID 1260161751 (0x4b1c8ad7)
LGWR: STARTING ARCH PROCESSES
Thu Oct 14 20:41:33 2010
ARC0 started with pid=20, OS id=21108
ARC0: Archival started


open 은 되었고
5. 다시 shutdown immediate 를 시도.

헛~


SQL*Plus: Release 11.2.0.1.0 Production on Thu Oct 14 20:48:25 2010

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

Enter user-name: /as sysdba
Connected.
SQL>

alert 로그에....
ORA-19815: WARNING: db_recovery_file_dest_size of 4070572032 bytes is 100.00% used, and has 0 remaining bytes available.

결국 또 먹통
6. 그래서 arc 를 전부 지웠다.

그리고나서 다시 shutdown immediate 시도 헛.
안된다....

7. 먹통 os상에서 oracle process 전부 종료.
8. 다시 sqlplus들어가니.
??? 아무메세지가 안나온다.

SQL*Plus: Release 11.2.0.1.0 Production on Thu Oct 14 20:48:25 2010

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

Enter user-name: /as sysdba
Connected.
SQL>

ㅡ_ㅡ;;;;;

어떻게 할까 최고의 명답안 리부팅을 할것인가 말것인가????
흠.... 왜... process에 아무것도 없는데 저렇게 될까나....


9. 리부팅 시작..


답이 안나온다..

백업안하고 이짓저짓하다가 결국 날렸다 ㅡ_ㅡ;;;;

※ 물론 딱 이상황의 문제는 DISK FULL이었다.
개별로 다시 위와같은 상황을 만들어서 에러가 발생한 상황을 만들어서 alert_log에 FULL 메세지가 뜨면
다른세션에서 ALTER SYSTEM SET db_recovery_file_dest_size='5G'; 를 실행하면 해결은 된다.
그러면 다시 아카이브를 쓰고 작업을 하게된다.
( 물론 사이즈를 늘리고 바로 작업이 되는게 아니라 좀 대기시간이 발생하고 나서
계속 archive 작업을 한다. )

아래는 alter 작업을 한 결과 alert_log에 나온 메세지이다.

db_recovery_file_dest_size of 5120 MB is 75.35% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon Oct 18 19:57:10 2010
ALTER SYSTEM SET db_recovery_file_dest_size='5G' SCOPE=BOTH;

SQL> alter database open resetlogs;
alter database open resetlogs
*

ERROR at line 1:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 52428800 bytes disk space from 1073741824 limit

SQL> alter system set db_recovery_file_dest_size='3G';

System altered.

SQL> alter database open resetlogs;

Database altered.

SQL>




아무튼.
백업의 중요성과 ㅡ_ㅡ;;;
짧은시간의 트랜잭션이 많을경우는 충분한 db_recovery_file_dest_size , 그리고
큰 redo 사이즈.... 가 중요하다는것을 뼈저리게 느꼈다.

Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설
2010.10.15 08:38

MMON, MMAN, MMNL Oracle/Oracle testing2010.10.15 08:38

Oracle 10g 에 새로 생긴 프로세스인 MMON, MMAN, MMNL
AWR과 큰 관련이 있는 이 프로세스들을 11g에서 DUMP를 떠서 뭔 지랄을 하는지 ㅡ_ㅡ;;
뭔 테이블을 참조하는지 봤다.

대략 2시간동안
특정세션에서 이짓저짓을 하면서

3개의 세션에서 모니터링을 했다.

::::: MMON :::::

시간 : 테이블이름.
1287039314171796  :  smon_scn_time
1287039614283598  :  SYS_FBA_FA
1287039614283888  :  smon_scn_time
1287039614366329  :  sys.scheduler$_window
1287039614367015  :  col$
1287039614414938  :  col$
1287039614416287  :  sys.scheduler$_window
1287039614420280  :  sys.scheduler$_jo, sys.scheduler$_lightweight_job, sys.job$, sys.scheduler$_class
1287039914616171  :  SYS_FBA_FA
1287039914616498  :  smon_scn_time
1287040214721170  :  SYS_FBA_FA
1287040214721367  :  smon_scn_time
1287040214773224  :  sys.scheduler$_window, sys.scheduler$_wingrp_member
1287040514901203  :  SYS_FBA_FA
1287040514901522  :  smon_scn_time
1287040514902328  :  sys.scheduler$_window
1287040514902911  :  sys.scheduler$_jo, sys.scheduler$_lightweight_job, sys.job$, sys.scheduler$_class
1287040815115501  :  SYS_FBA_FA
1287040815186561  :  update WRI$_SCH_CONTROL

다른 잡소리는 빼고 어떤 테이블들만 조회하는지 봤다.

주기적으로 smon_scn_time 으로 scn값을 조회해서
해당 시간대의 데이터를 가져와서 update하는듯하다. 그리고
시간이 되면
v$shared_pool_advice
v$java_pool_advice
v$db_cache_advice
v$pga_target_advice

뷰를 조회도 한다.

::::: MMAN :::::

SGA: MMAN sleep for component shrink

MMAN 에서는 별로 하는일이 없었다. - 물론 내부적으로는 모르지만...
일단 보였던 이벤트는 SGA: MMAN sleep for component shrink


::::: MMNL :::::

MMNL도 별로 하는일은 없었으나 지속적(물론 쉬는시간이 길지만)으로 file$를 계속  조회를 했다.

1287039678917475  file$
1287039979367207  file$

select *From file$ 를 해보니
테이블스페이스 정보가 나온다.

TAG 11g, mman, MMNL, mmon, R2
Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설

오라클 양성반 교육중이다.
10g R2를 가지고 교육중인데.
교육이라 오라클 서버를 매일 켜놓지는 않는다.
매일 수업을 하고 끄고 또 다음날 교육을 하고 또 끄고.
24시간이상 켜있는 적이 없다.

오라클 내부적으로 뭐 그닥 내부는 아니겠지만.
잡이 돌고있다.

통계재생성작업! 잡이다.

기본값이 매일 10시인데
10시는 꺼져있는지라 통계생성을 안한다.

교육이 60%정도 진행된시점에서 DBA_TABLE.LAST_ANALYZED를 조회해보니.
날짜가 그대로다.

그런데 보면 날짜가 좀 이상하다.
난 오라클 교육한 날짜가 2010년8월인데 통계날짜는 2005년 6월 30일이다.

아래 SELECT 문으로. 조회를 하고나서 나온결과가 그렇다.

select OWNER,TABLE_NAME,TABLESPACE_NAME,LAST_ANALYZED From dba_tables order by LAST_ANALYZED




오라클 10G R2 는 출시가 2005년 9월 경에 나왔다.

2005년 6월 30일. 그럼 이것들은....???

예상되는 몇가지가 보인다.

1. 오라클 설치시에는 통계재생성작업은 안한다.
2. 2005년 6월 30일이 내부적개발이 끝나고 테스트를 하기위해서 마지막에 통계생성작업을 저날짜(2005년 6월 30일)에 했다.
3. 19시 인걸보니 저 개발자가 걸어놓고 퇴근했나보다. ㅡ_ㅡ;;;;
4. 릴리즈 전에 테스트 기간이 대략 2달정도 되나보다. (물론 내부적으로 다시 수정할수도있고 기타 다른 문제로인한 또는 다른일로 인한 지연이 있을수도있지만...)


아래내용은 11g R2 설치는 2010년에 10월에 했으나
역시 2009년 8월 15일 00시다.
11g R2 돌릴때도 야근했나 ㅡㅡ;;;
설치하고나서 한번은 돌려줘야할듯하다.


Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설

이벤트 클래스중에서 가장 이슈가 될만한것은
Concurrency 가 되지 않을까 싶다.

10g R2 에 비해서 11g R2 에 추가된 이벤트가 추가되었을까?

선행작업 :

Vmware 11g R2 설치
Vmware 10g R2 설치.

각각의 tnsnames.ora 설정후 DB링크작업을 해준다.

create public database link COMPDB11G connect to flashone identified by ORACLE using 'TEST11G'
create public database link COMPDB10G connect to flashone identified by oracle using 'TEST10G'

10g 와 11g 를 DBLINK작업을 한후에
이제 SELECT를 시도.

11g에서
select * from v$event_name where event_id in (
select EVENT_ID from v$event_name WHERE wait_class = 'Concurrency'
minus
select EVENT_ID From v$event_name@COMPDB10G  WHERE wait_class = 'Concurrency')

기존 10g R2 에서는 이벤트가 874개.
11g R2 에서는 이벤트가 1118개
빼면 380개가 된다.

위의 SELECT 문은 그 380개의 이벤트를 가져온 sql문이다.
그중에서 Concurrency 가 가장 궁금한지라
이것들만 조회를 시도했다.

그랬더니. 11개의 결과가 출력되었다.

EVENT NAME

logout restrictor
Shared IO Pool Memory
db flash cache invalidate wait
securefile chain update
SecureFile mutex
enq: WG - lock fso
cursor: pin X
cursor: pin S
library cache: mutex X
library cache: mutex S
Streams apply: waiting for dependency

위의 이벤트를 조사해 보기로 했다. (아는대로만)
구글에도 자료가 별로없고 그렇다고 내가 META LINK를 들어갈수있는 권한이 있는것도 아닌지라
난감. ㅡ_ㅡ;;


1. enq: WG - lock fso
우선 enq니 v$lock_type 를 조회해보면 description에 Long term lock on wgc file state라는 말이 보인다.
그러면 WGC가 또 무엇인가해서 찾아보기로했다.

이 단어를 가지고 이곳저곳의 자료를 찾아보게되면
LOB write 와 연관이 있다는것을 알게된다.

11g에 새로 생긴 기능으로서.

기존 10g LOB DATA를 쓸때는 direct path 를 사용해서
쓰게된다 . SGA를 그냥 바이바이하고 넘어가게된다.

그런데 11g 에서는
그냥 무조건 파일을 쓰는게 아니고 메모리를 이용해서 쓴다고 한다.
4MB의 메모리의 캐시를 하면서 dbwriter 가쓴다고한다.

관련 파라미터 : _kdlw_enable_write_gathering
해당기능 활성화 : 11g R2를 설치해보니 기본으로 true

실제 돌아가는 알고리즘은 나도 알아보는중.


2. securefile chain update
3. SecureFile mutex

오라클 사이트에 11g를 광고하는 글중에

민감한 문서(계약서, X-레이 이미지 등)는 종종 전자적으로 스캔하여 저장합니다.
이제 Oracle Database의 한층 강화된 보안을 활용할 수 있습니다.
Oracle Database 11g의 새로운 'SecureFile' LOB를 암호화할 수 있습니다.
출처 : http://www.oracle.com/technology/global/kr/deploy/security/database-security/transparent-data-encryption/index.html

라는 말이 있다. 여기서 SecureFile 과 말이 동일한것을 보아 LOB암호화를 하는과정에서
발생하는 이벤트를 예기하는듯하다.


4. cursor: pin X
5. cursor: pin S
여기에서 말하는 cursor는 아마도 library cache 안의 cursor 를 말하는듯하다.
이 부분에서 pinning 작업을 하면서 직관적으로 pin 발생및 shared인지 exclusive인지 보여주는 이벤트로 보여진다.



6. library cache: mutex X
7. library cache: mutex S

기존 10g에서는 아래와 같은 이벤트를가지고 작동했던부분이
latch: library cache
latch: library cache lock
latch: library cache pin

11g에서는 mutex로 작동이 되는것이 아닐까?
그러면서 이또한 shared 와 exclusive 로 분류되어 직관적으로 이해할수있게 이벤트가 보여지는것같아보인다.

아래는 library cache 를 dump 를 해서 나온부분 중하나이다.
Bucket 부분에 Mutex로 된것을 봐선 Mutex로 바뀐듯하다.

...
Bucket: #=6 Mutex=8bb78d48(0, 17, 0, 6)
  LibraryHandle:  Address=85151968 Hash=8a3e0006 LockMode=0 PinMode=0 LoadLockMode=0 Status=VALD
    ObjectName:  Name=select s.serial#, p.spid, s.server from v$session s, v$process p where s.sid = 70 and
s.paddr = p.addr

      FullHashValue=9292705db02933e0c93cb87b8a3e0006 Namespace=SQL AREA(00) Type=CURSOR(00) Identifier=23193
19046 OwnerIdn=95
    Statistics:  InvalidationCount=0 ExecutionCount=1 LoadCount=2 ActiveLocks=0 TotalLockCount=1 TotalPinCou
nt=1
...


A세션 : UPDATE 문 반복
B세션 : alter system flush shared_pool;
C세션 : 모니터링

모니터링중에

아래와 같은 이벤트가 발생했다.
library cache lock
library cache lock

library cache: mutex X

8. Streams apply: waiting for dependency
오라클의 Stream Pool 을 이용한 DB간의 데이터 전송(물론 redo log capture한 데이터를 전송할경우에도)
시 발생하는 이벤트라고한다. - 자세한내용은 아직 ㅡ_ㅡㅋ;

다른이벤트도 있으나 자료가 별로없다 ㅡ_ㅡ;;; 테스트하는대로 갱신을 해야할듯하다.

Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설
Oracle 10g R2 (10.2.0)
startup을 하면 arc0 , 1, 2 가 뜨는데.
어느정도있다가 .
" Stopping ARC2 to reduce ARCH processes from 3 to 2 "
라는 메세지가 나오면서 프로세스 하나가 죽게된다.

기본 파라미터값 : log_archive_max_processes = 2

아래 프로세스 dump는 10g 아카이버이다.
도대체 뭔짓을 하길래. 그런메세지가 뜨나 해서.. 봤으나.
별내용은 없다....

:::: ARC0  프로세스 ::::
*** 2010-10-07 17:26:57.673
...
kcrrwkx: nothing to do (end)
*** 2010-10-07 17:27:57.677
WAIT #0: nam='rdbms ipc message' ela= 58597316 timeout=6000 p2=0 p3=0 obj#=-1 tim=1256289138357352
tkcrrxmp: Stopping ARC2 to reduce ARCH processes from 3 to 2
WAIT #0: nam='Wait on stby instance close' ela= 977127 p1=0 p2=0 p3=0 obj#=-1 tim=1256289139334927
WAIT #0: nam='Wait on stby instance close' ela= 977151 p1=0 p2=0 p3=0 obj#=-1 tim=1256289140312295
WAIT #0: nam='Wait on stby instance close' ela= 977266 p1=0 p2=0 p3=0 obj#=-1 tim=1256289141289723
WAIT #0: nam='Wait on stby instance close' ela= 978285 p1=0 p2=0 p3=0 obj#=-1 tim=1256289142268172
....
kcrrwkx: nothing to do (end)
-------------------------------------------------------------------------


:::: ARC2  프로세스 ::::
...
*** 2010-10-07 17:53:01.453 2520 kcrf.c
tkcrf_clear_srl: Started clearing Standby Redo Logs
WAIT #0: nam='control file sequential read' ela= 12 file#=0 block#=1 blocks=1 obj#=-1 tim=1256290606888447
....
tkcrf_clear_srl: Completed clearing Standby Redo Logs
*** 2010-10-07 17:54:06.307
WAIT #0: nam='rdbms ipc message' ela= 63327773 timeout=30000 p2=0 p3=0 obj#=-1 tim=1256290670222537
WAIT #0: nam='Log archive I/O' ela= 6 count=-1 intr=0 timeout=2147483647 obj#=-1 tim=1256290670223138
-------------------------------------------------------------------------

10g , 11g 에서 각 프로세스 맥스값을 변경시키면서 실제 OS에서 몇개의 프로세스가
뜨는지 확인해봤다.

테스트 결과.

  10g R2  11g R2
 프로세스 1개  0,1 -> 0  0
 프로세스 2개  0,1,2 -> 0,1  0,1
 프로세스 3개  0,1,2,3 -> 0,1,2  0,1,2
* 분명 이유가 있다면 11g에서도 1개프로세스를 더 띄우고나서 다시 죽였을터인데.
11g R2에서는 그렇지 않은걸로 봐서는 버그였던것으로 보여진다.

물론 본인은 테스트환경이 linux에 국한되었으나 다른 환경도 별로 다르지 않을것으로 보여진다.
32비트 64비트 상관없이 둘다 그랬던것으로 보아 버그였던것같기도 하다.

흠.... 11g new feature 에서는 못찾았다. ㅡ_ㅡㅋ;;; ( 짧은 영어실력으로 인하여... )
정말 내부적 버그인가...


Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설

오라클 10g 스텐다드버전에서는 Bitmap index 없다~

아래 관련 링크.

http://download.oracle.com/docs/cd/B19306_01/license.102/b14199/editions.htm#CIHBAEID



아래는 비트맵인덱스 사용 할때 쓰는 파라미터.

1. confirm : INITSID.ORA

CREATE_BITMAP_AREA_SIZE=8 ( default 8MB )
BITMAP_MERGE_AREA-SIZE=65536 ( default 1MB )

 

2. instance restart 

init.ora check *

Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설

10g 오라클을 설치해보고 나서 아카이브모드를 활성화 하고나서

오라클 instance 를 띄우면

 

Arc0 , 1 , 2 가 뜬다.

 

총 3개의 프로세스가 뜨는데

대략 10분정도있다가 2번이 죽는다.

 

왜그럴까????? 초보자라 그런가.. 난 여기저기 물어봐도 답은 못찾았다.

현업DBA도 그렇고 강사분도 그렇고.....

 

우선 vmware로 single instance 로 해서

ASM을 사용하여 ( 물론 파일시스템에서도 마찬가지 상황이 발생 )

 

오라클( 10g R2) 을 설치후 .

 

해당 arc2 의 프로세스를 dump를 떠보기로 했다. 뭐 답은 정확하게 안나오겠으나 뭐하고 있는지는 볼수있을테니 말이다.

 

아래는 덤프뜬화면

 

/u01/app/oracle/admin/ORCL/bdump/orcl_arc2_6940.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.2.0
System name:    Linux
Node name:      ora1.oracle.com
Release:        2.6.18-194.11.1.el5
Version:        #1 SMP Tue Aug 10 19:05:06 EDT 2010
Machine:        x86_64
Instance name: ORCL
Redo thread mounted by this instance: 1
Oracle process number: 21
Unix process pid: 6940, image: oracle@ora1.oracle.com (ARC2)

*** 2010-08-22 20:11:16.882
*** SERVICE NAME:(SYS$BACKGROUND) 2010-08-22 20:11:16.882
*** SESSION ID:(151.1) 2010-08-22 20:11:16.882
Received ORADEBUG command 'event 10046 trace name context forever , level 8' from process Unix process pid: 6934, image:
WAIT #0: nam='rdbms ipc message' ela= 16905133 timeout=29928 p2=0 p3=0 obj#=-1 tim=1252417457893546
Received ORADEBUG command 'tracefile_name' from process Unix process pid: 6934, image:
WAIT #0: nam='rdbms ipc message' ela= 7194698 timeout=28197 p2=0 p3=0 obj#=-1 tim=1252417465088309
*** 2010-08-22 20:15:17.509
WAIT #0: nam='rdbms ipc message' ela= 29273322 timeout=2997 p2=0 p3=0 obj#=-1 tim=1252417733301500
WAIT #0: nam='control file sequential read' ela= 9501 file#=0 block#=1 blocks=1 obj#=-1 tim=1252417733311350
WAIT #0: nam='control file sequential read' ela= 83 file#=1 block#=1 blocks=1 obj#=-1 tim=1252417733311450
WAIT #0: nam='control file sequential read' ela= 60 file#=0 block#=16 blocks=1 obj#=-1 tim=1252417733311527
WAIT #0: nam='control file sequential read' ela= 278 file#=0 block#=18 blocks=1 obj#=-1 tim=1252417733311819
WAIT #0: nam='control file sequential read' ela= 78 file#=0 block#=1 blocks=1 obj#=-1 tim=1252417733311999
WAIT #0: nam='control file sequential read' ela= 57 file#=1 block#=1 blocks=1 obj#=-1 tim=1252417733312075
WAIT #0: nam='control file sequential read' ela= 57 file#=0 block#=16 blocks=1 obj#=-1 tim=1252417733312143
WAIT #0: nam='control file sequential read' ela= 233 file#=0 block#=18 blocks=1 obj#=-1 tim=1252417733312390
*** 2010-08-22 20:15:58.911 2520 kcrf.c
tkcrf_clear_srl: Started clearing Standby Redo Logs
WAIT #0: nam='control file sequential read' ela= 81 file#=0 block#=1 blocks=1 obj#=-1 tim=1252417733312586
WAIT #0: nam='control file sequential read' ela= 50 file#=1 block#=1 blocks=1 obj#=-1 tim=1252417733312651
WAIT #0: nam='control file sequential read' ela= 56 file#=0 block#=16 blocks=1 obj#=-1 tim=1252417733312720
WAIT #0: nam='control file sequential read' ela= 201 file#=0 block#=18 blocks=1 obj#=-1 tim=1252417733312934
WAIT #0: nam='control file sequential read' ela= 74 file#=0 block#=21 blocks=1 obj#=-1 tim=1252417733313056
WAIT #0: nam='control file sequential read' ela= 91 file#=0 block#=1 blocks=1 obj#=-1 tim=1252417733313189
WAIT #0: nam='control file sequential read' ela= 49 file#=1 block#=1 blocks=1 obj#=-1 tim=1252417733313251
WAIT #0: nam='control file sequential read' ela= 70 file#=0 block#=16 blocks=1 obj#=-1 tim=1252417733313334
WAIT #0: nam='control file sequential read' ela= 196 file#=0 block#=18 blocks=1 obj#=-1 tim=1252417733313544
WAIT #0: nam='control file sequential read' ela= 4963 file#=0 block#=304 blocks=1 obj#=-1 tim=1252417733318528
WAIT #0: nam='control file parallel write' ela= 1117 files=2 block#=303 requests=2 obj#=-1 tim=1252417733319707
WAIT #0: nam='control file parallel write' ela= 1310 files=2 block#=17 requests=2 obj#=-1 tim=1252417733321040
WAIT #0: nam='control file parallel write' ela= 1687 files=2 block#=15 requests=2 obj#=-1 tim=1252417733322747
WAIT #0: nam='control file parallel write' ela= 1034 files=2 block#=1 requests=2 obj#=-1 tim=1252417733323813
*** 2010-08-22 20:15:58.923 2828 kcrf.c
tkcrf_clear_srl: Completed clearing Standby Redo Logs
*** 2010-08-22 20:17:03.742
WAIT #0: nam='rdbms ipc message' ela= 63299452 timeout=30000 p2=0 p3=0 obj#=-1 tim=1252417796623412
WAIT #0: nam='Log archive I/O' ela= 23 count=4294967295 intr=0 timeout=2147483647 obj#=-1 tim=1252417796623759

주로 발생하는 event 는 뭐 뻔하다.

일반 로그파일이 하는 일만곤 별로 없는듯하다.

 

저 맨마지막에 Log archive I/O가 발생하고나서 해당 프로세스는 대기상태로 돌아가는게 아니라

그냥 그상태로 죽는다. 프로세스상에서 확인해보면 완전죽어있다.

 

딱 기본 컨트롤파일관련 내용만 쓰고 죽는 것 같은데 도대체 왜~~~~~

어째서~~~ 그럴까.

Posted by ORACLE,DBA,BIG,DATA,JAVA 흑풍전설