Dando continuidade ao meu Guia de Estudos para o exame 731 (DBA DB2), falaremos aqui sobre os utilitários do DB2. Esta parte é realmente fácil de se entender, porém, demanda muita experiência diária de um DBA! Desconsidere erros de português, este guia foi escrito conforme eu estudava, então o foco era aprender, e não escrever bem. Vamos lá:
5.1 Movimentando dados no DB2
Antes de falar sobre qualquer utilitário, é importante ressaltar que a FONTE e o DESTINO dos dados precisam ser compatíveis, embora obvio, muitas pessoas erram nisso. Os utilitários trabalham com tipos de dados definidos, o mais famoso é o do tipo DEL (Delimited ASCII), por exemplo, quando exporto uma tabela, exporto para um arquivo .del, para importar, preciso ler esse .del.
5.2 Utilitários para movimentação de dados
5.2.1 Export
O export extrai dados de uma tabela para um arquivo utilizando uma clausula SQL ou XQuery. Você pode logar qualquer problema em um arquivo texto utilizando a clausula MESSAGES. Exemplo:
EXPORT TO myfile.del OF DEL
MESSAGES msg.out
SELECT *
FROM staff;
5.2.2 Import
Obviamente o import recebe um arquivo que foi exportado pelo export e o importa em uma tabela ou view. O Import não importa os dados em tabelas do sistema ou tabelas temporárias. A sintaxe do import é:
IMPORT FROM file_name OF file_type
MESSAGES message_file
[ INSERT | INSERT_UPDATE | REPLACE | REPLACE_CREATE | CREATE ]
INTO target_table_name
Como visto, existem 5 formas de se importar:
- INSERT: Destino deve existir, os dados serão inseridos na tabela.
- INSERT_UPDATE: Destino deve existir, os dados serão inseridos na tabela, caso algum já exista (verificando chave primária), ele sofrera um update. Destino precisa ter PK definida.
- REPLACE: Destino deve existir, todos os dados existentes na tabela serão removidos e os novos dados serão inseridos na tabela. Destino precisa ter PK definida.
- REPLACE_CREATE: Tabela destino não precisa existir. Neste caso a mesma será criada e suas chaves tambem. Caso já exista, o dado existente será substituido. só funciona com o tipo de arquivos IXF, pois ele armazena dados da estrutura da tabela.
- CREATE: Tambem só funciona com IXF. Ele cria a tabela com as chaves necessárias e insere os dados.
IMPORT FROM emp.ixf OF IXF
MESSAGES msg.out
CREATE INTO employee IN datatbsp INDEX IN indtbsp
Quando um import está sendo efetuado, ele obtem um Lock na tabela. Isso pode ser cancelado atraves da opcao "Allow write access". Tambem pode-se estabelecer uma contagem de linhas para commit ser efetuado, caso contrário, o mesmo será efetuado somente ao final da transação.
Tambem pode ser utilizado a clausula RESTARTCOUNT, no exemplo abaixo:
IMPORT FROM myfile.ixf OF IXF
COMMITCOUNT 500 RESTARTCOUNT 30000 ROWCOUNT 100000
MESSAGES msg.out
INSERT INTO newtable
vamos supor que algum problema ocorra apos a importação da linha 30000. Se você executar o comando acima, o import será reiniciado a partir da linha 30000 do arquivo myfile.ixf e irá até a linha 100000.
5.2.3 Load
Faz exatamente o mesmo que o import, porem ele ignora constraints e nem dispara triggers, dessa forma é muito mais rápido, mas pode gerar alguma inconsistência no banco se utilizado sem cuidado.
Supondo que um DBA deseja deletar todos os dados armazenados em uma tabela employee em um server AIX, para atingir o seu objetivo ele poderia executar o seguinte comando:
LOAD FROM /dev/null OF DEL REPLACE INTO employee
5.2.4 db2move
É utilizado para mover grande numero de tabelas. Por exemplo, todas as tabelas de um banco de dados Sample:
db2move database_name
action
options
O db2move basicamente executa IMPORT/EXPORT/LOAD/COPY para várias tabelas ao invés de uma tabela só.
5.2.5 db2lock
É um utilitário que gera DDL de objetos do banco de dados, além disso, gera updates para atualizar parametros do banco de dados, comandos db2set, gera estatísticas, etc.
Um bom exemplo de seu uso é grando se quer importar uma tabela em um banco, mas se necessida da estrutura da mesma, então utilizamos o db2lock no banco de origem para gerar o ddl da tabela. No exemplo abaixo, estamos gerando um ddl de todas as tabelas do peter no banco department:
db2look -d department -u peter -e -o alltables.sql
5.2.6 db2batch
Objetivamente, executa uma série de comando que você pode especificar em um arquivo e gera um output com detalhes de benchmarching, tais como tempo que demorou para executar a operação, etc.
5.3 Utilitários de manutenção
5.3.1 runstats
O DB2 mantém tabelas de sistema com dados estatísticos tais como número de linhas em uma tabela, tamanho, etc. Tais dados permitem que o SGBD aloque os recursos necessários para se efetuar alguma operação que manipule algo. Se estes dados estiverem errados, tal alocação de recursos pode ser erronea, o banco pode por exemplo alocar menos memória ou cpu que o necessário, assim, a operação irá demorar muito mais.
Para atualizar os estas estatísticas que o banco consula, o comando é o runstats. O comando tem varios parametros, é possível fazer isso por tabela, fazer para os indices ou não, colocar a mesma em modo somente leitura para otimizar a operação, etc.
A utilização do runstats é importante ser executada após um grande número de insert, update, delete, opereção de import, load, etc, para obter informações do status do SGDB e ter um maior controle dos recursos. Por padrão, a atualização das estatísticas é automática no DB2, mas pode ser desabilitada ou forçada a qualquer momento.
5.3.2 reorg e reorgchk
5.3.2 reorg e reorgchk: Assim como acontece com o sistema de arquivos de um sistema operacional, os dados de uma tabela ou index podem se fragmentar. O utilitário reorg desfragmenta os dados de uma tabela, deixando-os mais próximos ou em seguencia no disco (quando possível). Tais comandos podem lockar ou não a tabela na qual estiverem rodando. O reorgchk, checa se um reorg é necessário e gera estatisticas/um relatório completo. Exemplos são:
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE ALLOW WRITE ACCESS
REORG TABLE db2user.employee INDEX db2user.idxemp INPLACE PAUSE
5.3.3 rebind
Recompila um pacote. Um pacote é um objeto de banco de dados que contem instruções já compiladas.
A sintaxe é: REBIND PACKAGE package_name
A figura a seguir ilustra o trabalho de um DBA para manter um banco de dados "up and running":
Voltar para o índice do Guia.
Nenhum comentário:
Postar um comentário