Em
SQL Server usa o conceito de Registro write ahead, em que cada operação de alteração de dados é gravada pela primeira vez no log de transações (. LDF) da memória (buffer pool) e periodicamente liberado para a arquivo de dados do disco (. MDF) como parte do processo de ponto de verificação (as operações de alteração de dados são de inserção, atualização, exclusão e outras operações, como recompilação e reorganização do índice). O uso de um registro de transações garante que, se houver um desastre, você poderá restaurar o banco de dados para um estado anterior, com perda mínima. Exemplos de desastres incluem falha de hardware ou erro humano.

Modelo de recuperação completa:
Depois de fazer backup da transação usando o modelo de recuperação completa, SQL Server sinaliza registros com backup como inativos e truncar o registro. Dessa forma, todas as novas operações que são registradas no log de transações podem reutilizar esse espaço substituindo as entradas inativas. Esse design ajuda a evitar o crescimento do tamanho do log.

Se nenhum backup periódico do log de transações for feito, o tamanho do registro de transações continuará crescendo até que consuma todo o espaço em disco disponível. Portanto, se o banco de dados do ePO estiver configurado para usar o modelo de recuperação completa, é importante executar backups regulares do log de transações para manter seu tamanho em cheque.

Modelo de recuperação simples:
No modelo de recuperação simples, depois que o ponto de verificação ocorrer e os registros forem movidos para o disco, o SQL Server truncar o registro de transações. Essa ação libera o espaço internamente no log de transações arquivo. O registro de transações não aumenta de tamanho, desde que haja espaço suficiente disponível para as transações abertas atuais.

No modelo de recuperação simples, o conceito de backup do log de transações não é usado, pois você só faz um backup completo regular do banco de dados do ePO. Se houver um desastre, você poderá recuperar somente o último backup completo. Todas as alterações que ocorrerem após o último backup completo serão perdidas.

O modelo de recuperação simples é uma solução aceitável para a maioria dos clientes corporativos, pois os dados perdidos em um desastre são geralmente dados de evento desde o último backup completo. O modelo de recuperação completa inclui a sobrecarga administrativa do backup do log de transações para o banco de dados do ePO periodicamente.

Por esse motivo, a Modelo de recuperação simples para o banco de dados do ePO, é recomendável. No entanto, se você optar por usar o modelo de recuperação completa, certifique-se de que tenha um bom plano de backup para o banco de dados do ePO e o registro de transações. Uma discussão sobre o plano de backup para os bancos de dados do SQL Server está além do escopo deste artigo. Para obter mais detalhes, consulte a documentação técnica do SQL Server.

NOTA: Se você tiver vários bancos de dados com diferentes modelos de recuperação, poderá criar planos de manutenção de banco de dados separados para cada modelo de recuperação. Dessa forma, você pode incluir uma etapa para fazer backup dos logs de transação somente nos bancos de dados que não usam o modelo de recuperação simples.

Definir o modelo de recuperação do banco de dados do ePO como simples
Para verificar se o modelo de recuperação está definido como simples, faça as seguintes alterações no SQL Server Management Studio:

1. Clique em Todos os Programas, Microsoft SQL Server <version>, SQL Server Management Studio.
2. Selecione o Autenticação Digite (Windows ou SQL Server) e clique em Conectar para efetuar logon na instância do SQL Server que hospeda o banco de dados do ePO.
3. Na janela objeto Explorer, expanda o Bancos de dados node.
4. Clique com o botão direito do mouse no ePO_<server name> entrada.
5. Selecionar Propriedades. A janela Propriedades do banco de dados é aberta.
6. Clique em Options na guia Selecionar uma página na área do painel esquerdo.
7. Clique na seta suspensa à direita da Modelo de recuperação e selecione Simples.
8. Clique em OK.

Quando você encolhe a arquivo de dados, as páginas no final da arquivo de dados são movidas para o início do arquivo. Essa ação ignora qualquer fragmentação possível que seja introduzida nesse processo.

Se o banco de dados do ePO aumentar de tamanho depois que você excluir eventos e reduzir o banco de dados, haverá necessidade de espaço para eventos enviados pelo agente. A redução dos dados arquivo após a exclusão dos eventos faz com que o arquivo aumente de volta, além de causar fragmentação. Se o espaço for uma preocupação, considere a filtragem de eventos não essenciais usando a filtragem de eventos do ePO.

NOTA: Você pode considerar a redução de arquivo de dados depois de executar muitas operações de exclusão. Por exemplo, descartar eventos antigos se você souber que não precisa desse espaço novamente para armazenar novos eventos. Caso contrário, reconstrua os índices periodicamente e filtre os eventos desnecessários usando a filtragem de eventos do ePO para evitar a captura de dados indesejados em primeiro lugar.

IMPORTANTE: Os eventos de filtragem têm um impacto direto sobre quais relatórios podem ser gerados e que usam esses eventos. Verifique se você filtrar somente os eventos que você sabe que não são necessários para os relatórios diários. Faça backup do banco de dados do ePO antes de limpar os eventos mais antigos. Para referência futura, você sempre pode restaurar o backup do banco de dados do ePO para um novo nome a fim de gerar relatórios para esse período.

Contanto que a manutenção adequada do banco de dados seja executada, como a recriação e a reorganização de índices, o tamanho do banco de dados do ePO não afeta negativamente o desempenho da consulta. Se você limpar regularmente eventos antigos, como todos os eventos com mais de três meses, usando o ePO Purge Events Server Task , o tamanho do banco de dados será estabilizado. O tamanho do banco de dados estabiliza pressupondo que as taxas de crescimento do banco de dados sejam proporcionais a entradas excluídas e a eventos mais antigos.

Você deve ter um plano de manutenção de banco de dados adequado configurado para que o desempenho do banco de dados do ePO esteja íntegro.

Crie um plano de manutenção para o banco de dados do ePO no SQL Server:

1. Clique em Todos os Programas, Microsoft SQL Server <version>, SQL Server Management Studio.
2. Selecione o Autenticação Digite (Windows ou SQL Server) e clique em Conectar para efetuar logon na instância do SQL Server que hospeda o banco de dados do ePO.
3. Expandir Gerenciamento na janela do objeto do servidor Explorer.
4. Clique com o botão direito Planos de manutenção e selecione Assistente de plano de manutenção.
5. Digite um nome para o plano de manutenção (por exemplo, planos de manutenção do banco de dados do ePO).
6. Altere o agendamento. Clique em Alterar e, em seguida, clique em Avançar.
   NOTA: Programe a tarefa para que ela seja executada durante horários que não sejam picos, por exemplo, uma tarefa recorrente a cada sábado às 11 da noite.
   
7. Selecione as seguintes opções em Tarefas de manutenção e clique em Avançar:
   • Verificar integridade do banco de dados
   • Recriar índice
   • Backup do banco de dados (completo)
     
8. Defina a ordem das tarefas a serem executadas da seguinte maneira e clique em Avançar:
   • Verificar integridade do banco de dados
   • Backup do banco de dados (completo)
   • Recriar índice
   NOTA: Essas tarefas podem ser intercambiáveis em termos da ordem em que elas são executadas. Crie um backup de banco de dados antes do processo de recompilação do índice. Essa configuração garante que haja uma cópia de backup do banco de dados em funcionamento, se houver um problema durante o processo de reconstrução.
   
9. Definir uma Verificar integridade do banco de dados TaskId
   1. Selecione o banco de dados do ePO ePO_<servername>.
   2. Selecionar Incluir índices.
   3. Clique em Avançar.
      
10. Definir uma Backup do banco de dados (completo) TaskId
    1. Selecione o banco de dados do ePO ePO_<servername>.
    2. Digite o local do caminho de backup.
    3. Na guia Definir compactação de backup menu suspenso, selecione Compactar backup.
    4. Clique em Avançar.
       
11. Definir uma Recriar índice TaskId
    1. Selecione o banco de dados do ePO ePO_<servername>.
    2. Clique em Objeto: tabelas e exibições.
    3. Clique em Alterar o espaço livre por porcentagem de página para: 10%.
    4. Em opções avançadas, selecione Manter índice on-line ao reindexar.
       NOTA: Todas as edições do SQL Server não são compatíveis com a recompilação de índices on-line. Para obter mais detalhes sobre quais edições são compatíveis com a recompilação de índice on-line, consulte a documentação do SQL Server livros on-line.
       
    5. Para tipos de índice que não suportam recompilações de índice on-line, selecione a opção Recompilação de índices off-line.
    6. Clique em Avançar.
       
       NOTA: Uma tarefa de recriação de índice faz com que as estatísticas sejam atualizadas como parte da reconstrução efetivamente com uma varredura completa. Portanto, um Atualizar estatísticas a tarefa não é necessária após um índice de recriação.
       
12. Definidos Selecionar opções de relatório:
    1. Selecionar Gravar um relatório em um arquivo de texto e digite o local da pasta em que você deseja.
    2. Clique em Avançar.
    3. Clique em Concluir.

• o ePO 5.10 tem dois bancos de dados SQL exclusivos, o banco de dados primário e o novo banco de base de eventos do ePO.
• Os bancos de dados de eventos principal e do ePO devem ser mantidos usando as etapas descritas neste artigo.
• A execução do script abaixo apenas no banco de dados primário permite que o banco de dados de eventos do ePO fique fragmentado ao longo do tempo. Isso leva a possíveis problemas de desempenho. Para obter mais informações sobre o banco de dados de eventos do ePO, consulte KB91176-novo banco de dados de eventos do ePO e o modelo de recuperação recomendado para o ePolicy Orchestrator 5.10.

• Se a fragmentação estiver entre 20% e 30%, reorganize o índice.
• Se a fragmentação for > 30%, reconstrua o índice.

Você pode personalizar ainda mais o script para incluir a opção de executar uma recriação de índices on-line. A recriação on-line fornece mais simultaneidade durante a reconstrução do índice e usa uso intensivo de recursos. Esse recurso não está disponível em todas as edições do SQL Server. Consulte a documentação dos manuais on-line sobre a qual as edições oferecem suporte ao recurso de recriação de índices on-line.