Comparação de Páginas

...

• Banco read-only, scale-out. Possibilidade de se ter um outro banco sendo executado simultaneamente (atualizado de forma síncrona), read-only, para emissão de relatórios e arquivos (SPED, etc).
• Cláusula -gn praticamente obsoleta. Setada automaticamente entre -gnl (default = número de CPUs) e -gnh (-gn x 4 = 80). Default = 20 e ajustada automaticamente pelo SQLAnywhere.

Migrando o banco para o Sybase 12.

Aumentando a velocidade.

Aumentando a disponibilidade.

A disponibilidade do banco deve ser calculada de forma que se tenha o melhor custo/benefício para o cliente. O primeiro passo é definir quanto tempo o cliente aguentaria sem o Sistema no ar. Isso pode variar de nem um minuto, alguns minutos, algumas horas ou muitas horas. É lógico que, em sã consciência, todo cliente iria preferir a primeira opção. Porém, o custo de se ter um servidor auxiliar, licença de uso de um outro Sybase, uma estrutura de rede redundante, todos os micros com no-break, Internet redundante enfim, ter todos os pontos que podem falhar duplicados pode não compensar comparando este cenário com um muito mais barato onde teríamos um servidor auxiliar destino dos backups e um funcionário para acioná-lo caso o servidor principal falhe.
Enfim, é questão de avaliação porém é necessário sempre simular o tempo de parada nos mais variados cenários para se chegar a uma decisão conjunta.
Por isso, iremos listar os mecanismos disponíveis de proteção e cada um poderá optar pelo cenário com melhor custo/benefício para a sua empresa.
Você deve avaliar o procedimento de backup particularmente em função de cinco variáveis:

• Cobertura: Deve ser todo o banco de dados + todas as alterações ocorridas.
• Frequência: Quanto frequente deve ser o backup full e os incrementais? Dica: a resposta está no tempo de parada no caso de uma restauração. Quanto mais frequentes, os backups full menor o tempo de parada porém mais carga será exigida do banco de dados.
• Separação: Colocar os backups em outros discos rígidos ou computadores para que uma pane não os afete. Tenha cópia do backup full em locais diferentes e que não estejam juntos fisicamente (de preferência, em endereços diferentes).
• Histórico: Ter mais de um conjunto (full + incrementais) de forma que se possa recuperar dados ou mesmo um backup mais antigo no caso de alguma emergência.
• Validação: Validar, validar, validar os backups sempre e, de preferência, de forma automática. Não se esquecer de realizar, de vez em quando, uma restauração manual para não esquecer como o procedimento é realizado (aprender na hora da emergência sempre leva a resultados desastrosos ou demorados).
• Segurança: Verifique quem tem acesso aos backups (não só fisicamente como na rede local). Não deixe os mesmos de forma que qualquer pessoa possa obtê-los ou copiá-los (e principalmente, danificá-los).

Backup full

É a forma mais simples de se ter uma cópia do banco de dados em segurança. Todos os dados são copiados para um outro local criando uma cópia idêntica do banco de dados num determinado ponto no tempo.
Podemos executar o backup tanto no servidor diretamente quanto de uma outra máquina qualquer.

• Usando a linha de comando

  Bloco de código
  dbbackup -c "SERVER=scgwin12;UID=DBA;PWD=mara97" "c:\backup" # opções # Host=192.168.0.1 # DBN=scgwin.db

• Usando o ISQL

  Bloco de código
  BACKUP DATABASE DIRECTORY 'C:\\backup';

  Nota
  Tanto o arquivo principal (.DB) quanto o arquivo de log de transações (.LOG) são copiados e necessários no caso de uma restauração.

Backup incremental

...

• Cláusula -ad para aplicar backup incremental a partir de diretório. Basta colocar todos os arquivos .log (criados no procedimento de backup incremental) num diretório e utilizar esta cláusula para que o SQLAnywhere aplique todos os logs no processo de restauração do banco, em ordem sem necessidade de se especificar quais e em que ordem ele precisa aplicar.
• HotFailOver: Ver tópico Alta Disponibilidade.
• Suporte 64bits. Para ter mais cache disponível.
• Particionamento de Tabelas. É possível particionar uma tabela de forma que parte dela fique num arquivo .db e parte dela em outro arquivo .db de forma que possamos criar uma espécie de arquivo morto com dados antigos deixando o banco com dados a partir de uma determinada data.
• Usar stored procedures como tabelas. Pode-se utilizar uma stored procedure que retorne dados dentro de um SELECT. Assim, o comando call sa_index_density(); e SELECT * FROM SA_INDEX_density() ORDER BY SA_INDEX_density.density; são semelhantes. Note que podemos (como no segundo comando) ordenar ou agrupar o resultado.
• InMemory Server mode. Roda o banco inteiro em memória (se couber).

Migrando o banco para o Sybase 12.

Aumentando a velocidade.

Aumentando a disponibilidade.

A disponibilidade do banco deve ser calculada de forma que se tenha o melhor custo/benefício para o cliente. O primeiro passo é definir quanto tempo o cliente aguentaria sem o Sistema no ar. Isso pode variar de nem um minuto, alguns minutos, algumas horas ou muitas horas. É lógico que, em sã consciência, todo cliente iria preferir a primeira opção. Porém, o custo de se ter um servidor auxiliar, licença de uso de um outro Sybase, uma estrutura de rede redundante, todos os micros com no-break, Internet redundante enfim, ter todos os pontos que podem falhar duplicados pode não compensar comparando este cenário com um muito mais barato onde teríamos um servidor auxiliar destino dos backups e um funcionário para acioná-lo caso o servidor principal falhe.
Enfim, é questão de avaliação porém é necessário sempre simular o tempo de parada nos mais variados cenários para se chegar a uma decisão conjunta.
Por isso, iremos listar os mecanismos disponíveis de proteção e cada um poderá optar pelo cenário com melhor custo/benefício para a sua empresa.
Você deve avaliar o procedimento de backup particularmente em função de cinco variáveis:

• Cobertura: Deve ser todo o banco de dados + todas as alterações ocorridas.
• Frequência: Quanto frequente deve ser o backup full e os incrementais? Dica: a resposta está no tempo de parada no caso de uma restauração. Quanto mais frequentes, os backups full menor o tempo de parada porém mais carga será exigida do banco de dados.
• Separação: Colocar os backups em outros discos rígidos ou computadores para que uma pane não os afete. Tenha cópia do backup full em locais diferentes e que não estejam juntos fisicamente (de preferência, em endereços diferentes).
• Histórico: Ter mais de um conjunto (full + incrementais) de forma que se possa recuperar dados ou mesmo um backup mais antigo no caso de alguma emergência.
• Validação: Validar, validar, validar os backups sempre e, de preferência, de forma automática. Não se esquecer de realizar, de vez em quando, uma restauração manual para não esquecer como o procedimento é realizado (aprender na hora da emergência sempre leva a resultados desastrosos ou demorados).
• Segurança: Verifique quem tem acesso aos backups (não só fisicamente como na rede local). Não deixe os mesmos de forma que qualquer pessoa possa obtê-los ou copiá-los (e principalmente, danificá-los).

Backup full

É a forma mais simples de se ter uma cópia do banco de dados em segurança. Todos os dados são copiados para um outro local criando uma cópia idêntica do banco de dados num determinado ponto no tempo.
Podemos executar o backup tanto no servidor diretamente quanto de uma outra máquina qualquer.

• Usando a linha de comando

  Bloco de código
  dbbackup -c "SERVER=scgwin12;UID=DBA;PWD=mara97" "c:\backup" # opções # Host=192.168.0.1 # DBN=scgwin.db

• Usando o ISQL

  Bloco de código
  BACKUP DATABASE DIRECTORY 'C:\\backup';

  Nota
  Tanto o arquivo principal (.DB) quanto o arquivo de log de transações (.LOG) são copiados e necessários no caso de uma restauração.

Backup incremental

O backup incremental é um backup parcial somente do arquivo de transações (.LOG) obtido no momento em que é realizado o backup. É como se tirássemos uma foto do log no momento da execução do comando. É um backup bem mais rápido do que o backup full. É chamado incremental pois logo após a sua realização truncamos o arquivo de log original fazendo com que o log original tenha somente as transações a partir daquele momento (em que o mesmo fora truncado). Ele é utilizado num esquema de backups onde normalmente é realizado um backup full num primeiro passo e, em seguida, realizados backups incrementais num intervalo fixo de tempo (1h por exemplo). Assim, teríamos num plano de backup hipotético, um backup full programado para a meia-noite, outro para o meio-dia e backups incrementais de hora em hora (1:00am, 2:00am e assim por diante). Para se restaurar um banco de dados num esquema como este, precisaríamos ter o backup full e todos os backups incrementais até o ponto da falha.

...

SELECT Number AS connection_number, CONNECTION_PROPERTY ( 'Name', Number ) AS connection_name, CONNECTION_PROPERTY ( 'Userid', Number ) AS user_id,
CAST ( Value AS NUMERIC ( 30, 2 ) ) AS approximate_cpu_time
FROM sa_conn_properties()
WHERE PropName = 'ApproximateCPUTime' ORDER BY approximate_cpu_time DESC;

# connection_number connection_name  user_id    approximate_cpu_time 
# ================= ================ ========== ==================== 
# 33                SQL_DBC_5071260  LongRunner       97.20
# 35                SQL_DBC_3aa4a78  DBA              2.09 
# 12                Sybase Central 1 DBA              1.09 
# 37                SQL_DBC_504b0f0  LotsOfLocks      0.00

Como monitorar?

Existem algumas opções para o monitoramento destes parâmetros:

...