Construindo scripts eficientes para administrar bancos de dados Progress

Uma deficiência conhecida a muito tempo no mundo Progress é deficiência de ferramentas para administração de bancos de dados. Nas versões atuais, a ferramenta disponbilizada com a licença de banco de dados é o Progress Explorer Tool, que convenhamos, não pode ser categorizada como User-Friendly.

Uma opção para rotinas de administração, ainda bastante limitada, é o OpenEdge Management, conhecido anteriormente por Fathom Management. O problema dessa ferramenta é o custo que não se aceita pagar por funções que deveriam ser disponibilizadas na licença do próprio banco de dados.

Enfim, desviando da política de preços da Progress, a solução que vemos na grande parte dos clientes de bancos de dados OpenEdge é a utilização de scripts que administram o startup, shutdown, backup, recovery, replicação, segurança, e em alguns casos, até mesmo monitoração do ambiente.

Scripts geralmente são eficientes para fazer todas essas rotinas. Porém eles são construídos sob demanda, e não de forma pensada no ambiente completo e nas possibilidades de manutenção. Isso resulta em rotinas tão complexas, emendadas e não documentadas, que diante da necessidade de uma alteração do ambiente é mais fácil reconstruí-los que manutení-los.

Vamos a alguns exemplos de como construir scripts simples e eficientes

Esse script inicia todos os bancos cadastrados no AdminService. É simples, mas funcional. Todos os parâmetros estão gravados no arquivo conmgr.properties, que segue um padrão para qualquer ambiente com Progress OpenEdge. No mesmo arquivo a Progress já disponibiliza a documentação dos parâmetros que podem ser disponibilizados. Da mesma forma, o comando “dbman –all –stop” para todos os bancos de dados cadastrados no AdminService.

O próprio AdminService também se encarrega de derrubar os bancos de dados nele cadastrados, quando o servidor for desligado por um procedimento normal.

Outra forma eficiente de executar rotinas para todos os bancos de dados do ambiente é usar estruturas de repetição do próprio sistema operacional. Para isso, a recomendação é manter todos os .db no mesmo diretório e balancear a carga de disco nas extensões de dados, before-image e after-image. Vejamos alguns exemplos:

Esse código pega todos os arquivos com a extensão .db do diretório d:\bancos e executa o comando que lista a estrutura do banco de dados, atualizando o arquivo .st de cada banco. Além de reduzir a quantidade de linhas de comando, evita que o script tenha que ser manutenido diante da criação de um novo banco de dados.

Da mesma forma o seguinte comando pode ser usado em plataforma Unix.

Então, um script que faça backup offline de alguns bancos de dados em Windows pode ser assim:

Evite utilizar recursos desnecessário, como:

• Vários scripts para fazer uma mesma operação: Se o script é de backup, ele deve conseguir fazer o backup, sem chamar mais nenhum script. Se desejar sempre que parar um banco fazer o backup, então no script de parada de banco, chame o script de backup. A importância de segmentar as rotinas é unicamente não precisar reescrevê-las;
• Definir mais variáveis de ambiente do que é necessário: O nome do banco estará na variável de ambiente em comandos como o “for”, mostrado acima. Nunca utilize variáveis para o nome do banco, nem para o diretório. Além de complicar o entendimento do script, convenhamos, com que frequência você altera o diretório do .db?
• Definir os parâmetros de carga em variáveis de ambiente: A definição de parâmetros é por banco. Isso é assim para que cada banco de dados receba a melhor configuração de parâmetros, conforme monitorações de indicadores, e não conforme padrões.

E principalmente, construa algo que qualquer pessoa na sua empresa possa entender no futuro.