Pular para o conteúdo
  • This topic has 3 replies, 2 voices, and was last updated 8 years, 5 months ago by Avatar photoJosé Laurindo Chiappa.
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #108195
    Avatar de guilhermeguilherme
    Participant

      Pessoal,
      Estou com um problema, acredito que considerado fácil, porém não tinha passado por esta situação.
      Vamos lá… Percebi que alguém, muito antigamente, excluiu um datafile (“inútil”) via S.O. Para essa base, não havia backup, então não consegui restaurar o datafile. Precisei realizar backup da mesma, pois será feita transferência de servidor. Consultei a tabela dba_data_files e percebi que estava com status de RECOVER. Realizei o backup (rman) com a clausula SKIP OFFLINE, ou seja, o backup do datafile não foi feito… Agora preciso restaurar a base, como faço pra ignorar o datafile não “backupeado”?
      O que devo fazer nesta situação?

      Abs

      #108196
      Avatar photoJosé Laurindo Chiappa
      Moderator

        Opa : então, todo datafile ** PERTENCE ** a uma tablespace, e uma tablespace é composta por 1 ou por N datafiles, no conjunto – perdeu um dos datafiles, a tablespace todinha fica comprometida em princípio…. LOGICAMENTE, se a tablespace continha índices (que podem ser em tese reconstruídos a qualquer momento), ou coisa assim, ninguém pensa duas vezes, simplesmente se DROPA a tablespace , recria e recria-se os indices em questão…
        Sendo tablespace de DADOS, que continha/contém TABELAS : o mais fácil, creio que é simplesmente IDENTIFICAR a qual tablespace o datafile perdido pertence e pedir no RESTORE a opção SKIP nomedatablespace – veja no manual de Backup & Restore a sintaxe exata do comando… Depois vc remove a referência lógica da tablespace na catálogo / controlfile do banco restaurado via DROP TABLESPACE. Outra opção, mais complexa, é vc Remover a chamada para o datafile perdido de dentro do controlfile, recriando-o sem essa linha : a nota do Suporte Oracle “How to Recreate a Controlfile” (Doc ID 735106.1) é ref…

        OPCIONALMENTE, porém, o que vc talvez possa querer fazer antes disso (e isso SE a tablespace que teve esse datafile perdido era composta de outros datafiles mais, E SE os dados gravados nessa tiverem alguma importância – não parece ser o caso, mas enfim) é tentar EXTRAIR o máximo desses dados : nesse cenário, alguns registros de algumas tabelas dessa tablespace que fisicamente estavam gravadas no datafile perdido tão inacessíveis, mas os outros registros tão acessíveis, vc faria acesso via ROWID lendo apenas os ROWIDs que apontam pros datafiles que vc ainda tem e gravaria numa tabela de salva, que vc criaria em outra tablespace : vide na documentação a package DBMS_ROWID para refs… A vantagem disto, além de minimizar a perda de dados INESCAPÁVEL que vc vai ter aí depois de perder datafile e não ter backup, é que uma vez salvos em outra tabela os dados vc já pode mandar um DROP TABLESPACE (provavelmente com a cláusula INCLUDING) , Removendo a tablespace manca, antes de fazer o backup, que aí (obviamente) não vai mais tentar backupear o datafile perdido, dropada a tablespace que o usava…

        E é claro, nem preciso dizer que se alguém fez caquinha em procedimento de backup e andou excluindo o que não devia, vc TEM que corrigir isso o quanto antes… BACKUP e RESTORE é a alma da administração de banco de dados, ambiente que não tem ao menos isso bem-feito não serve de muito…

        []s

        Chiappa

        #108197
        Avatar de guilhermeguilherme
        Participant

          @Chiappa
          Então, infelizmente o datafile pertencia a uma tablespace de DADOS. Essa tablespace contém diversos outros datafiles (cerca de 10). Acredito eu, que possivelmente o datafile foi criado na tablespace errada, e o “adm” da época excluiu o mesmo via S.O. Por ser uma base de testes, não era feito backup da mesma…
          Acredito que a melhor alternativa seria fazer o restore ignorando a tablespace que possui o datafile excluido e entao realizar EXPDP dos dados desta tablespace, recriando seus datafiles de forma “manual”…. Não achas?

          Obrigado
          []s

          #108198
          Avatar photoJosé Laurindo Chiappa
          Moderator

            Então : como eu disse, se vc excluir a tablespace Obviamente *** TODOS *** os dados de ** TODAS ** as tabelas que estavam contidas nessa tablespace vão pro beleléu… Assim sendo, SE esses dados tem importância pro negócio (muitas vezes, mesmo sendo um banco “teste”, neguim enfia dados bons/importantes nele), E SE esse banco ainda está de pé mesmo com essa tablespace manca/faltando parte dela, o que vc pode fazer antes é escrever uma rotina que acesse os dados que estão gravados nos ** OUTROS ** 9 datafiles dessa tablespace e os grave em outro lugar/outra tablespace…. Para se fazer isso, basicamente vc vai ter que acessar cada linha de cada tabela que reside nessa tablespace manca e acessar linha-a-linha com dbms_rowid.rowid_create(file#,block,row) Excluindo o file# referente ao arquivo perdido – as refs que te indiquei dão dicas a respeito, e http://kerryosborne.oracle-guy.com/2009/02/saving-rows-from-corrupt-blocks/ tem um exemplo adaptável..

            ===> EVIDENTEMENTE, se os dados não Justificam esse trabalho, aí é mesmo excluir a tablespace, e isso TANTO pode ser feito simplesmente via DROP, como eu disse, Quanto pode ser feito um restore de um backup que não contém a tablespace manca, sim….

            []s

            Chiappa

          Viewing 4 posts - 1 through 4 (of 4 total)
          • You must be logged in to reply to this topic.
          plugins premium WordPress