Diagnosticando Distorção ao Utilizar o IBM DB2

Entender e solucionar problemas

Saiba como identificar e classificar os problemas de distorção mais comuns ao usar o IBM DB2®. Neste artigo, aprenda sobre técnicas corretivas e preventivas que é possível implementar para combater problemas de distorção.

Amitkumar Bamane, Software Engineer, IBM

Amitkumar BamaneAmitkumar Bamane é IBM Certified Advanced Technical Expert para DB2. Ele trabalha como analista de suporte técnico avançado do DB2 no IBM India Software Lab, Pune, onde sua prioridade é auxiliar os clientes do IBM DB2 no mundo todo.



06/Set/2012

Introdução

Talvez considerado um dos problemas de negócios mais difíceis, a distorção do banco de dados geralmente ocorre de forma discreta e prejudica as empresas. Em palavras simples, distorção pode ser definida como qualquer entrada não intencional no banco de dados. Problemas de distorção podem resultar em uma grave queda do sistema. Em alguns casos, pode resultar em travamentos frequentes do sistema e pode se tornar uma situação de tempo de inatividade crítica ao negócio. Distorção do banco de dados pode ocorrer em qualquer camada, desde o DB2 até o sistema operacional e completamente na camada de hardware. Portanto, é importante entender e solucionar problemas envolvendo todas as camadas afetadas possíveis e coletando os dados diagnósticos que possam ser necessários assim que possível, enquanto os dados estiverem disponíveis.

Neste artigo, você entenderá porque um banco de dados pode ficar offline quando encontrar uma distorção. Você também aprenderá a analisar sintomas de distorção e diferenciar entre falhas fáceis de corrigir e catastróficas. Este artigo explicará sobre problemas de distorção ao utilizar o IBM DB2 e ajudar os usuários do DB2 a entender e escolher a melhor abordagem ao lidar com tais problemas críticos e de alto impacto.

Este artigo começa com a discussão sobre possíveis fontes de distorção. Depois, explica as seguintes tarefas:

  1. Identificando e solucionando problemas de distorção — Identifique e categorize a distorção no banco de dados ao usar o DB2, com a ajuda de mensagens de sintoma de amostra que aparecem em db2diag.log. Problemas de distorção podem ser amplamente classificados em cinco categorias: distorção de página de dados (ou distorção de tabela), distorção de índice, distorção CBIT, distorção de log e distorção do descritor compactado.
  2. Usando db2dart e INSPECT para identificar distorção — Obtenha um insight sobre os comandos úteis do DB2 db2dart e INSPECT para verificar a distorção do banco de dados.
  3. Abordagens para recuperar de distorção — Quando um problema de distorção é identificado, como abordar esses casos, quais dados coletar e como se recuperar da situação é essencial. Conheça possíveis abordagens de recuperação e como escolher entre as opções disponíveis.
  4. Estratégias preventivas para evitar possível distorção — Melhores práticas são discutidas.

Origens

A distorção do banco de dados pode ocorrer durante a gravação, leitura, armazenamento, transmissão ou processamento, que introduzem mudanças não desejadas nos dados originais. Alguns dos motivos comuns para distorção:

  1. Sistema de arquivos corrompido é um dos motivos mais comuns de distorção em um banco de dados. Encerramentos repentinos do sistema, picos de energia, montagem dupla do sistema de arquivos, migração de discos, atividades no nível do sistema de arquivos, como verificar e reparar o sistema de arquivos (usando utilitários como fsck no Linux®) quando o banco de dados está ativo e em execução e usar Ctrl+Alt+Delete enquanto um arquivo está aberto, vírus: tudo isso pode introduzir mudanças não desejadas no banco de dados.
  2. Falha de hardware.
  3. Distorção da memória.
  4. Defeito do DB2.
  5. Problemas de E/S e de rede (problemas no adaptador de fibra, comutadores, etc.).
  6. Codificação incorreta do aplicativo.
  7. Inconsistência no valor da página no buffer pool (sqldpage) e o armazenado no sistema de arquivos.
  8. A sobrescrição de dados do disco causa distorção.
  9. Interferência do usuário em arquivos de configuração do banco de dados críticos, arquivos de log, arquivos de controle de log, etc., pode colocar o banco de dados em estado inconsistente

Tendo dito isso, a distorção pode ser devida a vários motivos; o desafio é descobrir exatamente o que causou a distorção de dados. Na maioria dos casos, ela é causada por problemas no sistema de arquivos e problemas de hardware.


Identificar e solucionar problemas

Para um DBMS, página é a menor unidade de dados para alocação de memória executada pelo sistema operacional de um programa e transferência entre a memória principal e qualquer outro armazenamento auxiliar, tal como uma unidade de disco rígido. Assim, ao dizer que algo em um banco de dados está corrompido, você realmente quer dizer que algumas páginas em um banco de dados estão corrompidas.

Pânico é um método que o DB2 utiliza para fazer com que ele mesmo trave se houver uma condição de erro que não consiga lidar normalmente. Quando uma distorção de página é detectada pelo DB2, ele para todo o processamento por meio de um travamento controlado (pânico), pois não consegue determinar a integridade de banco de dados. Isto também serve para evitar mais danos ou perda de dados.

Diversas mensagens de erro são despejadas em db2diag.log quando o DB2 encontra distorção em um banco de dados. Quando uma indisponibilidade ocorre e a primeira captura automática de dados da ocorrência (FODC, First Occurrence Data Capture) está ativada, os dados são coletados com base em sintomas. Os dados da FODC serão coletados automaticamente no DB2 9.5 quando uma das condições a seguir for atendida:

  1. FOCD_Trap quando ocorrer um trap em toda a instância.
  2. FODC_Panic quando um mecanismo do DB2 detectar uma incoerência e decidir não continuar.
  3. FODC_BadPage quando uma página inválida foi detectada.
  4. FODC_DBMarkedBad quando um banco de dados foi marcado como inválido devido a um erro.

É fundamental envolver o suporte de SO e de hardware a fim de reunir as informações necessárias, como diagnósticos do SO (por exemplo, as saídas errpt –a, snap e fileplace no AIX®), além de todo e qualquer diagnóstico de hardware (gravações de estado, logs de erro, etc.). É importante assegurar que exista espaço em disco adequado para sistemas de arquivos críticos, como espaço para dump e diretórios de log, para assegurar que os eventos críticos sejam inteiramente capturados.

Vendo db2diag.log, é possível confirmar se o pânico é devido à distorção ou a outro motivo. Abaixo, você verá como identificar e categorizar a distorção no DB2. A seguir, há algumas das mensagens de erro db2diag.log mais comuns que identificam a distorção.

Distorção da página de dados

Distorção da página de dados indica distorção de dados reais em uma tabela. Diversas mensagens são registradas no db2diag.log quando a distorção de dados é detectada. Essas mensagens são necessárias para identificar o objeto afetado. A Listagem 1 mostra uma mensagem de erro de amostra em db2diag.log.

Lista 1. Mensagem de erro de amostra para distorção da página de dados
2012-02-04-03.13.05.261082-360 I3442A358          LEVEL: Error 
PID     : 393470               TID  : 1           PROC : db2pfchr 0 
INSTANCE: inst1                NODE : 000 
FUNCTION: DB2 UDB, buffer pool services, sqlbReadAndReleaseBuffers, 
probe:13 
RETCODE : ZRC=0x86020001=-2046689279=SQLB_BADP "page is bad" 
DIA8400C A bad page was encountered. 
. 
. 
. 
2012-02-04-03.13.05.264301-360 I3801A437          LEVEL: Error 
PID     : 393470               TID  : 1           PROC : db2pfchr 0 
INSTANCE: inst1                NODE : 000 
FUNCTION: DB2 UDB, buffer pool services, sqlbReadAndReleaseBuffers, 
probe:13 
DATA #1 : String, 158 bytes 
Obj={pool:9;obj:20;type:0} State=x27 Parent={9;20}, EM=1120, PP0=1152 
Page=51235 Cont=17 Offset=2848 BlkSize=15 
sqlbReadAndReleaseBuffers error: num-pages=16

Como indicam as mensagens de erro acima, o DB2 encontrou uma página inválida para o ID do espaço de tabela 9 e ID da tabela 20. O tipo de objeto preenchido é marcado como 0, o que indica distorção da página de dados.

É possível consultar a tabela de catálogos para determinar qual tabela possui páginas corrompidas:

db2 "select char(tabname,20), char(tabschema,20) from
                    syscat.tables where tableid=20 and tbspaceid=9"

Observe que o DB2 despeja erros de página inválida apenas para aquelas páginas que tentou acessar. Isso não necessariamente significa que apenas essas páginas estão corrompidas. Você precisa verificar explicitamente todas as páginas em seu banco de dados para encontrar a extensão da distorção, com a ajuda dos comandos db2dart ouINSPECT .

As mensagens de erro similares são despejadas em db2diag.log para distorção em tabelas temporárias. Se o campo de tipo de dados na mensagem de erro db2diag.log tiver um valor maior que 128, isso indica distorção na tabela temporária. Se o tipo de objeto for 3, isso indica distorção de dados LOB em uma tabela.

Distorção do índice

Um índice é um objeto de banco de dados que contém um conjunto ordenado de ponteiros que se referem às linhas em uma tabela base. Há muitos tipos de problemas de danificação relacionados ao índice, incluindo:

  1. Duplicatas de índice exclusivo com RID(s) diferente(s) ou igual(is)
  2. Várias entradas de índice apontando para o mesmo RID
  3. Chave do índice deslocada (ordem da chave do índice errada)
  4. Linha existe, mas chaves de índice não existem em nenhum ou alguns dos índices
  5. Entrada de índice apontando para um slot de dados vazio ou slot de dados não utilizado ou RID é inválido
  6. Ponteiros de próxima página de índice ou anterior, chave alta incorreta ou outras distorções nas páginas de índice

A seguir, há uma mensagem de erro de amostra de distorção de índice.

Lista 2. Mensagem de erro de amostra para distorção de índice
2012-01-30-01.35.50.952434+000 I29308542A2532     LEVEL: Severe 
PID     : 1175792              TID  : 33926       PROC : db2sysc 0 
INSTANCE: inst1                NODE : 000         DB   : SAMPLE 
APPHDL  : 0-7                  APPID: *LOCAL.inst1.120130013528 
AUTHID  : TP0ADM 
EDUID   : 33926                EDUNAME: db2redow (TP0) 0 
FUNCTION: DB2 UDB, buffer pool services, sqlb_verify_page, probe:3 
MESSAGE : ZRC=0x86020001=-2046689279=SQLB_BADP "page is bad" 
DIA8400C A bad page was encountered. 
DATA #1 : String, 64 bytes 
Error encountered trying to read a page - information follows : 
DATA #2 : String, 23 bytes 
Page verification error 
DATA #3 : Page ID, PD_TYPE_SQLB_PAGE_ID, 4 bytes 
23046981 
DATA #4 : Object descriptor, PD_TYPE_SQLB_OBJECT_DESC, 72 bytes 
Obj: {pool:9;obj:11076;type:1} Parent={8;11076} 

Como é possível ver, as mensagens de erro têm o objeto tipo:1, o que indica distorção da página de índice. O índice reside no ID do espaço de tabela 9, e o ID do índice é 11076. Esse índice está em uma tabela com ID do espaço de tabela 8, tabela ID 11076. É possível recuperar o nome de tabela base e o nome do índice consultando tabelas de catálogos.

O fragmento acima de db2diag.log indica uma página inválida para o índice. Outros erros comuns em db2diag.log que apontam para distorção de índice são SQLI_NOKEY e linha não encontrada a partir da função índice.

Distorção CBIT

CBITs são um método utilizado pelo DB2 para verificar se uma página que está sendo lida no buffer pool do disco não é uma página parcial ou não foi alterada de alguma forma de distorção.

A ideia básica por trás de CBITs é que um bit de cada setor (512 bytes) em uma página é configurado com o mesmo valor antes da escrita da página. Antes que o DB2 limpe uma página do disco, o a soma de verificação é calculada e registrada na página. Quando uma página é lida novamente no buffer pool, essa soma de verificação é recalculada e verificada contra o valor armazenado. Se alguns bits forem diferentes, isso indica uma escrita de página parcial ou distorção do disco.

Lista 3. Mensagem de erro de amostra para distorção CBIT
2012-03-12-04.45.17.559235-240 I1104A2616 LEVEL: Severe
PID : 2551866 		       TID : 1 	  PROC : db2pfchr
INSTANCE: inst1   	       NODE : 000
FUNCTION: DB2 UDB, buffer pool services, sqlbVerifyCBITS, probe:1110
MESSAGE : ZRC=0x86020019=-2046689255=SQLB_CSUM "Bad Page, Checksum Error"
DIA8426C A invalid page checksum was found for page "".
DATA #1 : String, 64 bytes
Error encountered trying to read a page - information follows :
DATA #2 : String, 95 bytes
Erro de verificação CBIT
bitExpected is 0, userByte is 33, sector 7 (from head of page, 0 based)
DATA #3 : Page ID, PD_TYPE_SQLB_PAGE_ID, 4 bytes

Observe que as mudanças feitas na página fora do DB2 (falhas do sistema de arquivos, falhas de disco, etc.) não serão observadas se a distorção não envolver os bytes que contêm os CBITs. Na maioria das vezes, erros de CBIT (erros de soma de verificação) são devido a erro de hardware ou do SO, durante a gravação inicial ou durante a leitura.

Distorção de log

O log de transações no DB2 é simplesmente um registro de todas as mudanças que ocorreram no banco de dados. Para controlar as mudanças feitas por transações, é necessário um método para registro de data e hora das mudanças, bem como registro de data e hora dos registros de log. No DB2, esse mecanismo de registro de data e hora é executado usando um número de sequência do log (LSN, Log Sequence Number). Caso você depare com um log corrompido, pode ocorrer uma mensagem de erro em db2diag.log semelhante a.

Lista 4. Mensagem de erro de amostra para distorção de log
2010-06-07-12.37.21.143998+120 I8673583A553       LEVEL: Severe 
PID     : 2498668              TID  : 27358       PROC : db2sysc 56 
INSTANCE: inst1              NODE : 056         DB   : SAMPLE 
APPHDL  : 998-22947            APPID: *N998.inst1.100607192315 
AUTHID  : LOADDSF 
EDUID   : 27358                EDUNAME: db2agntp (SAMPLE) 56 
FUNCTION: DB2 UDB, data protection services, sqlpgrlg, probe:291 
DATA #1 : < reformatted >
Error -2028994519 when reading LSN 00000B1C261B4FD3 from log file 
S0119292.LOG tellMe 1 dpsAcbFlags 1000 setSkipOutputBuf 0 
                
2010-06-07-12.37.21.144202+120 I8674137A487       LEVEL: Severe 
PID     : 2498668              TID  : 27358       PROC : db2sysc 56 
INSTANCE: inst1              NODE : 056         DB   : SAMPLE
APPHDL  : 998-22947            APPID: *N998.inst1.100607192315 
AUTHID  : LOADDSF 
EDUID   : 27358                EDUNAME: db2agntp (SAMPLE) 56 
FUNCTION: DB2 UDB, data protection services, sqlpgrlg, probe:291 
DATA #1 : < preformatted >
HeadLsn 00000B1B8B996EB3, copyLookForLsn 00000B1C261B4FD3                               
                
2010-06-07-12.37.21.158065+120 I8675153A549       LEVEL: Error 
PID     : 2498668              TID  : 27358       PROC : db2sysc 56 
INSTANCE: inst1              NODE : 056         DB   : SAMPLE
APPHDL  : 998-22947            APPID: *N998.inst1.100607192315 
AUTHID  : LOADDSF 
EDUID   : 27358                EDUNAME: db2agntp (SAMPLE) 56 
FUNCTION: DB2 UDB, data protection services, sqlptudo, probe:1010 
RETCODE : ZRC=0x87100029=-2028994519=SQLP_BADLSN "Invalid LSN value." 
DIA8538C An invalid log sequence number (LSN), the value was "".

Se os logs estiverem corrompidos, isso pode resultar em um problema grave durante o rollforward do banco de dados, recuperação de falha, resposta de logs HADR, etc., quando você realmente responder a logs. O rollforward do banco de dados permite manter a consistência no banco de dados. Ele recupera um banco de dados, aplicando as operações registradas nos arquivos de log do banco de dados. Rollforward é um processo chamado após a restauração de uma imagem de backup do banco de dados ou do espaço de tabela.

Distorção do descritor compactado

Um descritor compactado é uma coluna nas tabelas de catálogo do sistema que o DB2 usa para identificar os detalhes de um objeto de banco de dados. Se estiver corrompido por algum motivo, você verá erros em db2diag.log, conforme mostrado a seguir.

Lista 5. Mensagem de erro de amostra para distorção do descritor compactado
2011-08-22-20.50.00.922275-300 I154161182E497      LEVEL: Severe 
PID     : 14152                TID  : 184633256288 PROC : db2sysc 0 
INSTANCE: inst1             NODE : 000          DB   : SAMPLE
APPHDL  : 0-64465              APPID: 161.166.44.48.27625.11082301341 
AUTHID  : DTADM1 
EDUID   : 606                  EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, catcache support, sqlrlc_systables_fetch_from_disk, 
probe:200 
MESSAGE : Corrupt PD->length in table:DTWF    .JBPM_TASKINSTANCE 
                
2011-08-22-20.50.00.922476-300 I154161680E1588     LEVEL: Severe 
PID     : 14152                TID  : 184633256288 PROC : db2sysc 0 
INSTANCE: inst1             NODE : 000          DB   : SAMPLE
APPHDL  : 0-64465              APPID: 161.166.44.48.27625.11082301341 
AUTHID  : DTADM1 
EDUID   : 606                  EDUNAME: db2agent (SAMPLE) 0 
FUNCTION: DB2 UDB, catcache support, sqlrlc_systables_fetch_from_disk, 
probe:201 
MESSAGE : Length in PD=3792, LFD length=10104, DMS length=10104 
DATA #1 : String, 11 bytes 
Corrupt PD: 
DATA #2 : Dumped object of size 3792 bytes at offset 1386248, 53 bytes 
/volumes/work/db2dump/xnawmtp5/14152.606.000.dump.bin 
DATA #3 : LOB Descriptor, PD_TYPE_LOB_DESCRIPTOR, 60 bytes 
SQLDX_LD: Size:60 
    x0000        lfd_check                        0x49 
    x0001        lfd_version                      6 
    x0002        lfd_numsegs                      1 
    x0003        lfd_flags                        0x00 
    x0004        lfd_size                         10104 
    x000C        lfd_life_lsn                     0000009860A6FF2D 
    x0014        lfd_mini_numsegs                 0 
    x0015        lfd_first                        4 
    x0016        lfd_descsize                     60 
    x0018        lfd_last_pages                   16 
    x001C        lfd_last_bytes                   10104 
    x0038        lfd_dir                          Regular Directory 
Offsets 
        lfd_dir[0]: 33888 (16K) 
    Hexdump of LOB descriptor follows: 
        4906 0100 0000 0000 7827 0000 0000 0098 
        60A6 FF2D 0004 3C00 1000 0000 7827 0000 
        0000 0000 0000 0000 0000 0000 0000 0000 
        0000 0000 0000 0000 6084 0000

Se você tiver um PD corrompido, a tabela ficará inacessível.


Usando db2dart e INSPECT para identificar distorção

db2dart é um comando que pode ser usado para verificar a exatidão arquitetural dos bancos de dados e dos objetos dentro deles. Também pode ser utilizado para extrair dados de tabelas que de outra podem estar inacessíveis devido a distorção.

db2dart nunca deve ser executado em um banco de dados que ainda possua conexões ativas. db2dart acessa os dados e metadados em um banco de dados lendo-os diretamente do banco. Portanto, se houver conexões, db2dart não terá conhecimento sobre as páginas no buffer pool, estruturas de controle na memória, etc., e pode informar erros falsos como um resultado. Da mesma forma, se você executar db2dart com um banco de dados que exige recuperação de falha ou que não concluiu o a recuperação de rollforward, é possível obter resultados inconsistentes.

Para exibir todas as opções possíveis, execute o utilitário db2dart sem parâmetros. Algumas opções de db2dart exigem entrada do usuário, como ID da espaço de tabela e ID da tabela, que são solicitados caso não sejam especificados explicitamente na linha de comando.

Inspecionando bancos de dados, espaços de tabela e tabelas usando db2dart

O comportamento padrão para db2dart é inspecionar o banco de dados inteiro. Apenas o nome do banco de dados deve ser fornecido nesse caso. Por padrão, db2dart criará um arquivo de relatório com o nome databaseName.RPT. Para ambientes de banco de dados de partição única, o arquivo é criado no diretório atual. Para ambientes de banco de dados de partição múltipla, o arquivo é criado em um subdiretório no diretório de diagnóstico. O diretório é chamado DARTnnnn, em que nnnn é o número de partição.

Se um banco de dados for grande e você só estiver interessado em um espaço de tabela, é possível usar a opção /TS . Ao usar isso, você deve fornecer o ID do espaço de tabela na linha de comando (especificando o parâmetro /TSI ) ou pode permitir que db2dart solicite isso. Se você não souber o ID do espaço de tabela, pode obtê-lo via DB2 LIST TABLESPACES.

Da mesma forma, uma única tabela e seus objetos associados (LOBs, índices, etc.) podem ser inspecionados usando a opção /T . Ao usar isso, você deve fornecer o nome da tabela ou o ID do objeto e o ID do espaço de tabela em que a tabela reside. Para determinar o ID do objeto e o ID do espaço de tabela para uma tabela, é possível consultar a tabela de catálogos SYSIBM.SYSTABLES.

Fazendo dumping de dados formatados da tabela usando db2dart

Se um espaço de tabela ou uma tabela for corrompido por qualquer motivo (por exemplo, devido a um disco ou controladora de disco inválido), as tentativas de acessar a tabela por meio do SQL podem não funcionar. A instrução SQL pode falhar com um erro ou o banco de dados pode ser marcado como inválido, e todas as conexões serão eliminadas.

Se isso acontecer, pode ser necessário extrair todos os dados possíveis para que o espaço de tabela e a tabela possam ser reconstruídos. Em tal situação, a opção /DDEL de db2dart pode ser usada para extrair os dados da tabela e colocá-los em um ASCII delimitado. As sessões a seguir discutem essas opções em detalhes.

INSPECT

O comando INSPECT é semelhante ao comando db2dart . Permite verificar bancos de dados, espaços de tabela e tabelas quanto à integridade arquitetural, verificando as páginas do banco de dados para a consistência da página. Uma diferença significativa entre os dois comandos é que o banco de dados precisa ser desativada antes da execução de db2dart, enquanto INSPECT requer uma conexão com o banco de dados e pode ser executado enquanto há conexões ativas simultâneas com o banco de dados.

Diferentemente de db2dart, o comando INSPECT não pode ser utilizado para formatar e fazer dump de páginas de dados, formatar e fazer dump de páginas de índice, formatar linhas de dados para o ASCII delimitado e marcar um índice como inválido. Portanto, só inspeciona o banco de dados ou seus objetos online quanto a distorção.


Abordagens para recuperar de distorção

Problemas de distorção do banco de dados às vezes não são simples e precisam do conhecimento de suporte da IBM para escolher a melhor maneira possível para sair da situação. Aqui, você verá como lidar com os tipos mais comuns de problemas de distorção e procurar as melhores opções possíveis de recuperação. Quando a distorção é detectada, a determinação da origem do problema geralmente é de importância secundária. Você deseja corrigir a situação atual primeiro.

Recuperando de distorção da página de dados

Conforme discutido, você precisa identificar as páginas corrompidas usando ferramentas como db2dart. Consultando o arquivo de relatório db2dart gerado, é possível calibrar a extensão da distorção. Dependendo da quantia de dados corrompidos e da complexidade envolvida, é necessário decidir sobre o melhor plano de recuperação possível. Eis algumas opções para recuperar:

  1. Se houver um backup do banco de dados, restaure o banco de dados e execute rollforward para o final dos logs. Esta é a abordagem mais clara, se factível, de preferência se o tamanho do banco de dados for pequeno.
  2. Você também pode restaurar o espaço de tabela e executar rollforward para o final dos logs. Essa pode ser a melhor opção se a distorção for localizada.
  3. Se você tiver outras maneiras de recriar os dados para a tabela corrompida ou tiver uma cópia dos dados da tabela, elimine e recrie a tabela. Você precisaria do DDL da tabela, e, se você tiver os dados para a tabela, deve conseguir eliminar a tabela, recriar a tabela usando o DDL e recriar os dados por qualquer meio que você tenha.
  4. Se você não tiver uma imagem de backup válida e nenhuma forma para recriar a tabela, pode usar db2dart com /ddel para recuperar os dados de uma tabela corrompida. Antes disso, você precisa ter o DDL da tabela usando db2look. É possível buscar o DDL de uma tabela corrompida usando:
    db2look -d <dbname> -e
                            -z <schema_name> -t <table_name> -o <output_file_name>

    Eis um exemplo de uso de db2dart com /ddel para recuperar os dados de uma tabela corrompida: db2dart <dbname> /ddel. Este comando requer quatro valores de entrada: um ID do objeto da tabela ou nome da tabela, ID do espaço de tabela, número da página para começar e número de páginas. O número de páginas pode ser um valor específico ou um valor suficientemente grande (por exemplo, 999999999) para extrair todas as páginas da tabela. Além disso, se uma determinada página na tabela contiver muitos danos, db2dart /DDEL talvez precise ser executado mais de uma vez para o intervalo de páginas e omitir a página danificada.

    O arquivo ASCII delimitado despejado é codificado na página de códigos do banco de dados. O comando db2dart não executa conversões de página de códigos. Depois de recuperar todos os dados da tabela corrompida, é possível verificar o arquivo de saída *.DEL para assegurar que todos os dados existam. Quando isso for feito, será possível eliminar a tabela corrompida e recriá-la posteriormente com os dados extraídos usando db2dart. Observe que db2dart /DDEL não funciona com os dados lob.

  5. Se você tiver uma forma para recriar o espaço de tabela corrompido, pode marcar o espaço de tabela corrompido no estado de eliminação pendente usando restart database. É possível recriar o espaço de tabela corrompido posteriormente.
  6. Se nenhuma das opções acima for factível ou apresentar algum erro durante a extração dos dados, eliminando a tabela durante a recriação da tabela, etc., consulte o suporte IBM para obter ajuda. O suporte IBM pode ajudá-lo a eliminar a tabela corrompida, inicializar páginas corrompidas para NULL, etc., dependendo da situação.

Recuperando de distorção de índice

Se houver indicações de distorção do índice em relatórios db2diag.log e/ou db2dart , é possível marcar um índice inválido usando db2dart e livrar-se de de índices inválidos. É possível recriar índices posteriormente.

db2dart tem uma opção de marcar um índice como inválido e fazer com que ele fique pendente para eliminação. É possível marcar um índice corrompido como inválido com db2dart /MI. Por exemplo, db2dart <dbname> /MI /TSI 9 /OI 11076.

É possível decidir quando recriar um índice configurando o parâmetro INDEXREC para reiniciar, acessar, etc. Para recriar índices quando um aplicativo tentar acessar o índice, é possível atualizar INDEXREC para acessar: db2 update db cfg for <dbname> INDEXREC ACCESS.

Depois de invalidar o índice inválido e atualizar INDEXREC, é possível conectar-se ao banco de dados.

Se o problema for um erro NOKEY de índice, então diversos comandos db2dart serão impressos no arquivo db2diag.log. É possível executar esses comandos db2dart <dbname> /di para fazer dump dos dados de índice formatados para análise de causa-raiz de distorção do análise, se necessário. É necessário salvar estes comandos usando grep no UNIX® ou Localizar no Windows® e salvá-los em um arquivo. Edite o arquivo e substitua DBNAME pelo nome do banco de dados. Se o problema tiver ocorrido várias vezes, pode haver entradas duplicadas. Você só precisa manter o último conjunto de comandos db2dart . Para confirmar o índice inválido usandodb2dart, é possível emitir db2dart <dbname> /t /tsi <tablespace_id> /oi <table_id> em quetablespace_id e table_id são o ID do espaço de tabela e o ID do objeto da tabela base em que o índice está definido.

Recuperando de erros CBIT

Para corrigir erros de distorção CBIT, examine a extensão do problema executando um db2dart pelo menos na tabela corrompida (melhor executá-lo com o banco de dados inteiro). É possível decidir sobre as abordagens discutidas acima dependendo se os erros CBIT estão na página de dados ou no índice. A opção mais factível para se recuperar de erros CBIT é restaurar o banco de dados ou o espaço de tabela (se os erros forem localizados).

Recuperando de distorção de log

A distorção de log é uma preocupação durante a reprodução de log. Pode ser necessário reproduzir logs durante o rollforward do banco de dados ou espaço de tabela, reprodução de log na espera HADR e recuperação de falha. No caso de distorção de log, o banco de dados pode estar bem e apenas o log pode ser danificado.

Se você tiver erros devido a logs inválidos durante o rollforward, a primeira coisa que pode ser feita é verificar para qual arquivo de log o DB2 está informando erros. db2flsn pode ser usado para retornar o nome do arquivo que contém o registro de log identificado por um LSN especificado. Portanto, se você tiver mensagens 'bad_lsn' em db2diag.log, pode usar db2flsn para localizar o arquivo de log correspondente.

Se for para um arquivo de log ausente ou um arquivo de log de uma cadeia de log incorreta, é possível procurar o arquivo de log correto. Se o rollforward falhar devido a um log corrompido, é possível ir para rollforward de momento. O momento especificado para a operação de rollforward deve ser igual ou posterior ao tempo mínimo de recuperação. O ponto mínimo de recuperação (MRT, Minimum Recovery Time) é o momento mais cedo durante um rollforward quando um banco de dados está consistente. Se você não puder executar rollforward de logs para o MRT no mínimo, é necessário entrar em contato com o suporte IBM para obter assistência. Outra opção seria restaurar de um backup de banco de dados offline e não executar rollforward dos logs. Transações em logs não seriam aplicadas ao banco de dados nesse caso.

Se você tiver problemas na recuperação de falha devido a um arquivo de log inválido, é necessário restaurar o backup recente ou entrar em contato com o suporte IBM para assistência.

Na terminologia HADR, o servidor que processa transações é conhecido como primária e o banco de dados do parceiro que recebe logs e os reproduz é chamado de espera. Na espera HADR, durante a reprodução de log, a espera pode travar devido a um log inválido. É possível verificar db2diag.log na espera para descobrir o arquivo de log inválido e tentar remeter uma boa cópia desse arquivo de log de primário. Quando um arquivo de log válido está em vigor, é possível iniciar o HADR:

  1. Execute o início no HADR do nó de espera: db2 start hadr on db <dbname> as standby.
  2. Execute o início no HADR do nó primário: db2 start hadr on db <dbname> as primary.

Se a tentativa acima falhar, pode ser necessário reconfigurar o HADR com novo backup de primário e restaurá-lo na espera. Se você transmitir uma cópia do arquivo de log inválido para o suporte do IBM DB2, ele pode examinar seu conteúdo para ver o que há nele que possa dar alguma indicação do que falhou.

É possível usar db2cklog para verificar a validade dos arquivos de log de archive a fim de determinar se os arquivos de log podem ser usados durante a recuperação de rollforward de um banco de dados ou espaço de tabela. Um arquivo de log de archive simples ou um intervalo de arquivos de log de archive pode ser verificado. Um arquivo de log que retorna um erro durante a validação pordb2cklog fará com que a operação de recuperação falhe.

Recuperando de distorção do descritor compactado

É possível usar a ferramenta db2cat para corrigir o descritor compactado corrompido. É necessário consultar o suporte IBM antes de modificar um descritor compactado. Execute as etapas a seguir para modificar o descritor compactado:

  1. export DB2SVCPW=<service_password from IBM support>
  2. db2cat -d <dbname> -s <schema> -n <tablename> -f <raw pd output file> -o <message file>
  3. db2cat -d <dbname> -s <schema> -n <tablename> -g <generated pd output file> -o <message file>
  4. db2cat -d <dbname> -s <schema> -n <tablename> -r <generated pd output file> -o <message file>

    (use o arquivo gerado com -g como a entrada para a opção de substituição "-r").

  5. Exporte os dados da tabela (se necessário)
  6. Elimine a tabela
  7. Recrie a tabela (se necessário)
  8. Importe os dados do usuário (se necessário)

Agora é possível executar a opção de verificação de db2cat no banco de dados novamente: db2cat -d <dbname> -s % -n % -v .

Se não precisar das tabelas, é possível eliminá-las. Caso contrário, é necessário substituir o descritor compactado, extrair os dados, depois eliminar e recriar a tabela.


Estratégias preventivas para evitar possível distorção

A distorção do banco de dados pode ser sutil e difícil de detectar. Portanto, pode nunca haver uma ferramenta desenvolvida que consiga detectar cada distorção única que possivelmente ocorra. Distorções e procedimentos que geram a possibilidade de distorção devem ser sempre evitados.

É essencial entender diversas medidas preventivas para evitar possível tempo de inatividade e travamento do banco de dados. Eis algumas melhores práticas para ajudá-lo a identificar distorção em um banco de dados antes de um travamento do sistema:

  1. Mantenha o controle de todas as mudanças.
  2. Esteja no fix pack mais recente e, se possível, na versão mais recente do DB2 e sistema operacional (se aplicável).
  3. Faça uma verificação regular do funcionamento do sistema de arquivos, problemas de rede.
  4. Enquanto possível, encerre o DB2 de forma normal.
  5. Execute db2dart contra o banco de dados quando estiver offline para verificar se há distorção. Se você não puder se dar o luxo de tempo de inatividade necessário para executar db2dart no banco de dados de produção, restaure os backups de produção recentes nas máquinas de teste e execute db2dart. Como alternativa, também é possível INSPECT quando o banco de dados estiver online. Isso pode funcionar como detecção precoce ou verificação de funcionamento proativo para distorção.
  6. Tenha uma boa política de backup. O backup não detecta distorção em uma página, portanto é recomendável ter uma forte política de backup e suficientes gerações de backup.
  7. Configurações de disco, como RAID, ajudam a minimizar a distorção de dados usando discos redundantes para fazer backup dos dados.
  8. Faça um bom backup de energia para combater a distorção devido a picos de energia.
  9. Rastreie os defeitos mais recentes no IBM DB2 e no sistema operacional.

Conclusão

O artigo discutiu os problemas de distorção mais comuns ao utilizar o IBM DB2. Ele demonstrou diversas mensagens de sintoma de problemas de distorção no db2diag.log, como identificar o tipo de distorção com base nessas mensagens, e como solucionar esses problemas. Ele também descreveu os comandos db2dart e INSPECT , que são úteis ao lidar com problemas de distorção.

Recursos

Aprender

Obter produtos e tecnologias

  • Crie seu próximo projeto de desenvolvimento com o Versão de teste do software IBM, disponível para download diretamente no developerWorks.
  • Agora é possível usar o DB2 gratuitamente. Faça o download do DB2 Express-C, uma versão gratuita do DB2 Express Edition para a comunidade que oferece os mesmos recursos de dados centrais que o DB2 Express Edition e fornece uma base sólida para desenvolver e implementar aplicativos.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management
ArticleID=833551
ArticleTitle=Diagnosticando Distorção ao Utilizar o IBM DB2
publish-date=09062012