[oracle_br] Re: Duvida Export/Import
Traz sim : se vc não indicar nada em contrário (como EXCLUDEs, por exemplo) o default para o expdp é incluir DDLs de índices e constraints junto com as tabelas... []s Chiappa OBS : como vc diz que está lidando com LONG RAW, ficam duas dicas : a. se a aplicação e o ambiente Suportam, seria Extremamente Recomendado vc CONVERTER esse cacareco não suportado/depreciado do LONG RAW para BLOB, com a package correspondente : isso não só elimina as limitações de MOVE mas também te dá a chance de acessar os dados binários via API do DBMS_LOB, em PL/SQL b. se for uma qtdade relativamente grande de dados E a opção de converter tá fora, o legal seria usar linguagem C (com pro*C) para melhor performance (export Não É um campeão de velocidade, não), mas TESTE a possibilidade de OU extrair o DDL, criar na mão e depois mover via PL/SQL os dados para a tabela recém-criada na tablespace desejada (exemplo simples na nota metalink "How to Convert from Long Raw to BLOB/CLOB using PL/SQL" (Doc ID 1012454.7), OU manipular via UTL_RAW (exemplo na nota "Using UTL_RAW Package for Manipulating Raw Datatypes" (Doc ID 77327.1)
[oracle_br] Duvida Export/Import
Pessoal, Tenho algumas tabelas que tem campos LONG RAW, irei fazer um trabalho (EXPDP / IMPDP) para mudar essas tabelas de TABLESPACE, minha divida é se no Export os indices vão junto? Apos essas movimentação e recomendado fazer uma coleta de estatísticas do banco? Grato, Ednilson
RE: [oracle_br] Re: Crosscheck
Ah, uma lembrança : não tem direto a ver com a sua pergunta, mas vale a indicação... EU vi que vc está usando RECOVERY WINDOWS de x dias na sua política de incremental , vc Tá Sabendo que isso pode implicar um reter um backup full a mais do que o último, né ?? Considere esse caso-exemplo, com recovery windows de 7 dias : Dia 1 - Incremental level 0 backup Dia 2 - Incremental level 1 backup Dia 3 - Incremental level 1 backup Dia 4 - Incremental level 1 backup Dia 5 - Incremental level 1 backup Dia 6 - Incremental level 1 backup Dia 7 - Incremental level 1 backup Dia 8 - Incremental level 0 backup Dia 9 - Incremental level 1 backup Dia 10 - Incremental level 1 backup Dia 11 - Incremental level 1 backup Dia 12 - Incremental level 1 backup Dia 13 - Incremental level 1 backup Dia 14 - Incremental level 1 backup etc... NO caso acima, digamos que no dia 13 vc precise fazer um recuperação : como o backup full do dia 08 ** não cobre ** os 7 dias , o RMAN ** vai ** precisar do backup full anterior ao dia 08, que no exemplo seria o do dia 1, e de TODOS os incrementais nesse período , então NENHUM deles vai ser marcado como OBSOLETE, e (logicamente) o backup do dia 01 não será deletado ainda na ocasião, yes ??? Facilmente isso pode levar à utilização de espaço (no caso de backups em disco) de forma imprevista, estourando limites, em especial se a área em disco só comporta um backup full/grande
RE: [oracle_br] Re: Crosscheck
Tudo jóia, Francisco ? Então, vc não respondeu o principal questionamento, que era : a operação de passar para fita os backups que estão em disco é feita POR FORA do RMAN, com o Veritas movendo os arquivos em questão pra fita SEM que o RMAN saiba disso, ou não, vc usa algum comando tipo BACKUP BACUPSET para que o RMAN "saiba" que o backupset tal que estava em disco foi pra fita E ** quando ** isso é feito ??? Como eu tinha dito (não sei se ficou Claro) a minha Suposição para explicar o seu cenário é que esse move estava sendo feito por fora do RMAN, que erroneamente continua pensando que os arqs estão em disco como diz o catálogo mas não estão mais, aí o backup incremental level 1 ia ** procurar ** o último level 0, não encontra, aí acaba fazendo um full Tá claro ?? Só vc que pode comprovar ou desprovar isso... Sobre o CROSSCHECK sim, ele é necessário claro, mas a função dele é checar se os backupsets/backups que estão catalogados ainda estão acessíveis ou não E se estão dentro do prazo de retenção indicado : caso ele descubra que algum backup não está mais acessível OU passou da validade/retenção, essa entrada no catálogo é marcada (como EXPIRED, OBSOLETE ou seja qual for o status adequado) , e o próximo comando DELETE EXPIRED (ou seja qual for o DELETE que vc tem no script) é que remove as entradas do catálogo, ok ? Então por isso que frisei que o CROSSCHECK em si ** não move ** coisa alguma (pra fita ou o que for), não ** deleta ** coisa alguma, certo ? Vc não mostra o script mas certamente vc deve ter algum DELETE aí, ou tem algum script que faça DELETE (seja no RMAN, no SO, no veritas, algum)... Friso novamente o outro ponto que indiquei na msg anterior, ie : além da questão de ter sido ou não removido o full anterior que seria o pai do incremental, eu tenho Dúvidas no seu cenário... Pessoalmente já usei em n clientes backups full seguidos de incrementais tanto em disco, ou em fita , e algumas vezes para ambos ao mesmo tempo, mas nunca em mixed-mode, full para um dado detsino e incrementais para outro, como vc diz que faz aí, então Não Sei primeiro se isso é aceito/suportado... ===>> Se for aceito ** E ** vc na ocasião do incremental estar SIM com o último full catalogado E acessível certinho em disco, imho é Sim um BUG o fato do incremental não gerar só as mudanças mas sim um full, como vc relata Vc TEM que checar isso com o Suporte..., Complementando minha msg anterior, eu pensei em dois pontos mais que Podem ou Não estar influenciando nesse cenário de Incremental gerando backupset completo/full : 1. vc não diz (e eu esqueci de perguntar) se vc usa BCT (BLOCK CHANGE TRACKING) para identificar as alterações que tem que ir pro incremental : se sim, a nota metalink "RMAN incremental level 1 backups are not using block change tracking file" (Doc ID 1192652.1) lista uma bem possível causa de incremental não reconhecendo alterações Inclusive, a nota cita qtdade de backups, mas imho também a questão de quantidade de blocos registrados pode pegar, CONFIRA com o Suporte 2. no manual 11gR2 "Database Backup and Recovery User's Guide" no cap. 9 - Backing Up the Database, no item "Incrementally Updated Backups" é dito (referenciando-se a um script de backup incremental) que se não for localizado um level 0, mesmo se o script referenciar DEVICE TYPE sbt, o default é que a primeira execução do level 1 gere em disco a cópia necessária SERÁ que é isso, ou alguma variação disso, que vc está vendo aí ??? verificar com o Suporte, também... []s Chiappa OBS : como vc diz que abriu Chamado mas não teve retorno, na intenção de ajudar vou dar umas dicas de como trabalhar com esse povo do Suporte Oracle Negócio é assim : primeiro é fazer a lição de casa e criar o chamado completo e totalmente mastigado Isso implica em AGREGAR no Chamado os arqs de configuração e controle bem como os scripts TODOS eventualmente envolvidos, o output de um RDA e de um oraChk, os tracefiles/logfiles gerados, E em descrever DIREITINHO, em DETALHES, o cenário... Isto ELIMINA as mensagens de ganhar tempo "ah me passa isso e aquilo" que é a resposta-padrão ... Feito isso, se em 24h vc não recebeu uma resposta, aí vc tem TODO O DIREITO (e mesmo a Obrigação) de ligar no 0800 (eu prefiro o daqui do Brasil, mesmo) e pedir que seja feito o ESCALONAMENTO (Escalation) do chamado : isso não é aumentar a severidade, é simplesmente mudar o nível de atendimento Por mais que meu Inglês seja razoável, EU sempre faço isso no 0800 da Oracle , porque isso fica Registrado por escrito no Chamado : minha experiência é que esse pessoal responde MUITO melhor com coisas escritas ... E ** nunca ** escreva vc mesmo no Chamado que vc quer fazer um Escalonamento ou coisa assim : não sei porque mas a minha Experiência é que vc será SOLENEMENTE IGNORADO se o fizer, é pedir no 0880 que alguém da Oracle faça o processo de escalonamento e
RE: [oracle_br] Re: Crosscheck
Caro Chiappa, bom dia!Peço desculpas duas vezes, primeiro pela demora em responder e a segunda pela falta de clareza.Temos que executar o comando “CROSSCHECK” para fazer uma verificação cruzada dos backup pices com nossas políticas definidas no catálogo. No catalogo, temos definidas algumas políticas de backup do RMAN, como o tempo que manteremos os backups em disco, quantidade de canais utilizados, formatação do nome do arquivo, etc.Segue abaixo alguns tipos de regras definidas no catálogo: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEVICE TYPE DISK PARALLELISM 24 BACKUP TYPE TO BACKUPSET; CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 200 G; CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/zfssa/backup01/p001/bkp_u%u_s%s_p%p_t%t'; ... CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/p001/controlfile/snapcf_p001.f'; O CROSSCHECK só é executado no backup Full, apenas uma vez por semana. Como os backups estão divididos, pode dar a impressão de que todo dia está levando tudo. Temos a opção de não utilizarmos o catalogo, e todas as informações de backup ficam no Controlfile e a ferramenta de backup fica encarregada de apagar os arquivos após os mesmos serem levados para fita.[]'sFrancisco To: oracle_br@yahoogrupos.com.br From: oracle_br@yahoogrupos.com.br Date: Thu, 5 Feb 2015 07:46:34 -0800 Subject: [oracle_br] Re: Crosscheck Opa : então, eu fiquei meio em dúvida quando vc diz "crescentamos o CROSSCHECK no script para que seja levado para fita" : com certeza o CROSSCHECK rigorosamente não serve para levar um conjunto de backup para fita ou o que for, mas sim checar se os backupsets/pieces/whatever que estão catalogados estão acessíveis ou não Outra coisa , vc diz que "passa dos discos ZFS para a fita usando o Net Veritas", como é isso : é MANUAL, por fora do RMAN, simplesmente movendo através do Veritas os arquivos de backup, OU vc usa o BACKUP BACKUPSET para que o RMAN 'transfira' para fita os backupsets em disco Se a idéia é fazer manualmente, é CLARO que o CROSSCHECK ** não vai ** encontrar os backups que estavam em disco e vai portanto marca-los como inválidos - o que se faz nesses casos de movimentação manual para fita, por fora do RMAN, comumente é pedir mesmo pro RMAN dropar do catálogo esses caras e quando preciso vc restaura os arquivos de backup da fita para o disco e aí os RECATALOGA no rman, é isso que vcs pensam em fazer ?? Mostra os SCRIPTs todos (tanto o shell script que aciona o RMAN quanto os scripts/blocos de comandos RMAN em si), que talvez eles possam dar algum insigth... E finalmente, quando vc diz "... backup acontece normalmente todos os dias para o disco mas quando ele e feito de forma incremental para fita..." : eu nunca misturei os dois tipos de backup em dois destinos diferentes (ie, FULL em disco e Incrementais em Fita) como parece ser o seu caso, então não sei se em primeiro lugar isso é aceito pela Oracle, VERIFIQUE Se for possível, provavelmente é um bug : por causa do destino diferente do Full anterior o Incremental não o reconhece aí o RMAN "pensa" que não há FULL e assim automaticamente promove o Incremental para FULL []s Chiappa
