Mantendo os bancos de dados do Planning Server

Para cada instalação do Planning Server, há um Banco de Dados do Sistema de Planejamento (PPSPlanningSystem) e um @@@Banco de Dados do Serviço de Planejamento (PPSPlanningService).

O Banco de Dados do Sistema de Planejamento possui os seguintes componentes:

• Dados de segurança do sistema de planejamento.

• Dados de biblioteca de tipos do planejamento.

• Dados de configuração de nível de sistema do planejamento.

• Metadados de nível de aplicativo do planejamento.

O tamanho do Banco de Dados do Sistema de Planejamento e do @@@Banco de Dados do Serviço de Planejamento é pequeno e continuará relativamente pequeno.

Esses bancos de dados podem ser criados manualmente ou com a execução do Gerenciador de Configuração do Planning Server.

Se você optar pelo uso do Gerenciador de Configuração do Planning Server para criá-los para você, os bancos de dados serão colocados no grupo de arquivos principal com o tamanho padrão do arquivo de dados definido como 50 MB, com crescimento automático até 50 MB. O tamanho padrão do arquivo de log será definido como 20 MB, com crescimento automático até 20 MB.

Se você optar por criar esses dois bancos de dados manualmente, poderá escolher o grupo de arquivos e alterar as configurações padrão de tamanho do banco de dados inicial e do arquivo de log.

O SQL Server 2005 mapeia um banco de dados por um conjunto de arquivos do sistema operacional. Informações de dados e de log nunca são misturadas no mesmo arquivo e arquivos individuais são usados apenas por um banco de dados. Para obter mais informações sobre arquivos de log e de dados do banco de dados, consulte SQL Server (essa página pode estar em inglês).

Para todos os bancos de dados do Planning Server que são criados automaticamente pelo Planning Server, o tamanho inicial do arquivo de dados é definido como 50 MB, com crescimento automático de até 50 MB.

Para bancos de dados de aplicativo e de preparo, sugerimos que os administradores de bancos de dados do Planning Server do cliente façam o planejamento da capacidade e usem a diretiva de dados e retenção de dados da organização para determinar um tamanho razoável para o arquivo de dados inicial. Por exemplo, determinar quantos modelos eles esperam ter em cada site modelo e quantos sites modelo esperam ter no aplicativo.

Algumas diretrizes gerais ao criar o arquivo de dados e de log do banco de dados incluem:

• Habilitar o crescimento automático dos arquivos de dados e de log do banco de dados.

• Alocar tamanho inicial razoável para os arquivos do banco de dados e de log.

• Definir o tamanho máximo dos arquivos de dados de maneira que você não fique sem espaço quando não tiver espaço em disco (especialmente importante se você tiver vários bancos de dados).

• Definir o incremento de crescimento do arquivo de dados com tamanhos razoáveis (preferências: incremento fixo menor ou igual a 1 GB, auxiliado significativamente pela inicialização instantânea do arquivo).

• Considerar a possibilidade de permitir a inicialização instantânea dos arquivos de dados.

• Considerar o uso da tecnologia RAID nos arquivos de dados e de log.

• Alocar apenas um arquivo de log.

• Isolar o arquivo de log em uma unidade separada (para obter melhor desempenho, você deve ter os arquivos de log em um disco físico separado, em vez de em arquivos de dados).

O monitoramento do arquivo de log também é importante. Você pode monitorar o status do arquivo de log executando a seguinte consulta:

select * from 
sys.dm_os_performance_counters 
where counter_name like '%Log%'
and instance_name = 'Alpine_Ski_House_AppDB'

Para obter mais informações, consulte SQL Server (essa página pode estar em inglês).

Para reduzir o crescimento automático do arquivo de log, recomendamos a pré-alocação de um tamanho apropriado para o log. O tamanho do arquivo de log depende de dois fatores: a freqüência de backup do log e a atividade do sistema do Planning Server.

Embora a diretriz geral seja pré-alocar para um arquivo de log 10 ou 15% do arquivo de banco de dados, o tamanho real do arquivo de log depende da freqüência do backup do log.

Se você fizer backup do arquivo de log a cada cinco minutos e tiver o Planning em atividade normal, recomendados alocar o tamanho inicial do arquivo de log da seguinte maneira:

• Banco de Dados do Sistema de Planejamento: 50 MB

• @@@Banco de Dados do Serviço de Planejamento: 200 MB

• Banco de dados de aplicativo do Planning: 1 GB

• Banco de dados de preparo do Planning: 1 GB

• Banco de dados de saída do Planning: 400 MB

Você pode alterar esses números com base na freqüência de backup do log. Por exemplo, se você faz backup do log a cada 10 minutos, precisa aumentar o tamanho do arquivo de log inicial. Se você faz backup do arquivo de log a cada dois minutos, pode alocar um tamanho menor.

Além do tamanho inicial apropriado do arquivo de log, recomendamos definir o crescimento automático dele como um valor fixo (não uma porcentagem) e também a definição de um limite máximo para esse crescimento. Não defina o tamanho como crescimento irrestrito.

Reduzir o arquivo de log virtual (VLF) também é importante para o desempenho do SQL Server. Para obter mais informações sobre como realizar essa tarefa, consulte SQL Server (essa página pode estar em inglês).

É importante que você faça backup de seu arquivo de log regularmente. Em seu sistema de produção, é altamente recomendável que você programe o computador que estiver executando o SQL Server para fazer backup do log periodicamente (por exemplo, a cada 5 ou 10 minutos) para evitar a perda de dados. Se o modo de recuperação do banco de dados estiver cheio e o backup do log não for feito por um período prolongado, ele continuará a crescer até você obter o erro de log cheio.

Há sobrecarga mínima no sistema ao fazer o backup do log; portanto, os backups freqüentes não são dispendiosos. Quanto mais fragmentado estiver o arquivo de log, mais dispendioso será o backup do log. É por isso que é importante pré-alocar um tamanho razoável de arquivo de log no sistema. Isso resultará em um melhor desempenho do backup do log.

Quando um arquivo de log está cheio, a única coisa que você pode fazer é o backup do log. O backup do log limpará o log inativo e o arquivo de log reduzirá de tamanho. O backup não limpará os logs ativos, pois as transações ainda não foram confirmadas.

Em um ambiente que não seja de produção e no qual não haja preocupação em relação à perda de dados, você pode truncar o log para limpá-lo. No entanto, você só deve fazer isso em sistemas de teste, desenvolvimento ou protótipo em que a perda de dados seja aceitável.

Em sistemas de produção ou não, você deve cuidar atentamente do arquivo de log (fazer backup ou truncar); caso contrário, ele crescerá rapidamente e afetará o desempenho do sistema do Planning.

Exemplos de script

Esta seção inclui exemplos de script para fazer backup do log ou truncá-lo. É importante que você programe o computador que executa o SQL Server para executar o script a seguir. Se você estiver trabalhando em um ambiente de teste ou protótipo e não quiser perder tempo lidando com essa questão de backup ou truncamento do log, altere o modo de recuperação do banco de dados do modo padrão Full para o modo Simple modificando a página de propriedades do banco de dados no SQL Server Management Studio.

Importante:
O modo Simple não deve jamais ser usado no sistema de produção. Para obter mais informações sobre modelos de recuperação de banco de dados, consulte SQL Server (essa página pode estar em inglês).

-- Truncate Log sample script
-- Use only if you are in testing environment and do not care about DB backup.
BACKUP LOG 'Alpine_Ski_House_AppDB WITH NO_LOG
GO
BACKUP LOG 'Alpine_Ski_House_AppDB WITH TRUNCATE_ONLY
GO

USE 'Alpine_Ski_House_AppDB
GO
EXEC sp_helpfile 
GO
-- get the log file name for this DB

-- now shrink the log file
USE 'Alpine_Ski_House_AppDB
GO
DBCC SHRINKFILE(Alpine_Ski_House_AppDB_log, TRUNCATEONLY)
GO

-- Backup log sample script
-- For any DB that you care about data loss, you should back up DB and the 
-- log, that is the only good way to clear the inactive logs.

-- Create dump devices first
EXEC sp_addumpdevice 'disk', 'ServiceDBData', 
'C:\work\ServiceDBData.bak';
GO

EXEC sp_addumpdevice 'disk', 'ServiceDBLog', 
'C:\work\ServiceDBLog.bak';
GO

-- Back up database and log file
USE PPSPlanningService
GO
BACKUP DATABASE PPSPlanningService TO ServiceDBLog;
GO
BACKUP LOG PPSPlanningService TO ServiceDBLog
GO
DBCC SHRINKFILE(PPSPlanningService_log, TRUNCATEONLY)
GO

Importante:

Você deve truncar o log em um sistema que não seja de produção ou configurar o computador que executa o SQL Server para fazer backup do log periodicamente a fim de reduzir o tamanho do arquivo de log para obter melhor desempenho e evitar a perda de dados. Se você permitir que os arquivos de log fiquem muito grandes, o desempenho do Planning Server sofrerá significativamente. Eventualmente, o crescimento do arquivo de log consumirá uma imensa quantidade de espaço em disco.

O tamanho do TempDB pode afetar o desempenho do sistema. Por exemplo, se o tamanho definido para TempDB for muito pequeno, parte do processamento da carga do sistema poderá ser executado com o crescimento automático do banco de dados até o tamanho necessário para agüentar a carga de trabalho, sempre que você reiniciar o serviço do SQL Server (MSSQLSERVER). Você pode evitar essa sobrecarga aumentando o tamanho do TempDB.

As recomendações gerais de posicionamento físico e opções de banco de dados definidos para TempDB incluem:

• Permitir que o TempDB expanda-se automaticamente conforme necessário.

• Definir o tamanho original dos arquivos do TempDB como um tamanho razoável para evitar que a expansão automática dos arquivos ocupe mais espaço que o necessário. Se o TempDB expande-se com freqüência, o desempenho pode ser afetado.

• Defina a porcentagem de incremento do crescimento do arquivo como um tamanho razoável para evitar que os arquivos do TempDB assumam um valor muito baixo. Se o crescimento for muito baixo, em comparação com a quantidade de dados gravados no TempDB, o banco de dados talvez tenha que ser constantemente expandido. Isso afetará o desempenho.

• Coloque o TempDB em um subsistema de entrada/saída rápida para garantir um bom desempenho. Divida o TempDB em vários discos para obter melhor desempenho. Coloque o TempDB em discos que sejam diferentes dos usados pelos bancos de dados de usuários. Para obter mais informações sobre como mover o TempDB para um novo local, consulte SQL Server (essa página pode estar em inglês).

Quando o SQL Server é reiniciado, o tamanho do TempDB volta ao tamanho configurado inicialmente e ele cresce conforme os requisitos. Isso pode levar à fragmentação do TempDB e pode gerar sobrecarga. Isso pode causar impacto no desempenho de sua carga de trabalho. É recomendado pré-alocar o tamanho apropriado para o TempDB.

Como os bancos de dados do Planning Server usam "read committed isolation" (isolamento de leitura confirmada) pelo recurso de controle de versão de linha, TempDB deve ter um tamanho razoavelmente grande definido para que se obtenha melhor desempenho. Para isso, defina o tamanho inicial de TempDB como no mínimo 500 MB. Defina o tamanho inicial de TempDB como 1 GB para ter um desempenho melhor ainda.

É importante monitorar o espaço livre em TempDB. Para obter mais informações, consulte SQL Server (essa página pode estar em inglês).

Você deve agrupar objetos e arquivos do banco de dados em grupos de arquivos para fins de alocação e administração.

O Banco de Dados do Sistema de Planejamento e o @@@Banco de Dados do Serviço de Planejamento podem ser criados durante a instalação do Planning Server ou podem ser provisionados manualmente pelos clientes antes de instalarem o software Planning Server. Se você deixar que o Gerenciador de Configuração do Planning Server crie esses dois bancos de dados para você, não terá a oportunidade de especificar um grupo de arquivos para eles. Esses dois bancos de dados são relativamente pequenos no tamanho e a necessidade de usar um grupo de arquivos para eles é mínima.

O banco de dados de aplicativo do Planning é criado durante o processo Create Application. Há duas opções ao criar bancos de dados de aplicativo. Os clientes podem especificar a opção Manual Execution (Execução Manual) na interface de usuário de Create Application (Criar Aplicativo) no Console de Administração do Planning para que os administradores de bancos de dados possam personalizar CREATE DATABASE/CREATE TABLE em um processo de criação de aplicativos. Especificamente, os administradores de bancos de dados podem adicionar informações do grupo de arquivos ao criarem o banco de dados de aplicativo. Após a geração dos scripts do SQL Server no processo Application Creation, os administradores de bancos de dados poderão editar os arquivos CreateAppDB.sql e TypeLibMasterSchema.sql e adicionar as informações do grupo de arquivos a esses scripts antes de executá-los.

Observação:
Você pode criar grupos de arquivos usando CREATE DATABASE ou ALTER DATABASE. Também pode especificar grupos de arquivos para tabelas usando CREATE TABLE. Ao criar novos grupos de arquivos, não esqueça de adicionar os arquivos antes de usar esses novos grupos.

Para obter mais informações sobre grupos de arquivos, consulte SQL Server (essa página pode estar em inglês).