datasul manual do administrador progress.pdf
TRANSCRIPT
DATASUL
Manual do Administrador do
Sistema PROGRESS
Versão: I.00
Data Liberação: 01/Outubro/96
Visão Geral do Banco de Dados PROGRESSS …………………………………… 1-1 ……
1.1. PROGRESS …………………………………………………………………... 1-1 ……
1.2. Estrutura do Banco de Dados ……………………………………………….... 1-1 ……
1.2.1. Extensões do Banco de Dados ……………………………………………… 1-2 ……
1.2.2. Base de Dados ………………………………………………………………. 1-2 ……
1.2.3. Processo do Servidor do Banco de Dados ………………………………….. 1-2 ……
1.2.4. Processo Broker do Banco de Dados ………………………………………. 1-2 ……
1.2.5. Cache do Banco de Dados ………………………………………………….. 1-2 ……
1.2.6. CPU ………………………………………………………………………… 1-2 ……
1.3. DataServer ……………………………………………………………………. 1-3 ……
1.3.1. Schema Holder ……………………………………………………………… 1-4 ……
1.4. Limites do PROGRESS ………………………………………………………. 1-4 ……
1.4.1. Banco de Dados …………………………………………………………….. 1-4 ……
1.4.2. Elementos do Banco de Dados ……………………………………………... 1-5 ……
1.5. Sistemas Operacionais
…………………………………………………………
1-5 ……
1.6. Modos de Conexão …………………………………………………………… 1-5 ……
1.7. Localização do Banco de Dados ……………………………………………… 1-6 ……
1.8. Cliente Servidor ……………………………………………………………. 1-7 ……
Parâmetros ………………………………………………………………………… 2-1 ……
2.1. Parâmetros ……………………………………………………………………. 2-1 ……
Blocos no Buffer do Banco de Dados (-B) ………………………………………... 2-1 ……
Número de Cursores de Índice (-c) ………………………………………………... 2-1 ……
Formato da Data (-d) ……………………………………………………………… 2-2 ……
Área do Diretório de Programas (-D) ……………………………………………... 2-2 ……
Formato Numérico Europeu (-E) ………………………………………………….. 2-3 ……
Número de Entradas na Tabela de Bloqueio (-L) …………………………………. 2-3 ……
Número máximo de clientes por servidor (-Ma) …………………………………... 2-4 ……
Atraso na Gravação do Arquivo .bi (-Mf) …………………………………………. 2-4 ……
Número mínimo de clientes por servidor (-Mi) …………………………………. 2-5 ……
Número máximo de servidores (-Mn) ……………………………………………... 2-5 ……
Exemplo de uso dos parâmetros -Mn, -Ma e -Mi …………………………………. 2-6 ……
Número de Usuários (-n) ………………………………………………………….. 2-6 ……
Impressora (-o) …………………………………………………………………….. 2-7 ……
Programa Inicial (-p) ………………………………………………………………. 2-7 ……
Arquivo de Parâmetros (-pf) ………………………………………………………. 2-7 ……
Pedido Rápido (-q) ………………………………………………………………… 2-8 ……
Modo de Compilação de Programas (-rx) …………………………………………. 2-8 ……
Nome do Servidor (-S) …………………………………………………………….. 2-9 ……
Diretório para Arquivos Temporários (-T) ………………………………………... 2-9 ……
Classificação Rápida (-TB) ……………………………………………………… 2-10 …..
Número de Merge (-TM) ………………………………………………………...... 2-11 …..
Nome Físico do Banco de Dados (-db) ……………………………………………. 2-11 …..
Nome Lógico do Banco de Dados (-ld) …………………………………………… 2-11 …..
Acesso em Monousuário (-l) ………………………………………………………. 2-12 …..
Nome do Arquivo de After-Image (-a) ……………………………………………. 2-12 …..
Nome do Arquivo Before-Image (-g) ……………………………………………... 2-12 …..
Nome do Usuário do Banco (-U) ………………………………………………….. 2-13 …..
Senha do Usuário do Banco (-P) ………………………………………………….. 2-13 …..
Backup …………………………………………………………………………….. 3-1 ……
3.1. Importância …………………………………………………………………… 3-1 ……
3.2. Do que deve ser feito Backup ? ………………………………………………. 3-1 ……
3.3. Qual mídia magnética utilizar para o Backup ? ………………………………. 3-1 ……
3.4. Período de Backup …………………………………………………………… 3-2 ……
3.5. Backup Utilizando o Sistema Operacional …………………………………… 3-2 ……
3.5.1. Backup em DOS/OS2 ………………………………………………………. 3-2 ……
3.5.2. Backup em UNIX …………………………………………………………... 3-3 ……
3.5.3. Backup em VMS ……………………………………………………………. 3-3 ……
3.6. Backup utilizando probkup e prorest …………………………………………. 3-4 ……
3.6.1. Probkup Completo do Banco de Dados …………………………………….. 3-4 ……
3.6.2. Probkup incremental ………………………………………………………... 3-5 ……
3.6.3. Probkup Online ……………………………………………………………... 3-5 ……
3.6.4. Restaurando Backup feito com o probkup (prorest) ……………………….. 3-6 ……
3.6.5. Regras importantes para restaurar backup incremental …………………….. 3-7 ……
3.7. Exemplos de Uso do probkup e prorest ………………………………………. 3-7 ……
3.7.1. Exemplo de uso do probkup em DOS ……………………………………… 3-7 ……
3.7.2. Exemplo de uso do probkup em UNIX …………………………………….. 3-8 ……
3.7.3. Exemplo de uso do probkup em VMS ……………………………………… 3-9 ……
3.8. Exemplo de um esquema de Backup do Banco de Dados ……………………. 3-11 …..
3.9. Teste do Backup ……………………………………………………………… 3-12 …..
3.10. Cuidados com a Mídia Magnética …………………………………… 3-13 …..
3.11. Outras Recomendações …………………………………………………….... 3-14 …..
Multi-Volume …………………………………………………………………… 4-1 ……
4.1. Conceito de Multi-Volume …………………………………………………… 4-1 ……
4.2. Passos para transformar um banco em Multi-Volume ………………………... 4-2 ……
4.2.1. Backup do Banco de Dados ………………………………………………… 4-2 ……
4.2.2. Criação do Arquivo de Estrutura (.st) ……………………………………… 4-2 ……
4.2.3. Criação da Estrutura do Banco Multi-Volume ……………………………... 4-3 ……
1. Criação da Estrutura com área em disco disponível ………………………….. 4-3 ……
2. Criação de Banco Multi-Volume usando o probkup …………………………… 4-5 ……
3. Criação do Banco Multi-Volume sem usar o probkup …………………………. 4-5 ……
4.3. Adicionando novas extensões ao Multi-Volume …………………………… 4-5 ……
4.4. Listando a Estrutura do Multi-Volume ……………………………………….. 4-7 ……
4.5. Usando Estatísticas do Banco ………………………………………………… 4-7 ……
4.6. Algumas considerações sobre multi-volume ……………………………….. 4-7 ……
After-Image ………………………………………………………………………... 5-1 ……
5.1. After-Image e Before-Image ………………………………………………….. 5-1 ……
5.1.1. Como funciona o processamento Before-Image ……………………………. 5-1 ……
5.1.2. Processamento After-Image ………………………………………………… 5-2 ……
5.2. Preparação para usar o After-Image ………………………………………….. 5-4 ……
5.2.1. Escolhendo a localização para os arquivos do banco ……………………….. 5-4 ……
5.2.2. Estratégia de Backup ……………………………………………………….. 5-5 ……
5.3. Usando o After-Image ………………………………………………………... 5-5 ……
5.3.1. Passos para usar o after-image ……………………………………………… 5-5 ……
5.3.2. Fazendo backup do Banco de Dados ………………………………………. 5-6 ……
5.3.3. Marcando o banco como "backupeado" ……………………………………. 5-6 ……
5.3.4. Habilitando o after-image do banco ………………………………………… 5-6 ……
5.3.5. Usando um banco com after-image habilitado ……………………………… 5-7 ……
5.3.6. Iniciando um novo after-image …………………………………………… 5-8 ……
5.3.7. Desabilitando o after-image ………………………………………………… 5-8 ……
5.4. Reprocessando um arquivo after-image ……………………………………… 5-9 ……
5.5. O que pode e o que não pode fazer no after-image …………………………... 5-9 ……
5.6. O que fazer durante erros do sistema …………………………………………. 5-10 …..
5.6.1. Durante o uso do proutil e rfutil ……………………………………………. 5-10 …..
5.6.2. Durante o backup do Banco de dados ……………………………………… 5-10 …..
5.6.3. Durante o uso do PROGRESS …………………………………………….. 5-10 …..
5.6.4. Perda do disco do .db ou .ai ………………………………………………… 5-11 …..
5.6.5. Perda do arquivo after-image ……………………………………………….. 5-11 …..
5.6.6. Perda do backup do banco ………………………………………………….. 5-11 …..
5.7. O que fazer quando o disco lotar ……………………………………………... 5-12 …..
5.7.1. Quando o disco do After-Image lotar ………………………………………. 5-12 …..
5.7.2. Quando o disco do .db ou .bi lotar …………………………………………. 5-12 …..
5.8. Outras Considerações …………………………………………………………. 5-13 …..
Copyright 1993 DATASUL S.A.
Este documento é de propriedade da DATASUL. Não poderá ser alterado, copiado,
fotocopiado, traduzido sem o prévio consentimento da DATASUL S.A.
MAGNUS é uma marca registrada da DATASUL S.A.
PROGRESS é uma marca registrada da PROGRESS Software Corporation.
UNIX é uma marca registrada da AT&T Bell Labs.
MSDOS e OS2 são marcas registradas da Microsoft Corporation.
VMS é uma marca registrada da Digital Equipment Corporation.
Este manual visa fornecer ao administrador do sistema MAGNUS todas informações
necessárias para a administração do PROGRESS.
Este administrador do sistema será a pessoa responsável em manter o MAGNUS em
funcionamento para que os usuários possam utilizar o mesmo.
A seguir, é mostrado um breve resumo de cada capítulo.
1. Visão Geral do Banco de Dados PROGRESS
Este capítulo apresentará uma visão geral de todo o ambiente e dos principais componentes
da Base de Dados PROGRESS: sua estrutura física e lógica, limitações, etc.
2. Parâmetros
Este capítulo explicará os parâmetros do PROGRESS, dando uma visão geral de cada um
deles, sua função e influencia no PROGRESS.
3. Backup
Este capítulo dá as informações para o administrador do MAGNUS realizar o Backup do
sistema. Será falado sobre a importância, quais arquivos precisam ser copiados, comandos
para backup e um esquema para controle das cópias de backup.
Existem duas formas para fazer o Backup do banco de dados. Uma forma é utilizar os
comandos do sistema operacional (cpio, tar, BACKUP/RESTORE, etc) e outra é utilizar o
comando probkup do PROGRESS. Neste capítulo, vamos falar sobre as duas formas.
Aconselhamos a você começar a usar os comandos do seu sistema operacional, que você já
está familiarizado. Estude os comandos do PROGRESS e se achar melhor use-os.
4. Multi-Volume
Este capítulo explica o que é multi-volume, quando usar e como transformar um banco em
multi-volume.
5. After-Image
Neste capítulo será explicado o que é o processamento after-image (imagem posterior), que
pode usado em um banco de dados. O after-image serve para proteger seu banco de dados em
caso de perda do disco em que ele se localiza. Depois de voltar o backup, você poderá ter as
informações atualizadas até o momento em que ocorreu o erro no disco.
Será explicado, também, como funciona o processamento before-image (imagem anterior) e a
diferença entre os dois.
Mostraremos a sintaxe dos comandos para usar o after-image, bem como alguns exemplos.
1.1. PROGRESS
Este capítulo apresentará uma visão geral de todo o ambiente e dos componentes da
base de dados PROGRESS. Os mecanismos da base de dados são extremamente importantes
para uma boa performance das aplicações desenvolvidas em ambiente PROGRESS. Para cada
um dos principais ambientes operacionais onde precise-se armazenar dados, a PROGRESS
desenvolveu uma robusta estrutura de banco de dados. Atualmente, é possível encontrar
aplicações rodando em bancos de dados com dezenas de gigabytes de dados armazenados e
milhões de processos sendo executados semanalmente. Portanto, é importante conhecermos
os princípios básicos das estruturas que o PROGRESS utiliza para armazenar e manipular, de
forma clara e segura, as informações armazenadas em seus bancos de dados e em diferentes
plataformas.
É importante mencionar que o banco de dados físico é, naturalmente, de extrema
importância quando da escolha da plataforma em que o banco irá trabalhar. As escolhas
típicas de plataformas de hardware incluem muitos dos sistemas UNIX, incluindo SCO, HP,
NCR, RS6000, VMS, IBM AS400, e servidores de redes Novell. O banco de dados nativo da
PROGRESS executa as mesmas funções lógicas indiferente da plataforma, sendo o mesmo
executável para cada tipo de plataforma. Isto garante que a estrutura tirará máximo proveito
da plataforma na qual esta rodando. Por exemplo, uma liberação de espaço de memória em
ambiente VMS , certamente não será idêntica em uma Novell, contudo a estrutura de base de
dados correspondente será montada apropriadamente.
1.2. Estrutura do Banco de Dados
A figura a seguir, mostra os principais componentes da estrutura de banco de dados
PROGRESS.
Base de Dados
Memória
Compartilhada
CPU
Processo Intermediário
Servidor do Banco de Dados
Cliente Remoto Cliente Self Service
Bases de dados
Físicas
A seguir, uma introdução aos componentes da estrutura de banco de dados PROGRESS.
1.2.1. Extensões do Banco de Dados
Estas são entidades físicas separadas, cada uma contendo uma parte da base de dados,
permitindo que vários dispositivos compartilhem a carga de acesso ao banco de dados. De
forma mais simples, isto significa que a base de dados pode ser dividida em seções de dados,
cada qual sendo uma extensão do banco. Cada uma destas partes pode residir em qualquer
parte da estrutura de disco. Desta maneira, os drives, controladores, e todos os outros recursos
do sistema podem compartilhar a carga do acesso ao banco de dados.
1.2.2. Base de Dados
Esta entidade lógica é referenciada por cada programa que acessa a base de dados. A
localização física e a configuração da base de dados permanece transparente ao código que
esta requisitando os seus dados. De fato, quando fazemos uso do Data Servers para bases de
dados externas , cada tipo de banco de dados (PROGRESS, Oracle, etc.) é transparente ao
código.
1.2.3. Processo do Servidor do Banco de Dados
O processo do servidor serve aos clientes do banco de dados (usuários). Isto inclui os
clientes locais auto-servidores (no mesmo hardware que o banco de dados, ou host-based), e
clientes remotos que podem solicitar múltiplos servidores para manipular suas requisições
acumuladas.
1.2.4. Processo Broker do Banco de Dados
O processo broker está relacionado aos clientes remotos cujos processos residem em
um sistema separado do sistema onde contém o processo broker e o processo de servidor. É
responsável por reconhecer o acesso deles ao banco de dados e iniciar processos de servidor
quando necessários. Note que os clientes remotos não necessariamente são clientes tipo "dial-
in". Por exemplo, dois sistemas UNIX podem estar conectados e enquanto o sistema #1
possui os processo do banco de dados, o sistema #2 pode receber entradas de usuários no
banco de dados e na aplicação.
1.2.5. Cache do Banco de Dados
Os blocos do banco de dados são lidos nesta área da memória e guardá-los tanto
quanto possível para que as leituras subseqüentes para os mesmos dados sejam somente
baseadas na memória, oposto ao baseado em disco (ligado diretamente a performance).
1.2.6. CPU
A CPU está envolvida pesadamente em facilitar todo o processo e é essencial à
performance e acesso ao sistema. O CPU agiliza os processos do servidor do banco de dados
e o broker do banco de dados tão bem quanto seus processo normais.
1.3. DataServer
A próxima seção discute DataServers para mostrar como você poderá acessar bancos
de dados não-PROGRESS transparentemente. Transparentemente, significa que o código
funcionará da mesma maneira, independente do banco de dados usado.
A figura a seguir, apresenta o funcionamento do DataServer.
Base de Dados
CPU
Processo Intermediário
Servidor do Banco de Dados
Cliente Remoto
Memória
Compartilhada
Cliente Self Service
Bases de dados
Físicas
DataServer
Schema Holder
1.3.1. Schema Holder
É um banco de dados PROGRESS vazio que mapeia campos, tabelas, indexes, e todos
os objetos externos em formatos PROGRESS. O programas conectam ao schema holder
como se este possuísse dados (mas, fisicamente não possui); o DataServer então, serve dados
dos bancos de dados externos para a estrutura do PROGRESS. É interessante notar que o
DataServer PROGRESS é atualmente um cliente para um banco de dados externo.
Agora você possui as informações básicas sobre a estrutura do banco de dados, que
permitirá a você compreender completamente o desenvolvimento de uma aplicação de
alcance empresarial. O conceito de uma estrutura de banco de dados verdadeira é peculiar
para alguns que já tenham trabalhado em ambientes como dbase ou clipper. Nestes casos, não
existe uma estrutura verdadeira funcionando. Ao invés, o executável da aplicação (.exe)
contém o mecanismo que solicita e gerencia os dados.
1.4. Limites do PROGRESS
O banco de dados PROGRESS possui suas limitações. Entre elas podemos citar:
1.4.1. Banco de dados
Tamanho do Bloco Tamanho Máximo do Banco
512 bytes 32 GB
1024 bytes 64 GB
2048 bytes 128 GB
4096 bytes 256 GB
Obs.: O tamanho do Bloco do Banco de Dados em HP-UX é 1024 bytes.
1.4.2. Elementos do Banco de Dados
Elemento Limite
Tabela Equivale ao tamanho máximo do banco de dados
Índice Depende do tamanho do bloco.
Tamanho do Bloco Número máximo de índices
512 2048
1024 4096
2048 8192
4096 16384
Não existe limite físico específico por tabela.
Entrada de
índice
Máximo de 16 campos por índice. O tamanho total para cada índice é cerca
de 188 caracteres por índice.
Registro Até 32 K por registro. Na prática, devido ao tamanho da pilha e de buffer,
reduz-se a 15 Kb.
Atributo Limitado pelo tamanho do registro
Lock de
Registro
Dependente do valor do parâmetro -L (Lock table)
Worktable Tamanho mínimo é 64 bytes. Está limitado pela memória disponível no
sistema.
Existe também um limite do tamanho do arquivo físico para o sistema operacional.
Este tamanho é limitado pelo sistema operacional. Em DOS, é 8 Mb (por motivos de
performance) e na maioria dos UNIX é 2 GB. Para possuir um banco maior mais que o
especificado pelo sistema operacional, deve utilizar banco de dados em multivolume.
1.5. Sistemas Operacionais
O PROGRESS suporta vários tipos de sistemas operacionais, os quais podemos
classificar em sistemas de memória compartilhada e sistemas de memória não compartilhada.
Sistemas de Memória Compartilhada Os sistemas de memória compartilhada usam uma área
de memória compartilhada para suportar múltiplos
usuários concorrentemente. Estes incluem UNIX,
Windows NT, VMS e OS/2.
Sistemas de Memória não-
compatilhada Suportam somente um usuário concorrentemente. Estes
são os sistemas baseados em DOS e Windows. Com
sistemas cliente/servidor, você poderá suportar
múltiplos usuários remotos.
1.6. Modos de Conexão
O PROGRESS possuem dois modos de conexão, que controlam quantos usuários
podem acessar a base de dados simultaneamente.
Modo Monousuário Somente uma sessão PROGRESS pode acessar o banco
de dados especificado por vez. Se o banco de dados
estiver em uso por outro usuário, você não conseguirá
conectar com este banco.
Somente utilize modo monousuário quando um usuário
necessitar acessar a base de dados, ou executar
programas para criar ou alterar um grande número de
registros em uma única transação. Também utilize
modo monousuário quando for fazer alguma alteração
no dicionário de dados.
Modo Multiusuário Múltiplas sessões podem acessar o banco de dados
simultaneamente. Um processo de servidor coordena
todos os acessos ao banco de dados de todos os
usuários.
Tanto em modo monousuário como em multiusuário, pode-se acessar o banco de
dados em modo interativo (on-line) ou de modo batch.
Modo interativo O usuário interage diretamente com o PROGRESS
Modo Batch O processamento ocorre sem a interação com o usuário.
Este modo é muito utilizado quando em operações de
atualização de larga escala, ou programas que executam
a noite sem o auxílio do usuário. Observe que processos
em batch quando em multiusuário degradam a
performance de processo on-line.
1.7. Localização do Banco de Dados
O PROGRESS suporta banco de dados local e remoto.
Banco de dados Local O banco de dados está localizado na mesma máquina onde
está a aplicação, ou sessão do PROGRESS.
Banco de dados Remoto O banco de dados está localizado na rede, desde que a
máquina onde esta sendo executada a aplicação também
esteja na mesma rede.
Para banco de dados remoto, podemos citar bancos de dados distribuídos, que nada
mais são do que várias bases de dados distribuídas através da rede. Podendo ser um ou mais
bancos de dados por máquina.
1.8. Cliente / Servidor
Em um ambiente cliente/servidor, o cliente e o servidor são processos separados. Cada
servidor pode suportar múltiplos usuários. Os processos clientes são, normalmente, locais.
Estes clientes solicitam dados ao servidor , que acessa o banco de dados, procura os dados e
os retorna para os clientes. Para exemplificar, veja a figura abaixo:
ClienteClienteCliente
Servidor Banco de Dados
Conexão
Remota
Conexão
Local
2.1. Parâmetros
Existem vários parâmetros que você informa ao PROGRESS. Estes parâmetros tem as
mais diversas funções, podendo, por exemplo, dizer ao PROGRESS, o quanto de memória ele
vai usar da máquina, em qual diretório ele deve gravar arquivos temporários, etc.
Estes parâmetros estão explicados a seguir:
Blocos no Buffer do Banco de Dados (-B)
Sintaxe UNIX
NT
DOS
OS/2
-B n
VMS /BUFFERS=n
Máximo 500.000
Mínimo 10
Padrão (8 * número de
usuários)
• n - número de blocos no buffer do banco de dados. Cada bloco tem a área de um bloco do disco - 512
bytes em DOS, OS2 e VMS, 1024 na maioria dos sistemas UNIX (2048 em alguns). Aumentando este
parâmetros mais blocos do banco ficarão em memória aumentando a performance.
Use este parâmetro para alocar memória para armazenar registros do banco de dados
em memória. Cada vez que um programa acessar um registro do banco, o PROGRESS
verifica se este registro já não está em memória e não haverá necessidade de ler do disco.
Geralmente, o valor do -B é 3% do tamanho do banco. (Ex.: BANCO: 100MB -B:3)
Número de Cursores de Índice (-c)
Sintaxe UNIX
DOS
Windows
OS/2
-c n
VMS /INDEX_CURSORS=n
Máximo
Mínimo
Padrão (4 * número de
usuários)
• n - número de cursores de índice permitidos. Cada vez que um programa PROGRESS acessar um
arquivo para uma leitura seqüencial será usado cursor de índice. Cada cursor usa 64 bytes. Se este
número estiver baixo o PROGRESS mostra a seguinte mensagem:
SYSTEM ERROR: Too few index cursors. Increase -c parameter.
Formato da Data (-d)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-d formato
VMS /DATE_FORMAT=formato
Padrão dmy
• formato - Formato da data que você quer ver ao executar o MAGNUS. Este formato é a combinação
das três letras: d (dia), m (mês), y (ano). O padrão é DIA/MÊS/ANO (dmy).
Área do Diretório de Programas (-D)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-D n
VMS /COMPILED_FILE_DIRECTORY=n
Máximo 500
Mínimo 5
Padrão 36
• n - Número de programas e includes que podem ser abertos ao mesmo tempo.
Cada programa executado durante uma sessão PROGRESS ocupa uma entrada de
diretório. Cada programa ao ser compilado usa uma entrada de diretório, bem como cada um
de seus includes. Se você receber a seguinte mensagem este parâmetro deverá ser aumentado:
SYSTEM ERROR: Too few directory entries: Increase -D parameter.
Formato Numérico Europeu (-E)
Sintaxe UNIX
DOS
Windows
OS/2
-E
VMS /NUMERIC_FORMAT=EUROPEAN
Padrão -E
Este parâmetro deve ser usado para indicar ao PROGRESS para interpretar os campos
decimais no formato europeu. Se não tiver este parâmetro, será usado o formato Americano.
Veja o exemplo a seguir:
Formato Europeu..: 191.065,00
Formato Americano: 191,065.00
Número de Entradas na Tabela de Bloqueio (-L)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-L n
VMS /LOCK_TABLE=n
Máximo depende S.O.¹
Mínimo 32
Padrão 500,00
¹ Limitado pela disponibilidade de memória e pelos parâmetros de memória compartilhada
• n - Número de entradas na tabela de bloqueios
Cada registro acessado em multiusuário usa uma entrada nesta tabela. Você precisa
aumentar o valor deste parâmetro se você ver a seguinte mensagem durante a execução de um
programa:
SYSTEM ERROR: Record lock table too small. Increase -L parameter.
Se você aumentar o valor do -L e o problema persistir entre em contato com a
DATASUL, pois talvez o programa no qual vem ocorrendo o problema precise ser
reestruturado.
Neste erro somente o programa será cancelado, mas o servidor do banco continuará
operando. Cada entrada nesta tabela usa 14 bytes no DOS e nos outros sistemas sem memória
compartilhada, e nos sistemas com memória compartilhada usa 18 bytes.
Utilizar sempre múltiplos de 32 para o valor do -L.
Número máximo de clientes por servidor (-Ma)
Sintaxe UNIX
NT
OS/2
-Ma n
VMS /MAXCLIENTS=n
Máximo 2048
Mínimo 1
Padrão 5
usuário/servidor
• n - Número máximo de usuários remotos (clientes) por servidor.
Os parâmetros -Mn, -Ma e -Mi são usados em sistemas com memória compartilhada e
que vão ter o banco acessado por usuários remotos.
Este parâmetro indica quantos usuários remotos poderão acessar um servidor.
Atraso na Gravação do Arquivo .bi (-Mf)
Sintaxe UNIX
NT
OS/2
-Mf n
VMS /TRANSACTION_DELAY=n
Máximo 32768
Mínimo 0
Padrão 0¹ ¹ O padrão é 3 para sistemas que usam memória compartilhada.
• n - Número de segundos que o PROGRESS vai atrasar na gravação das transações do arquivo before-
image (.bi).
Este parâmetro pode ser usado para melhorar a performance em sistema muito
carregado. Ele faz com que o PROGRESS não grave imediatamente a transação no arquivo
before-image, com isto você economiza algumas gravações no arquivo before-image. Isto não
significa que seu banco ficará sem integridade. Quando ocorrer um erro do sistema você
poderá perder além da última transação incompleta, outras transações que foram completadas
neste período de atraso que você determinou.
Este parâmetro também pode ser usado em monousuário.
Número mínimo de clientes por servidor (-Mi)
Sintaxe UNIX
NT
OS/2
-Mi n
VMS /MINCLIENTS=n
Máximo
Mínimo 1
Padrão 1
• n - Número de usuários remotos (clientes) num servidor antes de ser iniciado um novo servidor (até o
número máximo de usuários por servidor - parâmetro -Ma).
Os parâmetros -Mn, -Ma e -Mi são usados em sistemas com memória compartilhada e
que vão ter o banco acessado por usuários remotos.
Assim que o usuário remoto acessa o banco, é iniciado um servidor para ele. Este
servidor será iniciado a cada n usuários até o máximo de servidores (especificado pelo
parâmetro -Mn). Por default, um novo servidor é iniciado para cada um dos primeiros 4
usuários remotos. Os próximos usuários serão distribuídos entre estes servidores até que seja
alcançado os parâmetros -Mn ou -Ma.
Número máximo de servidores (-Mn)
Sintaxe UNIX
NT
OS/2
-Mn n
VMS /MAXSERVERS=n
Máximo 512
Mínimo 1
Padrão 4
• n - Número máximo de servidores para clientes remotos que podem ser inicializados pelo servidor
local..
Este parâmetro é necessário para sistemas operacionais que usam memória
compartilhada e que o banco de dados será acessado por usuários remotos. Normalmente, o
banco é acessado por usuários locais, mas em certas configurações você pode colocar o
banco em um equipamento e este banco será acessado por usuários que estão em um outro
equipamento conectado via rede (TCP/IP, DECNET, etc), ou seja, usuários remotos.
Quando o usuário remoto vai acessar o banco através da rede o servidor do banco inicia
um outro servidor para este usuário remoto (também conhecido por client). Você pode
especificar o número máximo de servidores que podem ser inicializados (através deste
parâmetro -Mn), o número máximo de usuários por servidor (-Ma) e o número mínimo de
usuários por servidor (-Mi).
Exemplo de uso dos parâmetros -Mn, -Ma e -Mi
Suponha que você terá 40 usuários remotos para acessar um banco na sua máquina e
você definiu os seguintes parâmetros:
Exemplo 1) -Mn 10 -Ma 4 -Mi 1
Os 10 primeiros usuários remotos terão um servidor cada um, pois o número mínimo
de usuários por servidor é 1. Os usuários seguintes serão divididos entre estes 10 servidores.
Cada servidor poderá servir até 4 usuários.
Exemplo 2) -Mn 10 -Ma 4 -Mi 3
Neste caso o PROGRESS vai iniciar um servidor a cada 3 usuários. Assim que atingir
10 servidores, o PROGRESS vai distribuir os usuários entre os servidores iniciados. Esta
configuração é melhor que a primeira.
Número de Usuários (-n)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-n n
VMS /NUMBER_OF_USERS=n
Máximo 2048
Mínimo 1
Padrão O valor máximo pode ser menor se sua máquina não estiver rodando Unix System 5, mas este valor
será no mínimo 10.
Depende do equipamento: UNIX System 5: 20
Pyramid: 50
Openet: 64
MS-DOS: 20
Outros: 10
• n - O número máximo de usuários no banco de dados. Após este número ser alcançado, outros usuários
não vão conseguir iniciar sessão neste banco de dados.
Em sistemas que não tem memória compartilhada, use este parâmetro para limitar o
número de usuários para o servidor do banco. Em sistemas com memória compartilhada, -n
deve incluir usuários locais e remotos.
Impressora (-o)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-o impressora
VMS /PRINTER=impressora
Padrão lp -s¹
¹ Este é o padrão para o sistema UNIX.
• impressora - Identifica a impressora padrão para o PROGRESS.
Veja o capítulo sobre Impressoras neste manual para obter maiores informações sobre
este parâmetro e como configurar impressoras no MAGNUS.
Programa Inicial (-p)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-p programa
VMS /STARTUP=programa
Padrão menu.p
• programa - nome do programa que deve ser executado ao iniciar o PROGRESS.
Arquivo de Parâmetros (-pf)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-pf arquivo
VMS /PARMFILE=arquivo
• arquivo - Nome de um arquivo do sistema operacional que contêm parâmetros. Este arquivo deve ter a
terminação .pf e pode ser criado usando-se um editor de textos formato ASCII.
Este arquivo é útil quando você tem muitos parâmetros na linha de comando,
especialmente em DOS onde o tamanho máximo da linha de comando é 128 bytes.
Você pode agrupar neste arquivo todos os parâmetros que pretende usar e indica através
deste parâmetro a localização do mesmo. No MAGNUS, cada banco tem seu próprio arquivo
de parâmetros (i00adm.pf, i00ind.pf e i00com.pf).
Você pode usar mais de um arquivo de parâmetros ao mesmo tempo na linha de comandos.
Pedido Rápido (-q)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-q
VMS /QUICK_REQUEST
Padrão
Ao executar um programa, o PROGRESS procura por este programa no PROPATH1.
Ao encontrar o programa, o PROGRESS verifica se ele não foi alterado procurando pelo
fonte deste programa. Isto é útil num ambiente de desenvolvimento, mas para o usuário final
isto pode ser evitado usando-se este parâmetro.
O uso deste parâmetro tende a melhorar a performance, pois, o PROGRESS só vai
pesquisar o PROPATH no primeiro uso do programa.
1 Veja no capítulo 2 informações sobre PROPATH.
Modo de Compilação de Programas (-rx)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-rx
VMS /XCOMPILER
Este parâmetro é usado somente no script libera e é explicado adiante no tópico
Compilação de Programas. Este parâmetro serve para compilar programas criptografados
(formato que a DATASUL envia os programas para compilação nos clientes) e para quando
precisar fazer alguma alteração nas definições do dicionário de dados. Em situação normal
você não precisa usar este parâmetro.
Nome do Servidor (-S)
Sintaxe UNIX
DOS
Windows
OS/2
-S nome-do-servidor
VMS /SERVICE=nome-do-servidor
• nome-do-servidor - um nome para o servidor do PROGRESS.
Esta opção poderá ser usada em dois casos: quando iniciando um servidor que vai ser
acessado por usuários remotos, ou quando usando o PROGRESS como usuário remoto. Neste
caso, o nome do servidor deve ser o mesmo nos dois casos.
Em redes Novell usando NLM será necessário criar um nome de servidor para cada um
que você carregar. E para cada usuário que for acessar o servidor do banco deverá ter também
o -S. Por exemplo: coloque o nome do servidor do i00adm como si00adm, o i00ind como
si00ind e o f00com como si00com.
Diretório para Arquivos Temporários (-T)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-T diretório
VMS /TEMPORARY_FILES=diretório
Padrão O Home Directory
do usuário
• diretório - Nome do diretório para o PROGRESS gravar arquivos temporários.
Se não for informado este parâmetro, o PROGRESS grava os arquivos temporários no
diretório corrente. Em UNIX, VMS e OS2 estes arquivos começam por lbi, pge, srt e trp e
terminam com o número do processo da sessão PROGRESS. Em DOS, estes arquivos tem o
mesmo prefixo mas, terminam com 5 caracteres de preenchimento.
Se você estiver usando LAN DOS, é possível que vários usuários usem o mesmo
diretório temporário e os mesmos arquivos temporários. Isto pode gerar conflito. Se isto
estiver ocorrendo você pode receber a seguinte mensagem:
• Sob o IBM PC Network:
Unable to open or create mgadm.srt, error 3
• Sob NOVELL NetWare:
Network error: file in use during CREATE A FILE.
File = mgadm.srt
Abort, Retry, Fail ?
Neste caso para cada usuário você deve definir um diretório de trabalho diferente. Isto
pode ser feito da seguinte maneira:
1. no script MAGNUS.BAT coloque o parâmetro -T %TEMP%
2. defina no AUTOEXEC.BAT de cada usuário o valor da variável TEMP com o comando set
TEMP=C:\TMP1, por exemplo.
3. Assim, quando o usuário executar o MAGNUS.BAT a variável TEMP estará apontando para um
diretório diferente.
Classificação Rápida (-TB)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-TB n
VMS /TBLOCKS=n
Máximo 31
Mínimo 1
Padrão 2
• n - Número de blocos (em 1024 bytes) que você deseja alocar quando o PROGRESS for fazer uma
classificação (sort) de registros ou quando for reindexar índices2. O default é 2 KB mas pode estar em
qualquer valor na faixa de 1 a 31 KB.
Este parâmetro é usado para melhorar a performance quando for feita uma classificação
de registros (sort).
Para fazer uma classificação de registros o PROGRESS usa a memória (valor do -TB),
mas a partir do momento que não tem memória para isto, ele vai gravando num arquivo de
trabalho. Então, se for um tamanho maior, mais memória você vai ter para estas
classificações.
2 Veja adiante o tópico Reindexação do Banco de Dados.
Número de Merge (-TM)
Sintaxe UNIX
NT
DOS
Windows
OS/2
-TM n
VMS /MERGE_NUM=n
Máximo 32
Mínimo 1
Padrão 5
• n - Número de blocos que podem ser simultaneamente unidos durante o processo de classificação.
Incremente este parâmetro para melhorar a performance durante um processo de
classificação (Este parâmetro implica no uso de mais memória da máquina).
Nome Físico do Banco de Dados (-db)
Sintaxe UNIX
DOS
NT
Windows
VMS
OS/2
-db nome-banco
• nome-banco - Nome físico do banco de dados. Pode ser incluído o nome do diretório também.
Este parâmetro é utilizado na hora que você conectar um banco no PROGRESS. Ele
indica a localização física do banco de dados. Atenção: Não confunda o nome físico de um
banco com o nome lógico (parâmetro -ld).
Nome Lógico do Banco de Dados (-ld)
Sintaxe UNIX
DOS
Windows
OS/2
-ld nome-lógico
VMS /LOGICAL_DBNAME=nome-lógico
• nome-lógico - Nome lógico do banco de dados.
Este parâmetro se utiliza na hora que você conectar um banco no PROGRESS, e
compilar um programa nesta base de dados. Portanto, caso você mude o nome físico do
banco, o nome lógico deve permanecer o mesmo, senão os programas compilados antes da
alteração não poderão rodar.
Acesso em Monousuário (-1)
Sintaxe UNIX
DOS
NT
Windows
OS/2
VMS
-1
Este parâmetro é utilizado, caso você deseje acessar um banco PROGRESS em monousuário.
Nome do Arquivo de After-Image (-a)
Sintaxe UNIX
DOS
NT
Windows
OS/2
-a nome-arquivo
VMS /AFTER_IMAGE=nome-arquivo
• nome-arquivo - Nome do arquivo que indica o local do after-image.
Este parâmetro deverá ser usado quando você estiver trabalhando com after-image.
Veja neste manual e no manual Progress System Administration Guide, o capítulo que fala
sobre o Processamento after-image.
Nome do Arquivo Before-Image (-g)
Sintaxe UNIX
DOS
NT
Windows
OS/2
-g nome-arquivo-bi
VMS /BEFORE_IMAGE=nome-arquivo-bi
• nome-arquivo-bi - Nome do arquivo do before-image.
Um banco de dados é composto por três arquivos. Por exemplo, para o banco i00adm,
você terá o arquivo i00adm.db, i00adm.bi e i00adm.lg. O arquivo .bi é usado pelo
PROGRESS para processamento de transações.
Por default, o PROGRESS considera que este arquivo está no mesmo diretório do
banco de dados (arquivo .db). Mas, algumas vezes, você pode colocar este arquivo em um
outro disco para ganhar performance, sendo então necessário especificar neste parâmetro
onde está o arquivo .bi do banco.
Por exemplo, você instalou o MAGNUS no diretório /usr/MAGNUS mas, depois
moveu o arquivo .bi do mgadm para o diretório /disco1/MAGNUS. No arquivo mgadm.pf
deverá ter a seguinte linha para indicar que o .bi está neste outro diretório:
-g /disco1/MAGNUS/i00adm.bi
Nome do Usuário do Banco (-U)
Sintaxe UNIX
DOS
NT
Windows
OS/2
-U nome-usuário
VMS /USER=nome-usuário
• nome-usuário - Nome do usuário que você pretende setar como usuário ativo no banco de dados.
Dentro de cada banco de dados existe o controle de usuários e senhas. Este controle é
feito pelo PROGRESS. Se você desejar definir um usuário padrão para o banco pode ser
informado neste parâmetro. O usuário deverá ter sido previamente cadastrado no banco. Veja
neste manual o capítulo sobre Segurança para maiores detalhes. Neste parâmetro, você
informa o Usuário veja o parâmetro -P a seguir que indica como informar a senha.
Senha do Usuário do Banco (-P)
Sintaxe UNIX
DOS
NT
Windows
OS/2
-P senha
VMS /PASSWORD=senha
• senha - Senha do usuário (parâmetro -U) que você pretende setar como usuário ativo no banco.
3.1. Importância
Entende-se por Backup as cópias que são feitas de um conjunto de arquivos em outro
dispositivo magnético, para o caso da perda do original, ter uma cópia de segurança. Esta
perda pode ser ocasionada por algum problema na máquina. Algumas vezes, você pode fazer
algum teste no banco, não obter o resultado desejado e resolva voltar a cópia antiga, etc.
Enfim, é sempre importante que você tenha uma cópia de segurança do seu banco de dados.
Temos exemplos de clientes que perderam trabalhos de uma semana por não terem feito
backup neste período.
Não espere por uma oportunidade de descobrir por si mesmo a importância do Backup,
previna-se.
3.2. Do que deve ser feito Backup ?
Basicamente, no MAGNUS, você deve fazer backup da base de dados (todos os
bancos), dos programas executáveis (*.r) e dos utilitários diversos.
Os bancos do MAGNUS devem ser copiados sempre juntos, para que as
informações estejam sempre sincronizadas. A base de dados mínima do MAGNUS é
composta dos bancos de dados mgadm, mgind e mgcom. Cada um destes bancos possui,
originalmente, 3 arquivos: .db, .bi e .lg. Além, é claro dos arquivos de parâmetros .pf. Então,
faça o backup dos seguintes arquivos:
i00adm.db, i00adm.bi, i00adm.lg e i00adm.pf
i00ind.db, i00ind.bi, i00ind.lg e i00ind.pf
i00com.db, i00com.bi, i00com.lg e i00com.pf
E dos outros arquivos semelhantes para os outros banco de dados do MAGNUS que
você possui. No diretório em que foi instalado o MAGNUS você terá os sub-diretórios dos
programas dos módulos (exemplo: ctp é o diretório da Contabilidade). É bom que sempre se
faça cópia destes programas, para o caso de uma perda do disco, você não precise solicitar os
fontes criptografados para recompilar.
Os utilitários diversos são os scripts de inicialização do MAGNUS (smagnus,
MAGNUS e fmagnus), os arquivos que estão no diretório util, o script libera e instala, etc.
3.3. Qual mídia magnética utilizar para o Backup ?
Depende do equipamento que você está utilizando para rodar o MAGNUS. Existe por
exemplo, equipamentos que utilizam fita DAT, que tem capacidade para 2 GB, e pode
portanto armazenar todo o diretório do MAGNUS de uma só vez (banco, programas e
utilitários). Existe equipamento que só possui unidade de disquete. Neste caso, é interessante
separar o backup do banco em um jogo de disquetes, e dos programas e utilitários em outro. É
claro que, você pode também separar cada módulo dos programas em um jogo de disquetes
diferente. A mesma coisa para os bancos de dados (i00adm, i00ind e i00com).
3.4. Período de Backup
Para o backup do Banco de Dados é importante que seja feito diariamente. Veja o
tópico Exemplo de um Esquema de Backup.
Dos programas você pode fazer uma cópia semanal. Isto depende das novas versões
de programas que você recebeu.
E dos utilitários faça uma cópia sempre que alterar algum dos parâmetros dos scripts
(MAGNUS, smagnus, fmagnus, etc).
3.5. Backup Utilizando o Sistema Operacional
Você vai usar os comandos do seu sistema operacional para fazer backup da base de
dados, dos programas e utilitários. Opcionalmente, você pode usar o comando probkup do
PROGRESS para backup do banco. Veja o próximo tópico.
A seguir, damos exemplos dos comandos por sistema operacional.
3.5.1. Backup em DOS/OS2
Em DOS, normalmente, se usa o comando BACKUP para copiar os programas para
disquete e o comando RESTORE para voltar um cópia de backup.
Para fazer um backup do banco de dados mgadm execute o seguinte comando (posicione-se
no diretório do MAGNUS antes):
BACKUP I00ADM.* A:
Este comando deverá ser executado para cada um dos bancos (i00adm, i00ind e i00com).
Para fazer o backup dos programas do diretório cdp (Cadastros) execute:
BACKUP CDP A:/S
Neste exemplo, estamos supondo que a unidade de disquete é A:. O parâmetro /S indica pro
DOS copiar os sub-diretórios. Para cada diretório de programas execute este comando. No
capítulo 1. MAGNUS I.00 você tem a relação dos módulos.
Para retornar algum backup digite o comando:
RESTORE A: C:/S
Obs.: Veja a documentação do MSDOS para maiores detalhes sobre o comando BACKUP e
RESTORE.
3.5.2. Backup em UNIX
Neste sistema operacional sempre se usa o comando cpio. Para fazer um backup
usando este comando, precisaremos de um outro comando do sistema para gerar a lista de
arquivos a serem copiados. Vamos usar o comando find. A sintaxe será a seguinte:
find lista-arquivos -print | cpio -opcões > dispostivo
onde: lista-arquivos - nomes dos arquivos e/ou diretórios
opções - opções para gravação no cpio
dispositivo - dispositivo no qual será feito o backup
A seguir, temos um exemplo do backup dos bancos de dados num equipamento HP com fita
DAT.
find i00adm.* i00ind.* i00com.* -print | cpio -ovcB > /dev/rmt/0m
Este comando vai copiar a base de dados do MAGNUS para unidade de fita DAT.
O seguinte comando copia todo o conteúdo do diretório do MAGNUS para fita DAT.
find . -print | cpio -ovcB > /dev/rmt/0m
Posicione-se no diretório em que foi instalado o MAGNUS para fazer o backup.
Para retornar um backup também é usado o cpio. Exemplo:
cpio -iduvcB < /dev/rmt/0m
Este comando vai retornar da Fita DAT todos os arquivos que foram copiados previamente
com o cpio.
Veja na documentação do seu sistema operacional maiores informações sobre a
sintaxe do comando cpio, e sobre os dispositivos instalados, pois eles variam de equipamento
para equipamento (nos exemplos aqui, usamos /dev/rmt/0m).
3.5.3. Backup em VMS
Em VMS você poderá fazer backup usando o utilitário BACKUP. Veja a
documentação do seu sistema para maiores detalhes sobre este utilitário.
3.6. Backup utilizando probkup e prorest3
Para fazer backup do banco de dados você pode usar o comando probkup. Este
comando deve ser feito para um banco de dados de cada vez. Se você fizer um probkup do
banco i00adm, você não poderá usar este dispositivo (disquetes, fita DAT, fita streamer) para
os outros bancos. Cada banco deverá ter seu próprio dispositivo.
A vantagem deste comando com relação ao comando do sistema operacional é a seguinte:
• no comando do sistema operacional sempre é copiado o banco de dados completo.
• no probkup, você pode usar o backup incremental, ou seja, depois de um backup completo, pode ser
copiado somente o que foi alterado de um dia para o outro. Ainda, existe a possibilidade de se fazer
backup online com o probkup. Ou seja, pode ser feito backup durante o uso do MAGNUS.
Por exemplo, na segunda-feira a noite você faz um backup completo do banco de
dados. Se o banco tiver 100 MB, todos 100 MB serão copiados para a unidade de backup. Na
terça-feira a noite você faz o backup incremental, ou seja, só será copiado o que foi alterado
neste dia, que é menos que os 100 MB do dia anterior.
A seguir, temos um esquema típico usando o probkup completo e incremental (estes
backup são realizados a noite e para cada dia será usada uma mídia magnética diferente):
Segunda Terça Quarta Quinta Sexta
Fazer um
probkup
completo do
banco de
dados.
Probkup
incremental.
Só será
copiado as
alterações do
dia.
Probkup
incremental.
Só será
copiado as
alterações do
dia.
Probkup
incremental.
Só será
copiado as
alterações do
dia.
Fazer um
probkup
completo do
banco de
dados.
Se ocorrer algum problema com o banco de dados, deverá ser feito o seguinte, dependendo do
dia em que precise voltar o backup:
Segunda Terça Quarta Quinta Sexta
3 O comando probkup e prorest estão descritos, também, no System Administration Guide II do PROGRESS (Versão 6) e System
Administration Reference (Versão 7).
Voltar o
backup
completo de
Sexta.
Voltar o
backup
completo de
Segunda.
Voltar o
backup
completo de
segunda mais
o backup
incremental
de Terça.
Voltar o
backup
completo de
segunda mais
o backup
incremental
de Terça e
Quarta.
Voltar o
backup
completo de
segunda mais
o backup
incremental
de Terça,
Quarta e
Quinta.
Então, por exemplo, se ocorrer algum problema na quarta-feira e você precisar voltar
o backup, primeiro retorne o backup completo da segunda-feira e em seguida o backup
incremental da terça-feira. Adiante é mostrado como fazer isto.
Você pode ajustar o ciclo conforme suas necessidades. Mas, é importante não deixar
um espaço muito grande entre dois backup's completos. A PROGRESS recomenda pelo
menos um backup completo por semana.
3.6.1. Probkup Completo do Banco de Dados
A seguir, é mostrada a sintaxe do comando probkup para fazer um backup completo
(este programa está no sub-diretório probin no diretório em que você instalou o
PROGRESS):
Sistema Operacional Comando para Reindexar o banco de dados
DOS, UNIX, OS/2 probkup banco dispositivo [-vs n] [-bf n]
VMS PROGRESS/BACKUP[/SIZE=n][/BLOCKING_FATOR=n] banco
dispositivo
O banco é o nome que você deseja fazer o backup completo. No MAGNUS deverá ser
i00adm, i00ind ou i00com.
O dispositivo é o nome do dispositivo no qual será feito o backup. Depende do
sistema operacional. Veja os exemplos a seguir:
O parâmetro -vs (/SIZE) indica a capacidade em blocos do dispositivo que você está
gravando. O tamanho do bloco depende do sistema operacional (512 em DOS, OS2 e VMS, e
1024 na maioria dos sistemas UNIX). Este parâmetro é util por exemplo ao gravar em
disquete DOS.
O parâmetro -bf (/BLOCKING_FATOR) indica quantos blocos devem ser lidos para
memória antes de gravar no dispositivo. O tamanho do bloco também depende do sistema
(512 em DOS, OS2 e VMS, e 1024 na maioria dos sistemas UNIX).
3.6.2. Probkup incremental
O probkup incremental só poderá ser realizado após um probkup completo. A sintaxe do
comando é a seguinte:
Sistema Operacional Comando para Reindexar o banco de dados
DOS, UNIX, OS/2 probkup banco incremental dispositivo [-vs n] [-bf n] [-io n] [-
scan]
VMS PROGRESS/BACKUP/INCREMENTAL[/SIZE=n][/BLOCKING_FATOR=
n][/OVERLAP=n][/SCAN] banco dispositivo
A diferença da sintaxe do incremental para o completo é a seguinte:
• A inclusão da palavra incremental no comando.
• A opção do fator de overlap -io (/OVERLAP). Este parâmetro serve para o seguinte: se você usar o
fator de overlap 1, significa que será feito o backup das alterações do dia e também as alterações do
dia anterior. Fator 2 indica que além do backup das alterações do dia, também será feito backup dos 2
dias anteriores e assim por diante.
• A opção -scan (/SCAN) que calcula a área necessária para o backup incremental, já que não é
possível saber esta área antes do backup.
3.6.3. Probkup Online
O probkup online pode ser usado para fazer backup de um banco em uso. A sintaxe é
a seguinte:
Sistema Operacional Comando para Reindexar o banco de dados
UNIX, OS/2 probkup online banco incremental dispositivo [-vs n] [-bf n] [-
io n] [-scan]
VMS PROGRESS/BACKUP/ONLINE[/INCREMENTAL][/SIZE=n][/BLOCKIN
G_FATOR=n][/OVERLAP=n][/SCAN] banco dispositivo
Exceto pela opção online (/ONLINE) a sintaxe é a mesma do backup completo e
incremental. Você não poderá executar backup online nas seguinte situações:
• Em sistemas operacionais sem memória compartilhada, exemplo DOS.
• Quando o banco de dados estiver sendo usado em monousuário.
• Quando o after-image do banco estiver habilitado4
Enquanto outros modos de backup exigem que o banco não esteja em uso, o backup
online permite que se faça backup durante este uso. Entretanto, usando backup online pode
degradar a performance um pouco. Isto porque, quando o PROGRESS estiver copiando o
arquivo de before-image, você não poderá acessar o banco. Se o before-image estiver muito
grande, você poderá esperar até 30 segundos ou mais para o PROGRESS copiar o arquivo.
Quando for iniciar o backup online, certifique-se que o dispositivo esteja pronto
(disquete, fita, etc.) para o backup. Se não, o PROGRESS não vai poder gravar as
informações no dispositivo. Até o PROGRESS gravar estas informações, você não poderá
acessar o banco. Se você usar mais um volume para backup (exemplo, disquetes) haverá um
tempo de espera durante a troca dos volumes.
4 Veja neste Manual o capítulo sobre processamento After-Image.
Obs.: Backup criado com probkup online só poderá ser restaurado com utilitário prorest da
versão 6. Veja o tópico a seguir.
3.6.4. Restaurando Backup feito com o probkup (prorest)
Quando é feito um backup usando o probkup, você deve usar o comando prorest do
PROGRESS para restaurar o backup. Este programa se encontra no sub-diretório probin no
diretório em que foi instalado o PROGRESS.
A sintaxe do prorest é a seguinte:
Sistema Operacional Comando para Reindexar o banco de dados
DOS, UNIX, OS/2 prorest banco dispositivo
VMS PROGRESS/RESTORE banco dispositivo
banco é o nome do banco que você quer voltar o backup e dispositivo é o dispositivo
onde se encontra o backup. O prorest usa o mesmo fator de bloco que foi feita a gravação.
3.6.5. Regras importantes para restaurar backup incremental
Você deve restaurar na ordem em que foi feito o backup. Primeiro, restaure o backup
completo, seguido do primeiro backup incremental, seguido do segundo backup incremental e
assim por diante. Se você tentar restaurar um incremental fora de seqüência o PROGRESS
emite uma mensagem de erro e a operação é cancelada.
Se você perder a segunda cópia do incremental, mas usou o fator de overlap 1, então o
terceiro incremental vai restaurar corretamente os dados perdidos do segundo.
Após restaurar um backup completo, não atualize nada no banco, se você tiver mais backup
incremental a ser restaurado. Se você entrar no banco, todos os backup incrementais (ainda
não restaurados) vão ficar inválidos, até que você restaure tudo novamente, a partir do backup
completo.
Se ocorrer uma falha no sistema durante a restauração do banco, recomece a partir o
backup que você estava processando quando ocorreu a falha.
3.7. Exemplos de Uso do probkup e prorest
A seguir, vamos dar um exemplo de um backup do banco de dados i00adm nos
diversos sistemas operacionais. No exemplo o banco será sempre o i00adm, mas se você for
usar este modo de backup não esqueça que o processo deve ser repetido para os outros
bancos: i00ind e i00com. E também, a mídia magnética deve ser outra, uma para cada banco.
Os dispositivos que serão mostrados são apenas exemplos, verifique no seu
equipamento qual dispositivo você tem disponível bem como quantos blocos possui. Como
falamos anteriormente o tamanho do bloco depende do sistema, podemos citar 512 bytes para
DOS, OS2 e VMS, 1024 na maioria dos sistemas operacionais, etc.
Quando o backup for feito em dipositivo multi-volume (unidade de disquete) o
PROGRESS faz uma pausa para troca do disquete.
3.7.1. Exemplo de uso do probkup em DOS
Neste exemplo, vamos fazer um backup do banco i00adm para uma unidade de
disquete no drive a.
1. Na primeira vez que for fazer um backup completo, você pode executar o utilitário
prostrct5 para determinar quantos disquetes serão necessários para fazer o backup.
prostrct statistics i00adm
Este comando mostra o número de blocos que o banco de dados possui.
2. Execute o comando probkup para fazer o backup completo do banco:
probkup i00adm.db a:\i00adm -vs 708
Neste exemplo o dispositivo é o arquivo \i00adm no drive a. A opção -vs indica que a
área do disquete é 708 * 512 = 362249 bytes (512 = tamanho do bloco em DOS). Por default
o fator de bloco é 30. A seguinte tela mostra o relatório gerado quando o backup inicia:
Na mensagem acima, o PROGRESS diz que é necessário 163 blocos para backup e
302 blocos para restaurar o banco. Esta diferença ocorre porque o PROGRESS compacta os
dados antes do backup.
3. Após executar o backup completo você pode executar o probkup incremental.
probkup i00adm.db a:\i00adm1 incremental -vs 708 -bf 50
Neste exemplo, o dispositivo de saída é o arquivo \i00adm1 no drive a. O fator de bloco
é 50 e a seguinte tela indica o relatório gerado.
Já que não foi usada a opção -scan o PROGRESS não pode determinar quantos blocos
serão usados para o backup.
5 Você tem maiores informações sobre o prostrct no capítulo so bre after-image.
i00adm requires a total of 163 blocks (83456 bytes) of backup media.
3 of those blocks will then be free.
160 out of 160 active data blocks will be dumped.
mgadm requires a minimum of 302 (154624 bytes) blocks to restore.
The bi file requires a total of 128 blocks (65536 bytes) of full
backup media.
i00adm requires an unknown amount of bytes for backup media.
4. Para retornar o backup do banco i00adm você usa o prorest. Você pode retornar como
i00adm ou dar um novo nome para o banco, neste caso deverá ser alterado o parâmetro -db no
arquivo .pf6.
prorest i00adm.db a:\i00adm
Você deverá ter um relatório na tela parecido com este.
5. Para retornar o backup incremental use o comando prorest indicando o nome do banco e o
dispositivo.
prorest i00adm.db a:\i00adm1
A seguinte tela mostra o relatório gerado:
3.7.2. Exemplo de uso do probkup em UNIX
1. Na primeira vez que for fazer um backup completo, você pode executar o utilitário
prostrct7 para determinar quantos blocos serão necessários para fazer o backup.
prostrct statistics i00adm
Este comando mostra o número de blocos que o banco de dados possui.
2. Execute o comando probkup para fazer o backup completo do banco:
6 No capítulo 3. Administração vocè tem informações sobre os parâmetros de banco. 7 Você tem maiores informações sobre o prostrct no capítulo sobre after-image.
Processing volume 1.
a:\i00adm is a full backup of i00adm.db
This backup was taken on Wed Feb 10 20:30:00 1993
It will require a minimum of 38 blocks to restore.
Processing volume 1.
a:\i00adm1 is a incremental backup of i00adm.db
This backup was taken Fri Feb 13 20:30:10 1993
It is based on the full backup of Wed Feb 10 20:30:00 1993
It will require a minimum of 38 blocks to restore.
i00adm requires a total of 163 blocks (166912 bytes) of
full backup media.
NO BACKUP HAVE BEEN DONE.
Total number of allocated blocks = 79
Total number of allocated blocks that are free: 22
Total number of allocated blocks that are used: 57
probkup i00adm.db /dev/rmt/0m -vs 4000 -bf 20
Neste exemplo o dispositivo é o /dev/rmt/0m. A opção -vs indica que a área do dispositivo é
4000 * 1024 = 4000 Kbytes. O fator de bloco é 20. A seguinte tela mostra o relatório gerado
quando o backup inicia:
3. Após executar o backup completo você pode executar o probkup incremental.
probkup i00adm.db /dev/rmt/0m incremental -vs 4000 -bf 50
Neste exemplo, o dispositivo de saída é o /dev/rmt/0m. O fator de bloco é 50 e a seguinte tela
indica o relatório gerado.
4. Para retornar o backup do banco i00adm você usa o prorest. Você pode retornar como
i00adm ou dar um novo nome para o banco, neste caso deverá ser alterado o parâmetro -db no
arquivo .pf8.
Você deverá ter um relatório na tela parecido com este.
prorest i00adm.db /dev/rmt/0m
3.7.3. Exemplo de uso do probkup em VMS
1. Como será feito um backup completo, podemos usar o utilitário de estatísticas para saber
quanto de área o banco possui. Execute o comando:
PROGRESS/STRUCTURE/STATISTICS i00adm
Este comando mostra o número de blocos que o banco possui9.
2. Use o seguinte comando para fazer o backup completo:
PROGRESS/BACKUP/BLOCKING_FATOR=20/SIZE=4000 i00adm dispositivo
8 No capítulo 3. Administração você tem informações sobre os parâmetros de banco. 9 Você tem maiores informações sobre o prostrct no capítulo sobre after-image.
i00adm requires a total of 64 blocks (65536 bytes) of backup media.
3 of those blocks will then be free.
61 out of 61 active data blocks will be dumped. i00adm requires a minimum of 64 (65536) blocks to restore.
i00adm requires a total of 64 blocks (65536 bytes) of backup media.
3 of those blocks will then be free.
61 out of 61 active data blocks will be dumped.
i00adm requires a minimum of 64 (65536) blocks to restore.
Neste exemplo, o dispositivo de backup deverá ser informado em dispositivo. /SIZE
indica que o dispositivo de backup possui 4000 blocos de área. A seguinte tela surgirá quando
for iniciado o backup completo:
3. A seguir, temos o comando para executar backup incremental no banco:
PROGRESS/BACKUP/INCREMENTAL/BLOCKING_FATOR=20/SIZE=4000
i00adm dispositivo
4. Para retornar o backup do banco i00adm você usa o prorest. Você pode retornar como
i00adm ou dar um novo nome para o banco, neste caso deverá ser alterado o parâmetro -db no
arquivo .pf.
PROGRESS/RESTORE i00adm dispositivo
3.8. Exemplo de um esquema de Backup do Banco de Dados
Neste tópico damos um exemplo de um esquema para controle de backup. Caso você
for utilizar este esquema com o comando probkup do PROGRESS, aconselhamos a usar
sempre backup completo para cada dia e assim evitar confusão com backup incremental.
O uso deste esquema exige disciplina, mas é um esquema muito seguro para controle
do backup. A rotina de backup do seu banco de dados deve ser efetuada utilizando os
seguintes discos:
- A = Banco de Dados em uso
- B = Cópia Diária Número 1
- C = Cópia Diária Número 2
- D = Cópia Diária Número 3
- E = Cópia Semanal
- F = Cópia do Período (Mês)
O procedimento de cópia é o seguinte:
Segunda-Feira --> Copiar "A" para "B"
Terça-Feira --> Copiar "A" para "C"
Quarta-Feira --> Copiar "A" para "D"
Quinta-Feira --> Copiar "A" para "B"
Sexta-Feira --> Copiar "A" para "C", sendo que "C" passará
a ser a cópia semanal e "E" será liberado
para realizaçäo de cópias diárias,
substituindo a cópia "C".
Segunda-Feira --> Copiar "A" para "D"
Terça-Feira --> Copiar "A" para "B"
Quarta-Feira --> Copiar "A" para "E"
Quinta-Feira --> Copiar "A" para "D"
Sexta-Feira --> Copiar "A" para "B", sendo que "B" passará
a ser a cópia semanal e "C" será liberado
para realização de cópias diárias,
substituindo a cópia "B".
Antes do Fechamento --> Fazer a cópia diária normalmente,
porém guardar a cópia como sendo o
backup do período, liberando o disco
"F" para as cópias diárias.
Este rodízio é necessário para que as cópias mensais e semanais sejam utilizadas
diariamente também, sendo assim, caso haja algum problema com a cópia (erro físico) você
possa detectar o problema numa cópia diária, o que é menos grave do que encontrar o
problema em uma cópia mensal que é a sua última alternativa.
Seguindo as instruções, o usuário terá os seguintes backup's:
- Situaçäo do dia anterior do processamento
- Situação do penúltimo dia de processamento
- Situação do antepenúltimo dia de processamento
- Situação da última semana
- Situação do último período encerrado
3.9. Teste do Backup
É importante que periodicamente se faça um teste do backup. Principalmente dos
bancos de dados. Você pode fazer isto da seguinte forma:
1. Crie um banco de dados teste (pode ser usado o banco demo do PROGRESS: prodb teste demo).
2. Faça o backup deste banco usando os mesmos comandos que você usa para o seu banco.
3. Retorne este backup para um diretório temporário que seja diferente do diretório em que está o seu
banco teste. (Você deve tomar cuidado ao usar o Backup/Restore do DOS, pois ele grava o diretório
no backup).
3.Compare os dois bancos usando o comando cmpdb do PROGRESS. A sintaxe deste
comando é a seguinte:
Sistema Operacional Comando para comparar dois bancos
DOS, UNIX, OS/2 cmpdb banco1 banco2
VMS PROGRESS/TOOLS=CMPDB banco1 banco2
Obs.: o cmpdb não pode ser usado em bancos multi-volume.
Este teste é importante para saber se não há nenhum problema com a mídia na qual
você está fazendo o backup e nem com os comandos que você está usando.
3.10. Cuidados com a Mídia Magnética
Descrevemos a seguir, alguns cuidados que você deve ter, afim de aumentar a vida útil
dos disquetes e fitas que usar para backup. Além, é claro de garantir as informações do seu
backup.
1. Fumar é inadmissível. O maior perigo não está na fumaça, mas nas cinzas. Use cinzeiro daqueles que
seguram o cigarro e o esvazie com freqüência.
2. Faça muitas cópias de segurança.
3. Discos, quando fora de uso, devem ficar guardados em posição vertical, sempre dentro das capas.
4. Tão logo tenha feito um Backup, coloque a etiqueta lateral de proteção e tire-a somente quando, de sã
consciência, for liberar o Backup.
5. Use etiquetas de fácil destaque na hora da remoção, procure fazê-lo com o disquete apoiado (nunca
no ar), firmando pelo canto (nunca pelo centro). Toda operação de colocar ou retirar etiqueta deve ser
feita com o disco dentro da capa. Procure escrever antes de colar; use caneta hidrocolor. A etiqueta,
quando colada de qualquer maneira, pode deixar fragmentos.
6. Evite poeira. Se possível, o ambiente dos discos jamais deve ser varrido (use pano úmido e aspirador
de pó).
7. Evite vapores químicos, detergentes, aerosol, chão-encerado.
8. Se um disco desencapado cair no chão, cuide imediatamente de saber se ainda pode ser lido; faça
nova cópia de segurança.
9. Não se deixe enganar euforicamente quando, após sucessivas mensagens de erro no disquete ele
deixa passar, principalmente se você executou um (I)gnore.
10. Atenção ao colocar o disquete na unidade - se isto for feito de forma dispersiva, você pode esbarrar
as partes sensíveis da gravação em algum obstáculo.
11. Tão logo tenha recebido novos disquetes, formate todos de uma vez, não os deixe virgens por muito
tempo.
12. Evite guardá-los em armários ou gavetas de ferro. Use madeira ou acrílico.
13. Evite colocá-los perto de motores, telefones, rádios, enfim qualquer coisa que possa gerar campo
magnético.
14. Mantenha todo o seu conjunto de computador afastado de alimentos.
15. Muito cuidado: não coloque mais de 10 (dez) disquetes numa caixa de papelão. A maioria dos discos
é danificada pelo excesso de pressão.
16. Pelo fato de terem o nome de "discos flexíveis", não vamos ficar por aí entortando-os.
17. Nunca use grampeador ou clips para anexar bilhetes aos discos, pois os mesmos não suportam serem
perfurados.
18. Quando transportar ou enviar disquetes em malotes ou correio faça uma embalagem resistente com
caixas de material rígido ou de papelão duro para evitar que os discos sejam amassados.
3.11. Outras Recomendações
• Não copiar o banco de dados em uso10
- Certifique, antes de fazer o backup que não tem nenhum
usuário usando o banco de dados. Em ambiente multiusuário você pode executar o comando
fmagnus, conforme descrito no capítulo 3, e verificar se tem algum usuário conectado ao banco. Em
monousuário, veja o arquivo .lg do banco. Nele tem a relação dos usuários que acessaram o banco.
• Teste o Backup - Pior do que você não ter uma cópia de backup para voltar, é esta cópia não voltar
por causa de erro na mídia. Por isso é importante você sempre fazer um teste para ver se o dispositivo
no qual você está fazendo backup é confiável. Volte o backup do banco de dados em um outro
diretório somente para ver se ele está em perfeitas condições.
• Não use mídia magnética de baixa qualidade - Não economize comprando disquetes, fitas streamer
para backup, que sejam de baixa qualidade. Você vai fazer o backup e é importante que seja um
material confiável.
• Não use uma mídia por muito tempo - Com o tempo, alguns disquetes, ou fitas, tendem a perder a
qualidade de gravação. Veja com seu fornecedor qual o tempo de uso da mídia magnética.
• Identifique claramente cada backup - As informações que você colocar na identificação do backup
(etiqueta) devem incluir:
1. data e hora do backup.
2. o nome do banco de dados.
3. o número do volume e o total de volumes da mídia, mesmo se for somente um único volume.
4. o nome da pessoa que fez o backup.
5. o comando para restaurar o backup (importante).
• Mantenha o backup diário por pelo menos duas semanas, o semanal por dois meses, e o mensal por
um ano. Comprar mídia magnética extra, é mais barato do que reconstruir bancos danificados.
• Mantenha algumas cópias de backup em outro prédio que não seja o local de trabalho, na casa de
algum diretor da empresa, por exemplo. Com isto, se ocorrer algum sinistro no prédio da empresa,
você terá suas informações salvas.
• Não esqueça de fazer backup - É muito importante que o cliente esteja sempre com o backup em dia,
pois imprevistos acontecem, e é imprescindível que você possa retornar um backup confiável do seu
banco de dados. Lembre-se que são as informações de sua empresa que estão em jogo.
Não esqueça de fazer backup....
Não esqueça de fazer backup....
Não esqueça de fazer backup....
Não esqueça de fazer backup....
10 Veja no capítulo 3 o comando proutil holder.
4.1. Conceito de Multi-Volume
O PROGRESS fornece a possibilidade de você dividir os arquivos .db, .bi e .ai em
várias partes (volumes ou extensões) que são acessadas como se fossem um único arquivo.
Normalmente, só dividimos o arquivo .db.
Você poderá usar um banco multi-volume nas seguintes situações:
• Em alguns sistemas operacionais existe um certo limite para o tamanho máximo de arquivo. Na
verdade, ao alcançar este limite o sistema tende a perder performance. Então, é interessante dividir .db
em várias partes com este tamanho máximo. Exemplo: em DOS, se o seu banco passar de 8 Megabytes
convém usar multi-volume. Consulte o seu sistema operacional para ver se não há algum limite deste
tipo.
• Quando no disco em que estiver o arquivo .db não tiver mais espaço, você pode transformar o .db em
multi-volume e continuar usando o primeiro volume neste disco e os outros volumes podem ser
gravados em outros discos.
• De uma forma geral se for distribuído os volumes em vários discos a performance tende a melhorar,
pois está se distribuindo as gravações e leituras para várias controladoras de disco. É importante
salientar que se distribua em vários discos físicos diferentes. Em alguns sistemas, um mesmo disco pode
ser dividido em unidades lógicas diferentes.
O tratamento multi-volume é por banco de dados. No caso do MAGNUS I.00 você
pode fazer o multi-volume para o i00adm, i00ind, i00com ou outro banco qualquer.
A seguir, mostramos um esquema do banco i00adm normal e i00adm em multi-volume, para
você ter um idéia:
1. i00adm normal:
Dados
i00adm.db
2. i00adm multi-volume:
.......
Localizaçãodas
Extensões
Dados Dados
i00adm.db i00adm.d1 i00adm.d2
Como você observou, ao transformar um banco em multi-volume o arquivo .db
servirá para indicar ao PROGRESS onde estão as extensões do banco (arquivos .d1, .d2, etc).
O acesso ao banco continua o mesmo, você não precisa alterar nenhum script do MAGNUS,
pois o PROGRESS sabe quando o banco é multi-volume e trata todas as extensões como se
fossem um arquivo único. O único detalhe é que se você não estiver usando o probkup do
PROGRESS11
para fazer backup, deverá copiar todas as extensões do banco juntas. Lembre-
se que elas podem estar em discos separados.
Você pode ter várias extensões para um banco. Estas extensões são identificadas pelo
nome do banco mais .d1, .d2, .d3 e assim por diante. A última extensão do banco vai ter
tamanho variável (para que o banco possa continuar crescendo), mas as outras extensões terão
tamanho fixo.
4.2. Passos para transformar um banco em Multi-Volume
1. Fazer um backup do banco de dados que você irá transformar em multi-volume.
2. Criar um arquivo de descrição da nova estrutura do seu banco de dados (número de extensões,
tamanho de cada uma, localização).
3. Criar a nova estrutura do banco com o prostrct create do PROGRESS. A área que você definir para
cada extensão fixa será alocada automaticamente pelo PROGRESS. Você deverá ter área em disco
suficiente para fazer isto. Veja adiante como criar um estrutura sem área em disco.
4. Copiar os dados do banco antigo para a nova estrutura. Esta cópia pode ser feita usando o comando
procopy do PROGRESS ou retornando um backup que foi feito com o probkup.
Estes são os passos para transformar um banco em Multi-Volume. A seguir, será
explicado cada passo em detalhes.
4.2.1. Backup do Banco de Dados
É sempre bom fazer o backup do banco, antes de fazer alguma grande alteração no
mesmo. No caso do banco multi-volume, será útil fazer o backup com o probkup, pois você
poderá retornar o backup na nova estrutura que você criou. Se fizer o backup usando os
comandos do sistema operacional isto não será possível.
4.2.2. Criação do Arquivo de Estrutura (.st)
Usando um editor de textos, formato ASCII, crie um arquivo com a descrição das
extensões do banco que você deseja criar. A seguir, temos um exemplo de um arquivo com
uma estrutura em UNIX:
As linhas que se iniciam por * são comentários.
As linhas que se iniciam por d indicam que será descrita uma extensão do banco. Para
cada extensão você deve especificar o diretório e nome da extensão. No nosso exemplo
estamos usando o diretório /disco1/MAGNUS. Este é um exemplo para UNIX, você deverá
informar de acordo com o sistema operacional. Em cada extensão fixa deve-se colocar o 11 O purobkup está descrito no capítulo 3. Backup.
parâmetro f e o tamanho da extensão. Neste exemplo, as três primeiras extensões são fixas e
tem tamanho de 5000 blocos. No UNIX, o tamanho do bloco geralmente é 1024 bytes e em
DOS e VMS 512 bytes. A última extensão é livre, ou seja, enquanto as três primeiras tem
tamanho limitado a última poderá crescer ilimitadamente. Você tem opção de adicionar novas
extensões mais tarde.
4.2.3. Criação da Estrutura do Banco Multi-Volume
Para criar a estrutura do banco multi-volume você deverá ter área em disco suficiente
para esta estrutura. No exemplo anterior você precisará de pelo menos 25000 blocos livres
(5000 para cada um das três extensões). Isto porque ao criar uma estrutura o PROGRESS já
aloca a área definida no arquivo de estrutura. Lembre-se de reservar alguma área também para
a última extensão (que é variável).
A partir daqui, poderá surgir três situações diferentes: 1. Você tem área em disco suficiente para criar a estrutura, mesmo com o banco de dados que pretende
transformar em multi-volume.
2. Você não tem área em disco suficiente para criar a estrutura e vai usar o probkup.
3. Você não tem área em disco suficiente para criar a estrutura e não vai usar o probkup.
Vamos explicar os passos para cada uma das três situações.
1. Criação da Estrutura com área em disco disponível
Nesta situação você deverá ter área em disco suficiente para acomodar o banco de
dados e a estrutura que será criada. Em UNIX, o comando df fornece a área disponível, em
DOS use o comando DIR. Em VMS, use o comando SHOW DEVICE.
Ao criar uma estrutura multi-volume é necessário que ela tenha um nome diferente do
banco. Por isto sugerimos, que antes de criar a estrutura, renomeie o banco de dados. Você
deve renomear o arquivo .db, .bi e .lg.
Exemplo UNIX:
mv i00adm.db i00adm1.db
mv i00adm.bi i00adm1.bi
mv i00adm.lg i00adm1.lg
Exemplo DOS e VMS:
REN I00ADM.DB I00ADM1.DB
REN I00ADM.BI I00ADM1.BI
REN I00ADM.LG I00ADM1.LG
*
* i00adm.st - exemplo de estrutura
*
d /disco1/MAGNUS/i00adm.d1 f 5000
d /disco1/MAGNUS/i00adm.d2 f 5000
d /disco1/MAGNUS/i00adm.d3 f 5000
d /disco1/MAGNUS/mgadm.d4
O banco de dados será então o I00adm1 e você vai criar a estrutura chamada I00adm,
que após a transferência dos dados, será o banco de dados que você usará.
Para criar a estrutura deverá ser usado o comando prostrct create, cuja sintaxe é a seguinte:
Sistema Operacional Comando para criar Estrutura
UNIX, DOS, OS2 prostrct create nome-banco arquivo.st
VMS PROGRESS/STRUCTURE/CREATE=arquivo.st nome-
banco
O comando prostrct está no diretório probin sob o diretório onde foi instalado o
PROGRESS. Por exemplo, se o diretório do PROGRESS é o /usr/dlc você deve executar o
comando /usr/dlc/probin/prostrct.
U tilizando o arquivo de estrutura mostrado no tópico anterior, você deve executar o
seguinte comando em DOS, UNIX ou OS2:
prostrct create i00adm.db i00adm.st
Em VMS execute o seguinte comando:
PROGRESS/STRUCTURE/CREATE=i00adm.st i00adm.db
Lembre-se de renomear o banco de dados, se você pretende criar a estrutura com o mesmo
nome do banco. Você terá então no seu disco a estrutura vazia do i00adm e o banco de dados
i00adm1 (que foi renomeado anteriormente). Você precisará agora transferir os dados do
banco para a estrutura criada. Você usará o comando procopy. A sintaxe é a seguinte:
Sistema Operacional Comando para criar Estrutura
UNIX, DOS, OS2 procopy banco-origem banco-destino
VMS PROGRESS/COPY banco-origem banco-destino
Para o nosso exemplo execute o seguinte comando em DOS/OS2/UNIX:
procopy i00adm1 i00adm
Em VMS execute:
PROGRESS/COPY i00adm1 i00adm
Com este comando será feita a transferência dos dados do banco i00adm1 para a
estrutura i00adm. Após a transferência dos dados, o banco estará pronto para ser usado e você
poderá eliminar o banco antigo usando o comando prodel do PROGRESS. Exemplo em
UNIX/DOS/OS2:
prodel i00adm1
Exemplo VMS:
PROGRESS/DELETE i00adm1
2. Criação de Banco Multi-Volume usando o probkup
Caso você não tenha área em disco suficiente para acomodar a estrutura e o banco de
dados, pode ser usado o probkup para auxiliar na criação do multi-volume. Os passos são os
seguintes: • usar o probkup para fazer um backup do banco;
• eliminar o banco para obter área em disco suficiente para a estrutura;
• criar a estrutura usando o prostrct create e o arquivo .st;
• retornar o backup do banco para a nova estrutura usando o prorest;
Veja no capítulo 4. Backup como fazer um backup usando o comando probkup. Para
maior segurança, você pode fazer mais de um backup para o banco, usando por exemplo o
comando do seu sistema operacional (BACKUP, cpio, etc). Caso ocorra algum problema
você pode voltar o backup do banco. A seguir, temos um exemplo do uso do probkup em
UNIX para o banco i00adm:
probkup i00adm /dev/rmt/0m
Para eliminar o banco de dados use o comando prodel do PROGRESS. Por exemplo,
se você estiver transformando o i00adm em multi-volume execute o comando prodel i00adm
(em VMS: PROGRESS/DELETE mgadm). Com isto você terá área suficiente para criar a
estrutura vazia do banco.
Para criar a estrutura será usado o comando prostrct create. Veja no item anterior (1.
Criação da Estrutura com área em disco disponível) a sintaxe e um exemplo de como criar a
estrutura.
Após a criação da estrutura você deve retornar o backup feito anteriormente para a nova
estrutura do banco. O comando prorest também é descrito no capítulo 4. Backup. Conforme
o exemplo anterior teríamos:
prorest i00adm /dev/rmt/0m
Este comando vai copiar os dados do banco para a nova estrutura criada e o banco estará
pronto para uso.
3. Criação do Banco Multi-Volume sem usar o probkup
Se você não tiver área em disco suficiente para o banco e a estrutura e não utilizar o
probkup para fazer um backup do banco, você deve transformar o seu banco em multi-volume
com uma única extensão e adicionar novas extensões depois.
Você usa o comando prostrct convert para transformar o seu banco para um banco
multi-volume. Lembre-se de truncar o bi12
do banco e fazer um backup.
A sintaxe do comando é a seguinte:
Sistema Operacional Comando para converter o banco em multi-volume
UNIX, DOS, OS2 prostrct convert nome-banco
VMS PROGRESS/STRUCTURE/CONVERT nome-banco
12 O comando para truncar o bi está descrito no capítulo 3> Administração do MAGNUS.
Por exemplo se você quiser transformar o banco i00adm em multi-volume execute o
seguinte comando (UNIX/DOS/OS2):
prostrct convert i00adm
Este comando vai renomear o arquivo i00adm.db para i00adm.d1 (primeira e única
extensão do banco) e vai criar o i00adm.db como arquivo de estrutura do banco. Você poderá
então adicionar novas extensões para o banco i00adm usando o comando prostrct add que é
descrito a seguir.
4.3. Adicionando novas extensões ao Multi-Volume
Depois que você começar a usar o banco multi-volume, pode ser que a última
extensão do banco, que sempre é de tamanho variável, comece a ficar muito grande e você
queira adicionar novas extensões ao banco. Estas novas extensões podem inclusive estar em
outro disco ou sistema de arquivos. Você pode ainda adicionar novas extensões a um banco
no qual você usou o prostrct convert.
Para tanto, você deve criar um novo arquivo de estrutura (arquivo .st) contendo
somente a descrição das novas extensões que pretende adicionar. Suponha que você esteja
usando o banco i00adm como multi-volume e ele já tenha 3 extensões. Vamos adicionar uma
nova extensão para este banco. Usando um editor de textos, formato ASCII, você pode criar o
arquivo nova.st com o seguinte conteúdo:
Neste caso estamos adicionando a extensão i00adm.d4 ao banco i00adm. Você usará
então o comando prostrct add, cuja sintaxe é a seguinte:
Sistema Operacional Comando para adicionar nova extensão
UNIX, DOS, OS2 prostrct add nome-banco arquivo.st
VMS PROGRESS/STRUCTURE/ADD=arquivo.st nome-banco
No nosso exemplo você usaria o seguinte comando:
prostrct add i00adm nova.st
Depois de executar este comando o banco passará a ter 4 extensões. Lembre-se que a última
extensão será sempre variável.
*
* nova.st - nova extensão para o banco i00adm
*
d /disco2/MAGNUS/i00adm.d4
4.4. Listando a Estrutura do Multi-Volume
Para você listar a estrutura de um banco multi-volume você pode usar o comando
prostrct list. Este comando gera um arquivo de estrutura (.st) com o mesmo nome do banco.
A sintaxe do comando é a seguinte:
Sistema Operacional Comando para listar a estrutura do multi-volume
UNIX, DOS, OS2 prostrct list nome-banco
VMS PROGRESS/STRUCTURE/LIST nome-banco
Exemplo:
prostrct list i00adm
Com este comando será gerado o arquivo i00adm.st com a descrição da estrutura do multi-
volume.
4.5. Usando Estatísticas do Banco
Para um banco de dados você pode emitir um relatório da utilização da área do banco
de dados. Você usa o comando prostrct statistics. Este comando lhe fornece as seguintes
informações:
• O número de blocos necessários para realizar um backup completo usando o probkup.
• O número de blocos necessários para realizar um backup incremental do banco.
• O número total de blocos alocados para o banco de dados.
• O número total de blocos livres.
• O número total de blocos em uso.
A sintaxe do comando é a seguinte:
Sistema Operacional Comando para listar estatísticas do banco
UNIX, DOS, OS2 prostrct statistics nome-banco
VMS PROGRESS/STRUCTURE/STATISTICS nome-banco
4.6. Algumas considerações sobre multi-volume
Como foi falado no começo, o multi-volume será útil naqueles sistemas que tem uma
certa limitação para o tamanho máximo de um arquivo, ou quando no disco em que se
encontra o arquivo .db não tem mais área em disco. Se você separar um banco em vários
discos lembre-se que ao fazer backup você deve copiar o arquivo .db, .bi, .lg e todas as
extensões do banco. A não ser que você esteja usando o probkup, que reconhece o banco
multi-volume.
O multi-volume é feito por banco de dados. Nos exemplos deste capítulo, usamos
sempre o banco i00adm. Você pode usar o multi-volume em todos os outros bancos também.
5.1. After-Image e Before-Image
Neste primeiro tópico, falaremos sobre como o PROGRESS faz para recuperar os
dados em caso de erro. Falaremos sobre cada um dos dois métodos: after-image e before-
image.
Convém relembrar que, um banco de dados é composto por um arquivo .db, .bi e .lg.
No caso do i00adm, por exemplo, teremos o i00adm.db, i00adm.bi e i00adm.lg. Quando for
habilitado o after-image teremos ainda um quarto arquivo chamado .ai (i00adm.ai por
exemplo).
5.1.1. Como funciona o processamento Before-Image
Este processamento é feito automaticamente pelo PROGRESS e protege o banco de
dados contra falhas no sistema (uma queda de energia por exemplo), mas não protege contra
uma falha no disco. No caso de uma falha no disco você deve voltar o backup. Você não
precisa habilitar o before-image para que ele funcione. Isto é feito automaticamente pelo
PROGRESS.
Como exemplo, imagine que você está usando o MAGNUS e ocorra queda de energia.
Quando você entrar novamente no MAGNUS você verá as seguintes mensagens na tela:
Você verá esta mensagem para cada banco de dados que estiver sendo modificado no
momento do erro. Esta mensagem indica que a última sessão terminou de modo anormal e
que as transações incompletas estão sendo desfeitas. Tudo aquilo que já foi atualizado no
banco, o PROGRESS mantém. Mas as transações incompletas são desfeitas. No PROGRESS
temos o conceito de transação, que é um conjunto de alterações no banco de dados que deve
ser feita por completo ou não. Por exemplo, a atualização do movimento da Contabilidade,
pode ser considerada uma transação. Se durante a atualização ocorrer algum problema, ela
será desfeita e você deverá reiniciá-la do começo.
Imagine que você vai alterar alguma informação no cadastro de clientes, por exemplo
o endereço. Assim que, você for alterar o registro do cliente, o PROGRESS grava uma cópia
deste registro no arquivo .bi do banco. Você altera o registro de cliente e ele é regravado no
arquivo .db. Se por acaso ocorrer algum erro durante a atualização do registro, o PROGRESS
usa a cópia que ele gravou no arquivo .bi para restaurar a situação anterior do registro no
arquivo .db. Veja o esquema a seguir que ilustra este exemplo:
** The last session was abnormally terminated.
** Any incomplete transactions are being backed out.
** Data recovery is complete. You must return all active transactions.
Press space bar to continue.
O before-image tem as seguintes características:
• É automático. Você não precisa habilitá-lo para usar.
• Protege contra falhas do sistema.
• Não protege contra perda do disco.
Se você estiver usando seu banco de dados e ocorrer uma falha no disco em que ele se
localiza, você só vai poder recuperá-lo retornando um backup. Neste caso, você pode perder
todas as alterações feitas desde o último backup. Imagine que foi feito o backup na segunda-
feira à noite, e ocorreu um erro na terça à tarde. Você vai retornar o backup e perder todas as
alterações que foram feitas na terça de manhã. É neste caso que entra o processamento after-
image.
5.1.2. Processamento After-Image
Quando você estiver usando o after-image o PROGRESS fará um trabalho extra ao
modificar o banco de dados. Além de regravar o registro alterado no arquivo .db ele gravará
uma cópia do mesmo no arquivo de after-image (.ai). Veja o esquema a seguir:
Inicio da alteração
Fim das alterações
arquivo
.bi
o Progress lê o registro
de clientes do banco (.db)arquivo
.db
arquivo
.db
o Progress grava uma copia
do registro no .bi
o Progress regrava o registro
com as alterações no .db
No caso de ocorrer um erro no disco em que está o banco de dados, você deve retornar
o backup do banco e reprocessar o after-image do dia. Assim, você terá o seu banco na
mesma situação anterior a que o ocorreu o problema no disco. Então, só faz sentido usar o
after-image, se você tiver mais de um disco. Um para manter o banco de dados (.db, .bi e
.lg) e outro para manter o arquivo de after-image (.ai).
Para usar o after-image é necessário que o mesmo precise ser habilitado. Adiante é
descrito este procedimento. Algumas características do after-image:
• Não é automático. Você precisa habilitar o mesmo para poder usá-lo.
• Requer que você esquematize um procedimento regular de backup.
• Protege seu banco contra perda do disco (a menos que ocorra problema no disco em que está o banco
de dados e no disco em que está arquivo de after-image).
Inicio da alteração
Fim das alterações
arquivo
.bi
o Progress lê o
registro
de clientes do banco
(.db)
arquivo
.db
arquivo
.db
o Progress grava uma
copia
do registro no .bi
o Progress regrava o
registro
com as alterações no
.db
arquivo
.ai
além de gravar o
registro
no .db, também é
gravadouma copia no .ai
5.2. Preparação para usar o After-Image
Antes de habilitar o after-image você deve tomar conhecimento de alguns pontos, para
que ele possa ser usado de uma forma correta e eficiente.
5.2.1. Escolhendo a localização para os arquivos do banco
Como falamos, anteriormente, um banco de dados é composto pelos arquivos .db, .bi
e .lg. Quando você estiver usando after-image teremos ainda um quarto arquivo com
terminação .ai. Para que tenha sentido usar o after-image é necessário ter mais de um disco no
seu equipamento. Normalmente, você terá a seguinte configuração (tomando como exemplo o
after-image para o banco mgadm):
Ao definir a localização para os arquivos .db, .bi, .lg e .ai, tenha em mente o seguinte:
• Para proteção contra falhas de hardware coloque o arquivo .ai em um disco diferente dos arquivos
.db, .bi e .lg.
• Por causa de performance você pode colocar o arquivo .bi em um disco diferente do .db13
. Tenha o
cuidado de não colocar o .bi no mesmo disco do .ai.
Obs.: neste capítulo ao falarmos de "banco de dados", estaremos nos referindo aos arquivo
.db, .bi e .lg. O "arquivo after-image" será o arquivo .ai do banco.
13 Você faz isto usando o parâmetro -g, que é descrito no capítulo 3.
Máquina
Disco 1 Disco 2
mgadm.db
mgadm.bi
mgadm.lg
mgadm.ai
5.2.2. Estratégia de Backup
O processamento after-image é uma segurança a mais para o seu banco de dados, mas
ele não funciona sem backup. Veja o seguinte esquema:
situação atual do banco = último backup + arquivo after-image atual
O backup do banco de dados poderá ser feito usando o comando probkup do
PROGRESS ou os comandos do seu sistema operacional. Neste manual, você tem um
capítulo dedicado ao backup. Recomendamos que você defina seu método de backup
primeiro para depois começar a usar o after-image.
É preciso um controle bastante rígido com relação ao backup, no sentido de identificar
as mídias nas quais você faz o backup. Você deve ter o nome do banco, a data em que foi
feito, quem fez o backup e o comando para retornar o mesmo.
5.3. Usando o After-Image
Depois de definir sua política de backup, você pode começar a usar o after-image. Você usará
dois utilitários do PROGRESS:
• proutil - este utilitário está no diretório bin que se encontra no diretório em que foi instalado o
PROGRESS.
• rfutil - este utilitário está no diretório bin que se encontra no diretório em que foi instalado o
PROGRESS (ex.: se o PROGRESS foi instalado no diretório /usr/dlc, você deve executar o seguinte
comando para usar o rfutil: /usr/dlc/bin/rfutil <opções>).
5.3.1. Passos para usar o after-image
Vamos tomar como exemplo o banco i00adm. Suponha que você queira habilitar o after-
image deste banco. Os passos que você deve seguir são os seguintes:
1. Faça um backup do banco de dados. Pode ser usado o probkup ou o comando do seu sistema
operacional (cpio, tar, BACKUP, etc). Antes de fazer o backup é interessante verificar se o banco não
está em uso e truncar o arquivo .bi14
.
1. Se você não usou o comando probkup para fazer o backup, você deve marcar o banco como
"backupeado". Adiante é explicado como fazer isto.
2. Habilite o after-image no banco i00adm. Será usado o rfutil.
3. Agora você pode usar o banco i00adm normalmente. A diferença é que você precisa usar o parâmetro
-a para indicar onde se localiza o arquivo after-image.
4. Após o uso do banco, no final do dia, encerre a sessão PROGRESS. Caso esteja sendo usado em
multiusuário derrube o servidor.
5. Faça o backup do banco de dados e do arquivo after-image (.ai).
6. Inicie um novo arquivo after-image usando o rfutil. A partir deste ponto o banco estará liberado
novamente para uso.
A seguir, descreveremos cada um dos passos necessários para uso do after-image.
14 Veja o capítulo 3. Administração para informações sobre estes comandos.
5.3.2. Fazendo backup do Banco de Dados
Os passos necessários para fazer um backup do banco estão descritos no capítulo 4.
backup. É essencial que você use o comando truncate bi para truncar o before-image do banco
antes do backup. Tenha sempre em mente que para iniciar um arquivo after-image é preciso
fazer o backup do banco de dados antes.
5.3.3. Marcando o banco como "backupeado"
Marcar o banco como "backupeado" significa indicar ao PROGRESS que foi feito
backup do mesmo. O PROGRESS verifica isto ao iniciar o after-image. Quando você usa o
probkup não tem necessidade de fazer isto, pois o banco é marcado automaticamente. Se você
usar os comandos do seu sistema operacional (cpio, tar, BACKUP/RESTORE, etc) é
necessário executar o seguinte comando:
Sistema Operacional Comando para marcar o banco como "backupeado"
UNIX, DOS, OS2 rfutil nome-banco -C mark backedup [ -g nome-bi ]
VMS PROGRESS/UT=MARK_BACKEDUP[/BEFORE_IMAGE=nome
-bi]
nome-banco
Para marcar o banco i00adm como backedup use o comando (UNIX/DOS/OS2):
rfutil i00adm -C mark backedup
Em VMS, o exemplo seria o seguinte:
PROGRESS/UT=MARK_BACKEDUP i00adm
5.3.4. Habilitando o after-image do banco
Para habilitar o after-image você usa o comando rfutil aimage begin. Este comando: • Cria o arquivo after-image do banco.
• Marca no banco que ele possui after-image habilitado.
O comando é o seguinte:
Sistema Operacional Comando para habilitar after-image
UNIX, DOS, OS2 rfutil nome-banco -C aimage begin
buffered/unbuffered -a nome-ai [ -g nome-bi ]
VMS PROGRESS/UT=AIMAGE_BEGIN/AFTER_IMAGE=nome-
ai
[/BEFORE_IMAGE=nome-bi] nome-banco
Neste comando você deve especificar o nome do banco e o nome do arquivo .ai. No
caso do .ai, você deve informar o diretório e disco em que ele deverá ser criado.
Em UNIX/DOS/OS2, a opção BUFFERED faz com que as gravações do .ai sejam
buferizadas pelo sistema operacional. Se for usado UNBUFFERED as gravações serão feitas
diretamente pelo PROGRESS.
Obs.: Em VMS, todas gravações são UNBUFFERED e esta opção não tem efeito no
comando.
A opção BUFFERED fornece uma performance melhor. Entretanto, se você precisar
reprocessar o after-image, você pode perder algumas transações que foram completadas nos
dois últimos minutos antes do momento em que ocorreu o erro. Mas isto não afeta em nada a
estrutura do seu banco.
Por exemplo, para habilitar o after-image do mgadm você usará o seguinte comando em
UNIX:
rfutil i00adm -C aimage begin unbuffered -a /disco2/MAGNUS/i00adm.ai
Em DOS/OS:
rfutil i00adm -C aimage begin unbuffered -a d:i00adm.ai
Em VMS:
PROGRESS/UT=AIMAGE_BEGIN/AFTER_IMAGE=USR:[U2]IOOADM.AI I00ADM
A partir deste momento, para usar o banco I00adm deverá ser sempre especificado o
parâmetro -a. Veja a seguir o tópico que explica como fazer isto. Se você tentar iniciar um
after-image para um banco que foi modificado após o último backup, o rfutil mostrará uma
mensagem de erro e vai cancelar.
5.3.5. Usando um banco com after-image habilitado
Para usar um banco com o after-image é preciso usar o parâmetro -a. No caso do
MAGNUS, você pode colocar este parâmetro no arquivo .pf do banco. Por exemplo, se você
for usar o after-image no i00adm, deve ser feita a seguinte alteração no i00adm.pf:
Assim, ao executar o script MAGNUS o PROGRESS saberá onde se localiza o
arquivo de after-image do banco.
No caso da carga do servidor também deverá ser informado o parâmetro -a. Sugerimos
que você copie o script smagnus para smgadm por exemplo e coloque neste arquivo o
parâmetro -a. A mesma coisa para o script fmagnus, que derruba o servidor do banco.
O PROGRESS não vai iniciar sessão se você informar o nome do arquivo .ai incorretamente.
#
# i00adm.pf - parametros do i00adm
#
-db i00adm.db
-ld i00adm
-a /disco2/MAGNUS/mgadm.ai
5.3.6. Iniciando um novo after-image
Após fazer o backup do banco de dados e do arquivo de after-image, você pode usar o
rfutil aimage new para iniciar um novo arquivo after-image. Ou seja, este comando trunca o
arquivo after-image do banco.
Sistema Operacional Comando para habilitar after-image
UNIX, DOS, OS2 rfutil nome-banco -C aimage new
buffered/unbuffered -a nome-ai [ -g nome-bi ]
VMS PROGRESS/UT=AIMAGE_NEW/AFTER_IMAGE=nome-ai
[/BEFORE_IMAGE=nome-bi] nome-banco
Este comando será usado sempre que fizer o backup do banco com after-image
habilitado. Este comando difere do comando para habilitar o after-image pelo uso da opção
new no lugar de begin.
5.3.7. Desabilitando o after-image
Caso você queira desabilitar o after-image de um banco, use o seguinte comando:
Sistema Operacional Comando para habilitar after-image
UNIX, DOS, OS2 rfutil nome-banco -C aimage end [ -g nome-bi ]
VMS PROGRESS/UT=AIMAGE_END[/BEFORE_IMAGE=nome-
bi
nome-banco
Após este comando não será mais necessário usar o parâmetro -a para acessar o banco.
5.4. Reprocessando um arquivo after-image
Neste tópico explicaremos o comando para reprocessar um arquivo after-image.
Imagine a seguinte situação: na terça-feira à tarde ocorre um problema no seu disco e você
perde o arquivo .db. Você deve voltar o backup do banco de dados da segunda à noite e
reprocessar o after-image do banco da terça. Assim, você terá seu banco atualizado até o
momento em que ocorreu o erro.
O comando para reprocessar o after-image é o seguinte:
Sistema Operacional Comando para reprocessar o after-image
UNIX, DOS, OS2 rfutil nome-banco -C roll forward [verbose]
-a nome-ai [ -g nome-bi -B n -i ]
VMS PROGRESS/UT=ROLL_FORWARD/AFTER_IMAGE=nome-
ai
[/BEFORE_IMAGE=nome-bi/BLOCKS=n/NOINTEGRITY]
nome-banco
Neste comando se você usar a opção -i (NOINTEGRITY) o processo de restauração será mais
rápido.
Se houver algum erro durante o ROLL FORWARD, será necessário voltar o backup do banco
e reiniciar o processo.
5.5. O que pode e o que não pode fazer no after-image
Tenha sempre em mente os seguinte cuidados ao usar after-image.
Sempre: • Teste seus backup's.
• Faça backup do after-image. Identifique e guarde o mesmo. É bom testar também este backup.
• Trunque o arquivo .bi do banco antes de fazer o backup.
• Faça o backup do arquivo .db, .bi e .lg juntos.
• Faça o backup do arquivo .ai num dispositivo diferente.
• Identifique todos os seus backup's.
Nunca: • Elimine o arquivo de after-image a não ser que esteja eliminando todo o banco e não necessita mais
do mesmo, ou tem um backup completo e seguro.
• Use o AIMAGE NEW sem ter feito o backup do after-image.
• Faça backup do after-image sem primeiro truncar o before-image.
• Copie o arquivo .db sem copiar o .bi e .lg.
• Elimine o .db ou .bi a não ser que não precise mais do banco, ou tenha um backup completo e seguro
do mesmo.
• Volte o backup do arquivo .db sem voltar também o backup do .bi e .lg.
5.6. O que fazer durante erros do sistema
Neste tópico, falaremos sobre os procedimentos a serem executados no caso de
alguma falha no sistema, como queda de energia, perda de um disco por falha de hardware,
etc.
5.6.1. Durante o uso do proutil e rfutil
Se ocorrer algum problema no seu sistema durante o uso de algum destes utilitários,
simplesmente reinicie o processo:
UNIX/DOS/OS2 VMS
proutil BUSY
proutil HOLDER
proutil TRUNCATE BI
rfutil AIMAGE BEGIN
rfutil AIMAGE CHANGE
rfutil AIMAGE END
rfutil AIMAGE SCAN
rfutil AIMAGE NEW
rfutil MARK BACKEDUP
PROGRESS/UT=BUSY
PROGRESS/UT=HOLDER
PROGRESS/UT=TRUNCATE_BI
PROGRESS/UT=AIMAGE_BEGIN
PROGRESS/UT=AIMAGE_CHANGE
PROGRESS/UT=AIMAGE_END
PROGRESS/UT=AIMAGE_SCAN
PROGRESS/UT=AIMAGE_NEW
PROGRESS/UT=MARK_BACKEDUP
Se você estiver executando o rfutil ROLL FORWARD (UNIX/DOS/OS2) ou
PROGRESS/UT=ROLL_FORWARD (VMS), então faça o seguinte:
1. Volte a cópia de backup do banco de dados.
2. Reinicie o processo.
5.6.2. Durante o backup do Banco de dados
Se ocorrer algum erro durante o backup do banco, simplesmente reinicie o backup
novamente.
5.6.3. Durante o uso do PROGRESS
Se ocorrer erro do sistema durante o uso do PROGRESS, reinicie o processo. O
PROGRESS usará o arquivo de before-image para restaurar o banco (.db) e o after-image
(.ai). Não importa se você está usando a opção BUFFERED ou UNBUFFERED no after-
image. Em ambos os casos o PROGRESS vai restaurar os arquivos .db e .ai.
Se você estiver usando o PROGRESS em UNIX/DOS/OS2 com a opção -r ou a opção
-i, o PROGRESS não poderá restaurar completamente os erros do .db e .ai.
5.6.4. Perda do disco do .db ou .ai
Backup do after-image (.ai) - Seu after-image contém informações que você necessita
para atualizar o seu banco de dados. Faça backup do after-image num dispositivo diferente no
qual este arquivo está.
Retornando backup do banco de dados - Restaure o backup do banco (.db, .bi e .lg)
que foi feito imediatamente antes do início do after-image atual. Se você estiver usando o
probkup com a opção incremental, retorne o backup completo mais recente e todos os
incrementais que foram feitos. Não retorne o backup de arquivos after-image anteriores. A
seguir, faça o reprocessamento do after-image do banco conforme descrito anteriormente
neste capítulo.
5.6.5. Perda do arquivo after-image
Caso ocorra algum problema no disco do after-image e ele seja perdido, faça o seguinte:
1. desabilite o after-image.
2. trunque o .bi.
3. faça um backup do banco.
4. marque o banco como backedup.
5. habilite o after-image.
5.6.6. Perda do backup do banco
Você pode reconstruir um banco de dados usando um backup anterior e o after-image
associado a este banco.
5.7. O que fazer quando o disco lotar
Se durante o uso do PROGRESS seu disco lotar, o PROGRESS vai encerrar e mostrar
uma mensagem de erro. Neste caso faça o seguinte:
1. Elimine os arquivos que não são necessários neste disco.
2. Reinicie o PROGRESS, que ele fará a recuperação automática do banco.
Se não puder conseguir mais área no disco para o PROGRESS fazer a recuperação
automática, você deve executar procedimentos de acordo com o conteúdo do disco.
5.7.1. Quando o disco do After-Image lotar
Se o disco em que estiver o after-image lotar, faça o seguinte:
1. Faça um backup do .db, .bi, .lg e .ai.
2. Remova o after-image do disco cheio.
3. Desabilite o after-image.
4. Reinicie o PROGRESS, para ele fazer a recuperação automática do banco.
5. Encerre a sessão PROGRESS.
6. Trunque o .bi.
7. Faça backup do banco de dados.
8. Mark o banco como backedup.
9. Use o rfutil AIMAGE BEGIN para habilitar o after-image.
10. Volte ao uso normal do PROGRESS.
5.7.2. Quando o disco do .db ou .bi lotar
Neste caso, você deve conseguir área livre em disco para fazer a recuperação
automática do banco. Se não for possível mude estes arquivos para um disco maior.
5.8. Outras Considerações
• No capítulo Roll Forward Recovery do manual System Administration do PROGRESS, também, é
falado sobre o after-image.
• O uso do after-image implica numa pequena diminuição da performance, mas por outro lado, você
terá uma segurança a mais para seu banco de dados.
• Se você for usar o after-image no MAGNUS, isto deverá ser implementado para os três bancos
(i00adm, i00ind e i00com), porque se você perder o disco onde estão os três bancos, deverá ser
reprocessado o after-image nos três bancos para que eles estejam atualizados até o momento do
erro. Não adianta reprocessar somente em um dos bancos, pois eles não estarão mais
sincronizados.
• Como existem diversos passos para usar o after-image, ou seja, execução de diversos comandos,
sugerimos que você coloque estes comandos em script's (UNIX), ou arquivos lote (.BAT em DOS e
OS2) ou arquivos .COM em VMS.
• Por motivos de performance, você deve executar o comando "proaiw nome-do-banco" sempre que for utilizar o after-image.
Este comando deve ser executado logo após a carga do servidor do banco de dados. Informações detalhadas sobre este
procedimento podem ser encontradas no manual do System Administration do PROGRESS.