12 Replies Latest reply: Sep 27, 2006 11:52 PM by 138107 RSS

    RMAN 백업을 실패했습니다...이제 어떻게 해야 될지요...

    531295
      RMAN 백업을 실패했습니다...이제 어떻게 해야 될지요...

      이전 부터 계속적으로 백업에 대해 질문 하였는데

      오늘 다시 한번 RMAN 백업을 하였으나 백업에 실패하였습니다.

      에러메세지는 RMAN 메세지의 일부 내용입니다.

      channel ORA_DISK_1: sid=2682 devtype=DISK
      channel ORA_DISK_1: starting full datafile backupset
      channel ORA_DISK_1: specifying datafile(s) in backupset
      input datafile fno=00005 name=/opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbf
      input datafile fno=00010 name=/opt/oracle/oraidx/NETVDB43/NCBBS_IX.dbf
      input datafile fno=00011 name=/opt/oracle/oradata/NETVDB43/NCCAFE_DATA02.dbf
      channel ORA_DISK_1: starting piece 1 at 25-SEP-06
      RMAN-03009: failure of backup command on ORA_DISK_1 channel at 09/25/2006 10:21:48
      ORA-19566: exceeded limit of 0 corrupt blocks for file /opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbfcontinuing other job steps, job failed will not be re-run
      channel ORA_DISK_1: starting full datafile backupset
      channel ORA_DISK_1: specifying datafile(s) in backupset

      이전에도 RMAN 으로 해보고 다시 CP명령어로도 해봤는데

      오늘 해보니 다음과 같은 메세지가 나왔습니다.

      위의 메세지 중 망가진 블럭의 갯수가 0이라는것 같은데..

      이제 어떻게 해야 될까요?

      새로운 테이블 스페이스를 만들어서 데이터를 모두 옮겨야 하나요?(move 명령어)

      아니면...import/export를 열심히 해야 할까요..

      아주 앞이 깜깜합니다.

      글 수정:
      nicekijun
        • 1. Re: RMAN 백업을 실패했습니다...이제 어떻게 해야 될지요...
          531295
          구글에서 검색해보니 alert.log 를 확인하라고 해서 확인을 해보았습니다.

          Hex dump of (file 5, block 276) in trace file /opt/oracle/admin/NETVDB43/udump/netvdb43_ora_9963.trc
          Corrupt block relative dba: 0x01400114 (file 5, block 276)
          Fractured block found during backing up datafile
          Data in bad block:
          type: 6 format: 2 rdba: 0x01400114
          last change scn: 0x0000.0032ccaf seq: 0x1 flg: 0x06
          spare1: 0x0 spare2: 0x0 spare3: 0x0
          consistency value in tail: 0x00140080
          check value in block header: 0xb161
          computed block checksum: 0x1c91
          Reread of blocknum=276, file=/opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbf. found same corrupt data
          Reread of blocknum=276, file=/opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbf. found same corrupt data
          Reread of blocknum=276, file=/opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbf. found same corrupt data
          Reread of blocknum=276, file=/opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbf. found same corrupt data


          이런 메세지가 나오네요

          모든 테이블에서 select * 를 해보라는데

          블럭 정보만 가지고 테이블을 찾을수는 없을까요?
          • 2. Re: RMAN 백업을 실패했습니다...이제 어떻게 해야 될지요...
            29384
            file_id가 5이고 block_id가 276이니깐

            Select segment_name,segment_type,owner
            from sys.dba_extents
            where file_id = 5 and 276 between block_id and block_id + blocks -1 ;
            하면 segment관련 정보를 알 수 있을겁니다.
            index면 drop하고 다시 생성하면 되구요..

            만일 table이면 corruption 난 블록만 빼고 export 받아서 다시 import 해야합니다.
            그런데 metalink를 보니깐 심한 I/O 중에 RMAN 백업을 하면 같은 현상이 발생한다고 되어 있네요..
            혹시 table이라면 select * from t_name해서 에러가 나는지 확인 해 보세요.. 에러가 발생 하지 않는다면 가중한 I/O로 인한 현상으로 볼 수 있습니다.

            문서번호는 99933.1입니다.
            • 3. Re: RMAN 백업을 실패했습니다...이제 어떻게 해야 될지요...
              531295
              답변 감사합니다.

              해당 쿼리를 실행햐 봤는데

              결과가 없네요..

              1 select segment_name,segment_type , owner
              2 from dba_extents
              3* where file_id =5 and 276 between block_id and block_id+blocks -1
              SQL> /

              no rows selected

              그렇다면 그 순간에만 I/O가 많아서 그런것인가요?

              현재 토드로 모든 데이터 테이블에 대해

              select * from 하고 있어 조금더 확인은 해봐야 하겠지만요...
              • 4. Re: RMAN 백업을 실패했습니다...이제 어떻게 해야 될지요...
                29384
                제 생각에는 trace나 현상이 문서에 나와 있는 것과 거의 흡사하기 때문에 진짜 corrution은 아니라고 봅니다.

                그리고 toad를 사용하신다고 하셨는데 부분 fetch를 하기 때문에 select * from table_name을 하셔도 fetch 안된 부분은 정상인지 비정상인지 알 수 없습니다.

                select /*+ full(table_name) */ count(*) from table_name 으로 하시는게 좋습니다.

                글 수정:
                jaehpark
                • 5. Re: exp/imp로 복구해보시죠..
                  531427
                  우선.. 저번에 해당파일이 복사가 안된다고 하지 않으셨나요?
                  /opt/oracle/oradata/NETVDB43/NCCAFE_DATA.dbf
                  이거 전체가 복사가 안되는 건지요?
                  그런데 블록을 조회했더니 아무것도 안나오는 건가요?
                  그렇다면.. 데이터가 있는 블록이 아니라 데이터가 없는 블록이
                  깨진 것 같습니다. 다행이네요..

                  테이블스페이스만 export해서 다시 생성하고 넣을 수도 있습니다.

                  우선 cp가 안된다고 하셨으니.. DB를 내리고
                  새로운 디스크를 붙이고 ufsdump같은 것으로
                  디스크 복사를 합니다. cp가 안되어도 ufsdump로는 백업이 되거든요..
                  이제 디스크 교체를 하고 DB를 띄웁니다.

                  아래를 통해서 테이블스페이스에 어떤 object가 있는지 확인합니다.
                  ## tbs_seg.sql
                  col owner format a10
                  col segment_name format a20
                  col tablespace_name format a30

                  select owner, segment_name, segment_type, trunc(next_extent/1024/1024) next_mega,
                  EXTENTS, MAX_EXTENTS, trunc(bytes/1024/1024) size_mega, tablespace_name from dba_segments
                  where tablespace_name=upper('&tablespace_name') order by 1,3,2
                  /

                  그리고 나서 해당 테이블스페이스를 export합니다.

                  PROD@/u/ora9i/product/9.2.0/tune/DUMP $exp system/manager tablespaces=users file=users.dmp log=users.log direct=y

                  Export: Release 9.2.0.7.0 - Production on Mon Sep 25 23:52:49 2006

                  Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


                  Connected to: Oracle9i Enterprise Edition Release 9.2.0.7.0 - Production
                  With the Partitioning, OLAP and Oracle Data Mining options
                  JServer Release 9.2.0.7.0 - Production
                  Export done in KO16KSC5601 character set and AL16UTF16 NCHAR character set

                  About to export selected tablespaces ...
                  For tablespace USERS ...
                  . exporting cluster definitions
                  . exporting table definitions
                  . . exporting table BONUS 0 rows exported
                  . . exporting table DEPT 4 rows exported
                  . . exporting table DUMMY 1 rows exported
                  . . exporting table EMP 14 rows exported
                  . . exporting table SALGRADE 5 rows exported
                  . exporting referential integrity constraints
                  . exporting triggers
                  Export terminated successfully without warnings.

                  이제.. 테이블스페이스를 drop하고 다시 만든 후에 import를 수행합니다.
                  디스크를 ufsdump로 백업하게 되면 block이 깨진 것의 데이터는
                  깨져서 dump를 뜬 것이니 이제는 drop후 재생성해주기만 하면
                  문제없습니다.

                  exp/imp시
                  단 NLS_LANG과 select * from sys.props$;의 character set이 같아야 합니다.
                  다르면 한글이 깨져요..;;

                  만약..export하면서 에러가 나고, 데이터가 들어간 block이 깨진 것이라면 말씀 주십시오..

                  그럴 경우에는 block corruption에 대한 조치를 해야지요..
                  restore가 된다면 백업을 restore하고 복구할 수도 있으나 restore가 되지
                  않는다면 block corruption을 처리하기 위한 event를 넣거나
                  dbms_repair 패키지를 이용해서 데이터 skip을 할 수 있습니다.

                  글 수정:
                  민천사 (민연홍)

                  경험상.. 디스크의 블록이 깨졌을 경우에 cp 명령이 안되더군요.
                  저는 ufsdump로 백업하고 확인결과 인덱스라서 지우고 다시
                  만들었던 적이 있습니다.
                  물론 physical한 상황이 아닌 논리적인 block corruption도 처리한 적이 있어서.. block corruption이라면 조금 도움드릴 수 있을 것 같습니다.
                  • 6. Re: exp/imp로 복구해보시죠..
                    531295
                    답변 감사합니다^^

                    팀장님한테 I/O 과다로 인해 발생할수 있다고 했다가 혼났습니다^^

                    맨날 놀구 있는 데이터 베이스이거든요~

                    그럼 어떻게든 알려주신 방법을 또 연구해봐야 겠네요

                    이제 점점 끝이 보이는듯 하네요 ㅋㅋ~

                    글 수정:
                    nicekijun
                    • 7. Re: exp/imp로 복구해보시죠..
                      29384
                      ㅎㅎ 히스토리를 다 보지 못해서 오버를 한 것 같네요.. 파문을 일으켜서 죄송합니다~~
                      참고로 RMAN Backup의 경우 과다한 업무가 아님도 불구하고 Backup 자체가 문제를 일으키는 경우가 있습니다. 무자비한 I/O를 보이면서 문제를 일으킵니다.(OS 문제다라고 잡아 떼다가 몰래 해결했습니다.)
                      10g에서는 RMAN Backp 시 resource 사용에 대한 제한을 할 수 있도록 해 놓았는데 이럴 때 유용하겠습니다.

                      글 수정:
                      jaehpark
                      • 8. Re: exp/imp로 복구해보시죠..
                        531295
                        답변감사합니다^^

                        이전에도 비슷한 질문을 해서 김재연씨에게 비슷한 답변을 받은 적이 있습니다.

                        현재 rman 을 사용할때는

                        sys 계정으로 컨트롤 파일을 이용합니다^^

                        resource manager 라는것이 sys , system 에 대해서는 항상 디폴트 100%

                        cpu%를 점유하지 않나요?

                        resource manager 를 사용하기 위해 새로 백업 유저를 만든다면

                        카탈로그 디비를 꼭 만들어야 하는거는 아닌지요?^^ 아닌가?

                        글 수정:
                        nicekijun
                        • 9. Re: exp/imp로 복구해보시죠..
                          29384
                          RMAN BACKUP 문제는 I/O issue이고 resource manager에서는 핸들링 할 수 없기 때문에 사용할 필요가 없습니다.(음... resource manager가 RMAN BACKUP 시 사용가능하지도 않을 것 같습니다.)

                          그리고 history리를 보니 물리적인 corruption 인 것 같은데요.. Export 받고나서 Tablespace 삭제하고 Import 하는게 가장 좋은 방법일 것같습니다. 삭제 후에 fsck를 한번 돌려 보는 것도 좋겠네요...
                          • 10. Re: exp/imp로 복구해보시죠..
                            531295
                            답변 감사합니다 ^^

                            리소스 매니져가 아니었군요~

                            그러면 rman 백업중에 resource(I/O) 에 제한을 둔다는 것이 무슨 말인지요?

                            rman 백업이 server-managed 방식이라 서버 프로세스를 사용하기에

                            resource manager 를 사용한하는 방법도 타당하다고 생각했는데

                            rman에서 어떤 파라메터를 확인해야 하나요?

                            현재 모든 디스크가 하나의 RAID로 묶여 있어... I/O를 줄이는것 가장 해보고 싶은

                            방법이기는 합니다~
                            • 11. Re: exp/imp로 복구해보시죠..
                              29384
                              10g를 사용하시나요? 정확하게 어디서 봤는지 기억이 없어서 메뉴얼에서 캡쳐 했씁니다.(이걸 보니 메뉴얼을 한번 봐야겠다는 생각이 드네요...) 구문에 나와 있듯이 RMAN은 i/o 대역을 전부 사용하기 때문에 I/O issue가 있습니다. 그래서 제한을 가하게 된거죠..

                              http://download-west.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconc1004.htm#sthref201

                              By default, RMAN uses all available I/O bandwidth to read/write to disk. You can limit the I/O resources consumed by a backup job with the RATE option of the ALLOCATE CHANNEL or CONFIGURE CHANNEL commands. The RATE option specifies the maximum number of bytes for each second that RMAN reads on the channel.

                              For example, you can configure automatic channels to limit each channel to read 1 MB a second:

                              CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
                              CONFIGURE DEFAULT DEVICE TYPE TO sbt;
                              CONFIGURE CHANNEL DEVICE TYPE sbt RATE 1M;

                              In effect, the RATE option throttles RMAN so that a backup job does not consume excessive I/O bandwidth on the computer.

                              글 수정:
                              jaehpark
                              • 12. Re: exp/imp로 복구해보시죠..
                                138107
                                답변 감사합니다 ^^

                                리소스 매니져가 아니었군요~

                                그러면 rman 백업중에 resource(I/O) 에 제한을 둔다는 것이 무슨 말인지요?

                                rman 백업이 server-managed 방식이라 서버 프로세스를 사용하기에

                                resource manager 를 사용한하는 방법도 타당하다고 생각했는데

                                rman에서 어떤 파라메터를 확인해야 하나요?

                                현재 모든 디스크가 하나의 RAID로 묶여 있어... I/O를 줄이는것 가장 해보고 싶은

                                방법이기는 합니다~
                                10g Enterprise 버전을 사용중이라면 Change Tracking File 을 사용할 수 있습니다.

                                이전 버전에서는 RMAN 으로 incremental backup 을 하기 위해서

                                마지막 incremental backup 이후에 변경된 block 을 찾기 위해서

                                모든 데이터 파일들을 읽어야만 합니다.

                                가령, 1TB 의 database 에 500MB 의 데이터를 추가했다고 하면,

                                백업하기 위한 500MB 의 정보를 찾기 위해서 1TB 의 데이터를 읽어야만 했습니다.

                                10g Enterprise 버전에서부터 사용이 가능한

                                Change Tracking File 의 목적은

                                마지막 incremental backup 이후로 어떤 blocks 이 변경되었는지 추적하기 위한겁니다.

                                그래서, RMAN은 전체 데이터베이스를 읽지 않고, 실제로 변경된 blocks 을 읽고 backup 할 수 있습니다.

                                당연히 I/O 와 백업시간을 줄일 수 있겠죠...^^

                                alter database문을 이용해서 block change tracking 기능을 enable, disable 할 수 있습니다.

                                아래는 block change tracking 기능을 enable, disable 하는 SQL 구문입니다.


                                ----------------------------------------------------------------------------------------------------------------------
                                Block Change Tracking Enable

                                SQL> alter database enable block change tracking
                                using file
                                '경로/changed_blocks.bct';

                                Block Change Tracking Disable
                                SQL> alter database disable block change tracking;

                                주의하실 건 disable 시키면 단지 기능만 disable 되는 것이 아니라
                                enable 시키면서 생성시켰던 changed_blocks.bct 파일도 삭제됩니다.

                                또 한가지 당부하고 싶은 말은
                                이런 기능들을 포함해서 데이터베이스에 변경을 가하는 New Feature 들은 바로 운영 장비에 적용하지 마시고,
                                개발장비나 테스트 장비에서 검증을 거친 후에 운영장비에 적용하시길 바랍니다.

                                글 수정:
                                minsu74 (김민수)