Olá pessoal,
Esses dias na empresa executamos um reorg em um banco do TSM 5.5. Sim é quase backlevel. Sim, já podíamos ter migrado para 6, mas não deu. O mesmo atingiu impressionantes 543GB e 100% de uso.
Para quem custa acreditar que o TSM 5.5 chegasse a esse tamanho.:
Após deleção de nodes antigos e exports de outros, o banco ficou altamente fragmentado e a execução do reorg foi inevitável pois nem mesmo alguns selects estavam rodando, pois estavam apresentando mensagens de "SQL temporary table storage has been exhausted".
Abaixo está o passo-a-passo do procedimento executado.
1- Após finalização da janela de backup, foi desabilitado todas as sessões para que nada novo entrasse.:
2- Migration de todos os diskpools para fita.:
3- Validação se todos os diskpools estavam zerados.:
4- Execução de um backup full do DB do TSM.:
5- Validação da execução do backup do DB.:
6- Criação de uma deviceclass do tipo FILE com o Directory apontando para o path onde será gerado o dump.:
7- Excesso de zelo. Backup do devconfig e volhist.:
8- Excesso de zelo. Listar volumes dos DB e LOG atuais.:
9- Agora sim. Efetue halt e prossiga com o unloaddb.:
Obs.: Aqui uma observação. O erro estava ocorrendo durante a leitura o dsmserv.dsk. Após algum tempo analisando percebemos que como temos mais de uma instância ativa no mesmo servidor, por algum motivo, mesmo tempo exportado todas as variáveis da instância correta, ele tava buscando um dsmserv.dsk de outro caminho.
10- Optamos por utilizar o parâmetro -k e passando o nome do Server da instância, no caso Server4. Com isso ele carregou todas as variáveis corretas e passou.
Obs.: Reparem que nesse momento o TSM emite um Warning de que está rodando em modo Standalone e logo abaixo o dump sendo gerado no caminho que você passou quando criou a deviceclass.:
11- Validação do término do processo de unloaddb.:
12- Após o processo de unloaddb, é necessário rodar o comando de loadformat para formatação dos novos volumes de DB e LOG.
Obs.: O comando precisa passar parâmetro sobre a quantidade e o nome dos logvolumes e dos dbvolumes. Uma dica aqui é que não encontrei na documentação oficial desse comando que logo após o nome do logv/dbv é necessário passar o tamanho em MB que será criado esses volumes. Foi feita uma tentativa sem passar o tamanho e tava dando erro, mas nada como uma pesquisa boa na net para encontrar a resposta.
13- Reparem que logo após a formatação dos logvolumes, o processo começa a formatação dos dbvolumes.:
14- Valide se finalizou com sucesso. Reparem que no final a log informa que o DB está pronto para ser dado load.:
15- Agora é o momento de efetuar loaddb. Reparem no comando que é necessário informar o caminho e o nome do dump que foi gerado no processo de unloaddb.:
Obs.: Vejam que logo no começo do processo a log informa que o dump está consistente e que ao final não será necessário efetuar auditdb.:
16- Validem se finalizou com sucesso e vejam que ao final vem a mesma mensagem onde informa que não é necessário efetuar o auditdb.:
17- Aqui, apenas uma validação do DB subindo-o em modo foreground.:
18- Com a validação Ok, basta dar halt e subir o banco em modo background normalmente. Aqui a validação do DB como ficou após o processo.:
Obs.: Uma dica aqui é não esquecer de dar um update server entre a librarymanager e a libraryclient com o forcesync, senão fica dando erro de autenticação entre as duas.
Resumindo.:
Tínhamos um banco de 543GB e 100%
Ao final do processo ficamos com um banco de 80GB e 78% de uso, ou seja, efetivamente um banco de 62,4GB.
Espero que tenham curtido. Qualquer dúvida, sugestão ou correção sobre o que foi escrito aqui ou em outros posts, escreva para tsmnapratica@gmail.com ou publiquem na área de comentários.
Caso queiram compartilhar a solução de algum problema que tiveram, escreva também que faço a publicação.
Abraços.
