ICT블로그

cast, convert 등의 함수를 쓸 때 분명히 overflow가 발생하지 않을것이라고 예상했는데 발생하는 경우가 있다.

아래의 예를 보자.

select convert(bigint,accounted_debit) from dbo.JE_Sample
where DR_CR = 'CR' and accounted_debit <> 0;

실행시키면 이런 메시지가 뜬다.

Msg 248, Level 16, State 1, Line 63
The conversion of the nvarchar value '2794014278' overflowed an int column.

분명 accounted_debit의 가장 큰 자리수는 14자리라 bigint로 충분히 가능하다,

하지만 왜 이런 현상이 발생할까...?

눈치채셨는지..?

올바른 쿼리는 다음과 같다.

select convert(bigint,accounted_debit) from dbo.JE_Sample
where DR_CR = 'CR' and convert(bigint,accounted_debit) <> 0;

where 절에서 convert함수(명시적 형변환)을 안해줬기 때문에 select 절이 아닌 where절에서 묵시적 형 변환으로 bigint 가 아닌 int로 변환하는 과정에서 overflow가 발생한 것이다!

이것을 깜빡하여 시간을 낭비하는 저 같은 사람이 없기를 바라며 극미세팁을 올린다.... ㅠㅠㅠ

robocopy_help.txt

CMD창

자주쓰는 옵션
robocopy /e /v /np source_directory destination_directory
디렉터리만 지정해도 디렉터리 하위의 모든 파일이 copy되게 됨.

example1) robocopy /e /v /np F:\TEST_EVIDENCE_INS_181122 E:\TEST_EVIDENCE_INST_181122
--> 실시간으로 진행상황이 CMD창에 찍히게 됨.

example2) robocopy /e /v /np /log:E:\TEST\ROBOCOPY_LOGS\TEST_EVIDENCE_INS_181122.txt F:\TEST_EVIDENCE_INS_181122 E:\TEST_EVIDENCE_INST_181122
--> "      /log:      " 옵션 ==> 진행상황이 CMD창에 안 나타나며, 대신 지정한 log파일명에 txt파일로 기록되게 됨.

※robocopy의 속도
디스크 타입(HDD, SSD), 전송방식 등에 따라 달라질수는 있겠지만,
source(HDD_a) --> USB --> destination(HDD_b)의 경우, 30분 동안 50GB가 Copy됨 (예시)

robocopy 옵션

robocopy /? 를 치면 볼수 있다.

-------------------------------------------------------------------------------
   ROBOCOPY     ::     Windows용 견고한 파일 복사                             
-------------------------------------------------------------------------------

  시작됨: 2018년 11월 22일 목요일 오후 3:20:23
             사용법 :: ROBOCOPY 원본 대상 [파일 [파일]...] [옵션]

               원본 :: 원본 디렉터리(드라이브:\경로 또는 \\서버\공유\경로)
               대상 :: 대상 디렉터리(드라이브:\경로 또는 \\서버\공유\경로)
               파일 :: 복사할 파일입니다. 이름/와일드카드: 기본값은 "*.*"입니다.

::
:: 복사 옵션:
::
                 /S :: 비어 있는 디렉터리는 제외하고 하위 디렉터리를 복사합니다.
                 /E :: 비어 있는 디렉터리를 포함하여 하위 디렉터리를 복사합니다.
             /LEV:n :: 원본 디렉터리 트리의 최상위 n개 수준만 복사합니다.

                 /Z :: 다시 시작 모드에서 파일을 복사합니다.
                 /B :: 백업 모드에서 파일을 복사합니다.
                /ZB :: 다시 시작 모드를 사용합니다. 액세스가 거부된 경우 백업
                       모드를 사용합니다.
                 /J :: 버퍼를 사용하지 않은 I/O로 복사합니다(큰 파일에 권장).
            /EFSRAW :: EFS RAW 모드에서 암호화된 모든 파일을 복사합니다.

  /COPY:copyflag[s] :: 파일에 대해 복사할 내용입니다. 기본값은 /COPY:DAT입니다.
                       (copyflags : D=데이터, A=특성, T=타임스탬프).
                       (S=보안=NTFS ACL, O=소유자 정보, U=감사 정보).

 
               /SEC :: 보안된 파일을 복사합니다. /COPY:DATS와 동일합니다.
           /COPYALL :: 모든 파일 정보를 복사합니다. /COPY:DATSOU와 동일합니다.
            /NOCOPY :: 파일 정보를 복사하지 않습니다. /PURGE와 사용하면 좋습니다.
            /SECFIX :: 건너뛴 파일도 포함하여 모든 파일의 파일 보안을 수정합니다.
            /TIMFIX :: 건너뛴 파일도 포함하여 모든 파일의 파일 시간을 수정합니다.

             /PURGE :: 원본에 없는 대상 파일/디렉터리를 삭제합니다.
                /MIR :: 디렉터리 트리를 미러링합니다. /E와 /PURGE를 함께 쓰는 것과 동일합니다.

               /MOV :: 파일을 이동합니다. 복사한 다음 원본에서 삭제합니다.
              /MOVE :: 파일 및 디렉터리를 이동합니다. 복사한 다음 원본에서
                       삭제합니다.

     /A+:[RASHCNET] :: 제공된 특성을 복사된 파일에 추가합니다.
     /A-:[RASHCNET] :: 제공된 특성을 복사된 파일에서 제거합니다.

            /CREATE :: 디렉터리 트리와 길이가 0인 파일만 만듭니다.
               /FAT :: 8.3 FAT 파일 이름만 사용하여 대상 파일을 만듭니다.
               /256 :: 256자를 초과하는 매우 긴 경로에 대한 지원을 사용하지
                       않습니다.

             /MON:n :: 원본을 모니터링합니다. n개 이상의 변경 내용이
                       표시된 경우 다시 실행합니다.
             /MOT:m :: 원본을 모니터링합니다. 변경 내용이 있으면 m분 후에
                       다시 실행합니다.

      /RH:hhmm-hhmm :: 실행 시간 - 새 복사본을 시작할 수 있는 시간입니다.
                /PF :: 통과 기준이 아닌 파일당 기준으로 실행 시간을 확인합니다.

             /IPG:n :: 패킷 간 간격(ms), 저속 회선에서 사용 가능한 대역폭을
                       확보합니다.

                /SL :: 대상에 대한 심볼 링크를 복사합니다.

            /MT[:n] :: n개의 스레드가 있는 다중 스레드를 복사합니다(기본값 8).
                       n은 1 이상 128 이하여야 합니다.
                       이 옵션은 /IPG 및 /EFSRAW 옵션과 호환되지 않습니다.
                       성능을 향상시키려면 /LOG 옵션을 사용하여 출력을 리디렉션하세요.

 /DCOPY:copyflag[s] :: 디렉터리에 대해 복사할 내용(기본값은 /DCOPY:DA).
                       (copyflags : D=데이터, A=특성, T=타임스탬프).

           /NODCOPY :: 디렉터리 정보 복사 안 함(기본적으로 /DCOPY:DA 수행).

         /NOOFFLOAD :: Windows 복사본 오프로드 메커니즘을 사용하지
                       않고 파일을 복사합니다.

::
:: 파일 선택 옵션:
::
                 /A :: 보관 특성 집합이 있는 파일만 복사합니다.
                 /M :: 보관 특성이 있는 파일만 복사하고 보관 특성을 해제합니다.
    /IA:[RASHCNETO] :: 지정된 특성을 가진 파일만 포함합니다.
    /XA:[RASHCNETO] :: 지정된 특성을 가진 파일을 제외합니다.

 /XF file [file]... :: 지정된 이름/경로/와일드카드와 일치하는 파일을 제외합니다.
 /XD dirs [dirs]... :: 지정된 이름/경로와 일치하는 디렉터리를 제외합니다.

                /XC :: 변경된 파일을 제외합니다.
                /XN :: 새 파일을 제외합니다.
                /XO :: 오래된 파일을 제외합니다.
                /XX :: 추가 파일 및 디렉터리를 제외합니다.
                /XL :: 고립된 파일 및 디렉터리를 제외합니다.
                /IS :: 같은 파일을 포함합니다.
                /IT :: 조정된 파일을 포함합니다.

             /MAX:n :: 최대 파일 크기 - n바이트를 초과하는 파일을 제외합니다.
             /MIN:n :: 최소 파일 크기 - n바이트 미만의 파일을 제외합니다.

          /MAXAGE:n :: 최대 파일 사용 기간 - n일/날짜보다 오래된 파일을
                       제외합니다.
          /MINAGE:n :: 최소 파일 사용 기간 - n일/날짜보다 최신 파일을
                       제외합니다.
          /MAXLAD:n :: 최대 마지막 액세스 날짜 - n 이후에 사용되지 않은
                       파일을 제외합니다.
          /MINLAD:n :: 최소 마지막 액세스 날짜 - n 이후에 사용된 파일을
                       제외합니다.
                       n이 1900보다 크면 n은 n일과 같고 그렇지 않으면
                       n은 YYYYMMDD 날짜입니다.

                /XJ :: 연결 지점을 제외합니다. 일반적으로 기본값으로 포함됩니다.

               /FFT :: FAT 파일 시간(2초 단위)을 가정합니다.
               /DST :: 1시간의 DST 시간 차이를 보완합니다.

               /XJD :: 디렉터리의 연결 지점을 제외합니다.
               /XJF :: 파일의 연결 지점을 제외합니다.

::
:: 다시 시도 옵션:
::
               /R:n :: 실패한 복사본에 대한 다시 시도 횟수입니다. 기본값은
                       1백만입니다.
               /W:n :: 다시 시도 간 대기 시간입니다. 기본값은 30초입니다.

               /REG :: /R:n 및 /W:n을 레지스트리에 기본 설정으로 저장합니다.

               /TBD :: 정의할 공유 이름을 기다립니다(다시 시도 오류 67).

::
:: 로깅 옵션:
::
                 /L :: 목록 전용 - 파일을 복사 또는 삭제하거나 타임스탬프를
                       만들지 않습니다.
                 /X :: 선택된 파일을 제외하고 모든 추가 파일을 보고합니다.
                 /V :: 자세한 정보 표시를 출력하고 건너뛴 파일을 표시합니다.
                /TS :: 출력에 원본 파일 타임스탬프를 포함합니다.
                /FP :: 출력에 파일의 전체 경로 이름을 포함합니다.
             /BYTES :: 바이트 크기로 인쇄합니다.

                /NS :: 크기 없음 - 파일 크기를 기록하지 않습니다.
                /NC :: 클래스 없음 - 파일 클래스를 기록하지 않습니다.
               /NFL :: 파일 목록 없음 - 파일 이름을 기록하지 않습니다.
               /NDL :: 디렉터리 목록 없음 - 디렉터리 이름을 기록하지 않습니다.

                /NP :: 진행률 없음 - 복사율(%)을 표시하지 않습니다.
               /ETA :: 복사하는 파일의 예상 도착 시간을 표시합니다.

          /LOG:file :: 상태를 로그 파일에 출력합니다. 기존 로그를 덮어씁니다.
         /LOG+:file :: 상태를 로그 파일에 출력합니다. 기존 로그에 추가합니다.

       /UNILOG:file :: 상태를 유니코드로 로그 파일에 출력합니다. 기존
                       로그를 덮어씁니다.
      /UNILOG+:file :: 상태를 유니코드로 로그 파일에 출력합니다. 기존 로그에
                       추가합니다.

               /TEE :: 로그 파일과 콘솔 창에 출력합니다.

               /NJH :: 작업 헤더가 없습니다.
               /NJS :: 작업 요약이 없습니다.

           /UNICODE :: 상태를 유니코드로 출력합니다.

::
:: 작업 옵션:
::
       /JOB:jobname :: 명명된 작업 파일에서 매개 변수를 가져옵니다.
      /SAVE:jobname :: 명명된 작업 파일에 매개 변수를 저장합니다.
              /QUIT :: 매개 변수를 볼 수 있도록 명령줄을 처리한 후에 끝냅니다.
              /NOSD :: 원본 디렉터리가 지정되어 있지 않습니다.
              /NODD :: 대상 디렉터리가 지정되어 있지 않습니다.
                /IF :: 다음 파일을 포함합니다.

::
:: 설명:
::
       볼륨의 루트 디렉터리에서 /PURGE 또는 /MIR을 사용하면
       요청된 작업이 robocopy에 의해 시스템 볼륨 정보 디렉터리의
       파일에도 적용됩니다. 적용되지 않게 하려면 /XD 스위치를
       사용하여 해당 디렉터리를 건너뛰도록 robocopy에
       명령할 수 있습니다.

추가 (2018-09-14)

ORA-00257은 DB을 Archive log Mode로 운영중일 때 발생할 수 있는 에러입니다. Redo Log에 대한 archiving이 정상적으로 완료되지 않았을 경우, Log switch가 실패하며 DB를 정상적으로 사용할수 없습니다. (sysdba 유저 외 일반 유저는 접속불가)

이때 예상되는 문제로는 다음 2가지가 있습니다.

(1) Archiving 공간이 Full이 됨. (File system 혹은 지정한 ASM diskgroup)

(2) FRA기능을 사용할 때 FRA에 할당된 공간(=db_recovery_file_dest_size 파리미터 값)이 100%가 되어, 더 이상 archive log가 저장될 수 없을 때 발생--> ORA-19809, 19804, 19815 에러와 함께 발생하는 특징

실제 DB운영시에는 (2)번의 경우를 주의해야 하는데요, 왜냐하면 (1)번의 경우 일반적으로 File System에 대한 사용률 모니터링, ASM Diskgroup에 대한 사용률 모니터링을 통해 100% 임계치에 도달하기 전에 장애를 예방할 수 있기 때문입니다.

따라서 해당 에러 발생전 사전에 DB의 FRA기능 사용유무를 파악하고 (db_recovery_file_dest_size<>0 이면 FRA는 ON이 된것입니다.) 아카이브 Full로 인한 장애를 예방하는 것이 중요합니다.

실제 운영중인 DB가 아닐경우, 또는 개인이 학습용도로 사용하는 경우 Archive Log는 DB복구에 사용될 뿐이지 필수 파일이 아니므로, 해당 에러가 발생한다면 임의로 archive log 파일을 삭제해도 무방합니다. 단, 운영계 시스템이라면 해당 archive log가 추후 복구 등에 사용될수 있으므로 (시간적 여유가 된다면) 백업 후 archive log를 삭제하거나, 적어도 여유가되는 다른 File system이나 asm diskgroup에 아카이브 로그 파일을 move하기를 권장드립니다.

그리고 FRA기능을 꼭 써야 하는 경우가 아니라면 db_recovery_file_dest_size=0으로 하는것도 관리포인트를 줄이는 효과가 있습니다.

아래는 저의 학습과정을 기록한 것으로 skip 하셔도 무방합니다.

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

※ 주의! : 저의 지식 한계 내에서 문제를 파악하고 분석한 글로서, 부족하거나 잘못된 내용이 포함될 수 있습니다. 참고만 해주시길 바라며, 지적 및 조언은 언제나 환영합니다.

(1) 로그인 시 ORA-00257에러가 떨어짐 (sqlplus "/as sysdba")

sys user를 제외한 전 유저로 로그인시에도 동일한 현상 발생

(2) ORA-00257 에러를 확인한다. (E17766-03)

** archiving 영역의 공간 부족이 의심된다.

(3) alert log, trace log, 관련 제반 parameter 확인

- alert log 확인

************************************************************************

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_arc1_4720.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 32109056 bytes disk space from 4102029312 limit

ARC1: Error 19809 Creating archive log file to 'F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\ARCHIVELOG\2016_03_14\O1_MF_1_279_%U_.ARC'

Mon Mar 14 23:29:16 2016

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_arc3_4728.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 4102029312 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.

************************************************************************

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_arc3_4728.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 32109056 bytes disk space from 4102029312 limit

ARC3: Error 19809 Creating archive log file to 'F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\ARCHIVELOG\2016_03_14\O1_MF_1_279_%U_.ARC'

==> 정확히 1분 간격으로 해당 error 메시지가 alert.log에 기록됨.

- trace file (archive process) 확인

*** 2016-03-14 23:32:16.882

ORA-19815: WARNING: db_recovery_file_dest_size of 4102029312 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 32109056 bytes disk space from 4102029312 limit

*** 2016-03-14 23:32:17.074 4132 krsh.c

ARC3: Error 19809 Creating archive log file to 'F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\ARCHIVELOG\2016_03_14\O1_MF_1_279_%U_.ARC'

*** 2016-03-14 23:32:17.074 2747 krsi.c

krsi_dst_fail: dest:1 err:19809 force:0 blast:1

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) -----

*** 2016-03-14 23:32:17.084 4529 kcrr.c

==> alert log, trace log의 내용은 대동소이하며, 결국 db_recovery_file_dest_size에서 설정된 한계치 만큼 archive log가 공간을 다 사용했기 때문으로 추정된다.

해결방법은 1. 필요없는 archive file 삭제

            2. db_recovery_file_dest_size 크기 확장 

두가지 정도로 정리된다.

※ no archive log mode로 운영 ==> 이것은 해결방안이 아니다.

-- 설정 변경 적용 전 몇가지 DB 설정사항 확인 및 세부 현상 확인

현재 DB는 archive log mode로 운영되고 있으며, 279번째 리두로그가 archiving 되어야 하나, 현재 archive 저장 영역 (db_recovery_file_dest_size)의 사용량이 100%이기 때문에 archive 되지 못하고 있다. (트레이스 파일 분홍색에서 확인 가능)

v$log의 조회내용이며, 현재 1, 2, 3번 리두 로그 그룹이 공통적으로 아카이빙이 되지 않았음(ARC=NO)을 확인 할 수 있다.

실제 db_recovery_file_dest_size 확인 내용 (3912M=4,102,029,312 bytes)

실제로 flash_recovery_area 영역이 한계치에 다다랐음을 알 수 있다.

주의! 이 부분은 디스크 사용량과는 별개이다.

(3) 문제해결

1. 필요없는 archive file 삭제

가장 오래된 archive log file을 삭제하여, 추가용량을 800M 정도 확보하였다.

system user로 login 시 여전히 같은 에러(ORA-00257)이 발생하는데, DB를 재시작 하면 해결될까?

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_arc3_4728.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 32109056 bytes disk space from 4102029312 limit

ARC3: Error 19809 Creating archive log file to 'F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\ARCHIVELOG\2016_03_15\O1_MF_1_279_%U_.ARC'

Tue Mar 15 00:11:50 2016

Active call for process 15292 user 'SYSTEM' program 'ORACLE.EXE (J002)'

SHUTDOWN: waiting for active calls to complete.

Tue Mar 15 00:12:17 2016

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_arc0_4656.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 4102029312 bytes is 100.00% used, and has 0 remaining bytes available.

shutdown immediate 를 수행한지 20여분이 지났어도 DB가 정상적으로 shutdown 되지 않는다. Ctrl+ C로 작업 중단 후 확인하자, DB가 비정상 종료(중)인걸 알수 있었다. 결국 윈도우 서비스관리(services.msc)를 통해 서비스 중단 및 재시작하였다.

SQL> startup

DB가 OPEN되지 않는다. 어떤 문제일까..

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_arc3_8992.trc:

ORA-19809: limit exceeded for recovery files

ORA-19804: cannot reclaim 33826304 bytes disk space from 4102029312 limit

ARC3: Error 19809 Creating archive log file to 'F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\ARCHIVELOG\2016_03_15\O1_MF_1_280_%U_.ARC'

   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.

************************************************************************

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_ora_16388.trc:

ORA-19809: 복구 파일에 대한 한계를 초과함

ORA-19804: 32109056바이트의 디스크 공간(4102029312 제한)을 재생할 수 없음

ARCH: Error 19809 Creating archive log file to 'F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\ARCHIVELOG\2016_03_15\O1_MF_1_279_%U_.ARC'

Errors in file f:\app\inseong\diag\rdbms\test1\test1\trace\test1_ora_16388.trc:

ORA-16038: 3 로그 279 시퀀스 번호는 기록될 수 없습니다

ORA-19809: 복구 파일에 대한 한계를 초과함

ORA-00312: 온라인 로그 3 스레드 1: 'F:\APP\INSEONG\ORADATA\TEST1\REDO03.LOG'

USER (ospid: 16388): terminating the instance due to error 16038

Instance terminated by USER, pid = 16388

동일한 문제로 보인다. archive log file 중 일부를 삭제했음에도 여전히 저장 공간 오류가 나는것을 이해하기가 어렵다.

해결방법 2. db_recovery_file_dest_size 크기 확장 

다행히 db_recovery_file_dest_size 는 modifiable로, alter system 명령어로 변경가능하다.

database mount 수행 후 파라미터 값 변경 --> database open까지 정상적으로 완료되었다.

※alert log 내용 참조

Instance terminated by USER, pid = 16388 --> shutdown immediate 중 Ctrl+C 로 강제 취소했을때

Tue Mar 15 00:37:50 2016

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on. 

IMODE=BR

ILAT =27

LICENSE_MAX_USERS = 0

SYS auditing is enabled

Starting up:

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

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

Using parameter settings in server-side spfile F:\APP\INSEONG\PRODUCT\11.2.0\DATABASE\SPFILETEST1.ORA

System parameters with non-default values:

  processes                = 150

  memory_target            = 2G

  memory_max_target        = 3G

  control_files            = "F:\APP\INSEONG\ORADATA\TEST1\CONTROL01.CTL"

  control_files            = "F:\APP\INSEONG\FLASH_RECOVERY_AREA\TEST1\CONTROL02.CTL"

  db_block_size            = 8192

  compatible               = "11.2.0.0.0"

  db_recovery_file_dest    = "F:\app\inseong\flash_recovery_area"

  db_recovery_file_dest_size= 3912M  --> 변경이 필요한 parameter 값

  undo_tablespace          = "UNDOTBS1"

  remote_login_passwordfile= "EXCLUSIVE"

  audit_sys_operations     = TRUE

  db_domain                = ""

  dispatchers              = "(PROTOCOL=TCP) (SERVICE=TEST1XDB)"

  local_listener           = "LISTENER_TEST1"

  audit_file_dest          = "F:\APP\INSEONG\ADMIN\TEST1\ADUMP"

  audit_trail              = "XML"

  audit_trail              = "EXTENDED"

  db_name                  = "TEST1"

  open_cursors             = 300

  diagnostic_dest          = "F:\APP\INSEONG"

Tue Mar 15 00:37:51 2016

PMON started with pid=2, OS id=10512 

Tue Mar 15 00:37:51 2016

VKTM started with pid=3, OS id=15484 at elevated priority

VKTM running at (10)millisec precision with DBRM quantum (100)ms

Tue Mar 15 00:37:51 2016

GEN0 started with pid=4, OS id=14140 

Tue Mar 15 00:37:51 2016

DIAG started with pid=5, OS id=14836 

Tue Mar 15 00:37:52 2016

DBRM started with pid=6, OS id=16916 

Tue Mar 15 00:37:52 2016

PSP0 started with pid=7, OS id=12912 

Tue Mar 15 00:37:52 2016

DIA0 started with pid=8, OS id=12248 

Tue Mar 15 00:37:52 2016

MMAN started with pid=9, OS id=11272 

Tue Mar 15 00:37:53 2016

DBW0 started with pid=10, OS id=16336 

Tue Mar 15 00:37:53 2016

LGWR started with pid=11, OS id=17308 

Tue Mar 15 00:37:53 2016

CKPT started with pid=12, OS id=16664 

Tue Mar 15 00:37:53 2016

SMON started with pid=13, OS id=14868 

Tue Mar 15 00:37:53 2016

RECO started with pid=14, OS id=988 

Tue Mar 15 00:37:53 2016

MMON started with pid=15, OS id=16096 

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

starting up 1 shared server(s) ...

ORACLE_BASE from environment = F:\app\inseong

Tue Mar 15 00:37:54 2016

ALTER DATABASE   MOUNT

Tue Mar 15 00:37:54 2016

MMNL started with pid=16, OS id=16424 

Successful mount of redo thread 1, with mount id 1283555746

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: ALTER DATABASE   MOUNT --> MOUNT 완료

Tue Mar 15 00:39:42 2016

ALTER SYSTEM SET db_recovery_file_dest_size='10240M' SCOPE=BOTH; --> 파라미터 값 변경

Tue Mar 15 00:39:42 2016

db_recovery_file_dest_size of 10240 MB is 38.07% 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. 

Tue Mar 15 00:40:53 2016

alter database open

Tue Mar 15 00:40:53 2016

LGWR: STARTING ARCH PROCESSES

Tue Mar 15 00:40:53 2016

ARC0 started with pid=20, OS id=16708 

ARC0: Archival started

LGWR: STARTING ARCH PROCESSES COMPLETE

ARC0: STARTING ARCH PROCESSES

Tue Mar 15 00:40:54 2016

ARC1 started with pid=21, OS id=14076 

Tue Mar 15 00:40:54 2016

ARC2 started with pid=22, OS id=16032 

ARC1: Archival started

ARC2: Archival started

ARC1: Becoming the 'no FAL' ARCH

ARC1: Becoming the 'no SRL' ARCH

ARC2: Becoming the heartbeat ARCH

Archived Log entry 137 added for thread 1 sequence 279 ID 0x4bb0414b dest 1:

Thread 1 advanced to log sequence 282 (thread open)

Thread 1 opened at log sequence 282

  Current log# 3 seq# 282 mem# 0: F:\APP\INSEONG\ORADATA\TEST1\REDO03.LOG

Tue Mar 15 00:40:54 2016

ARC3 started with pid=23, OS id=2980 

Archived Log entry 138 added for thread 1 sequence 280 ID 0x4bb0414b dest 1:

Archived Log entry 139 added for thread 1 sequence 281 ID 0x4bb0414b dest 1:

Successful open of redo thread 1

ARC3: Archival started

ARC0: STARTING ARCH PROCESSES COMPLETE

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

Tue Mar 15 00:40:57 2016

SMON: enabling cache recovery

Successfully onlined Undo Tablespace 2.

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

SMON: enabling tx recovery

Database Characterset is KO16MSWIN949

No Resource Manager plan active

SMON: Parallel transaction recovery tried

replication_dependency_tracking turned off (no async multimaster replication found)

Starting background process QMNC

Tue Mar 15 00:40:57 2016

QMNC started with pid=32, OS id=11476 

Completed: alter database open

Tue Mar 15 00:40:58 2016

Starting background process CJQ0

Tue Mar 15 00:40:58 2016

CJQ0 started with pid=34, OS id=15816 

Setting Resource Manager plan SCHEDULER[0x3003]:DEFAULT_MAINTENANCE_PLAN via scheduler window

Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter

Tue Mar 15 00:41:01 2016

Starting background process VKRM

Tue Mar 15 00:41:01 2016

VKRM started with pid=33, OS id=15316 

Tue Mar 15 00:50:58 2016

Starting background process SMCO

Tue Mar 15 00:50:58 2016

SMCO started with pid=24, OS id=10976 

279~281 sequence#에 해당하는 online redo group들이 모두 archiving 완료되었고, current redo group은 group3, sequence#는 282이다.

archiving이 정상적으로 완료되었음을 파일 시스템 영역에서도 확인할수 있다.

또한 아까 문제상황에서는 수행되지 못했던 'alter system switch logfile;' 구문도 정상적으로 수행됨을 확인 할 수 있었다.

덤으로 체크 포인트까지(참고로 체크포인트는 문제상황에서도 작동되었다.) -->

※ 정리

1. db_recovery_file_dest_size 파라미터에서 설정한 값 이상으로 recovery-related files 파일(특히 아카이브)이 쌓였을때 ORA-00257에러가 발생할 수 있으며, 이 때는 sys를 제외한 일반 유저의 접근이 불가능하다.

2. db_recovery_file_dest_size 파라미터 크기를 늘려줌으로써 DB를 다시 정상적으로 운영가능하다.

3. ORA-00257과 같은 상황이 발생하지 않도록, 평소 백업영역 관리에 신경을 써야 한다.

(archiving 삭제 스케쥴러 지정 등)

더 생각해 볼만한 문제

(1) 아카이브 파일을 삭제했으나, 그 내용이 DB로 바로 전달되는 것 같지는 않다... 반영되기 까지 delay가 있는 것인가?

--> 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.

==> 문제 확인: RMAN DELETE command를 사용하지 않았기 때문에 문제가 발생했을 것 같다.

(2) archive dest를 지정할 때, 여러 군데를 지정해서 운영가능한 것으로 알고 있다. 이 경우 해당 문제는 발생하지 않는가?