Diminuindo o tamanho do banco de dados Dynamics AX 2012 R3

Disclaimer: Antes de mais nada é bom alertar que a solução abaixo resolveu um problema que eu tinha e não quer dizer que é uma solução pronta, utilize as orientações por sua conta e risco.


Temos uma implementação do Dynamics AX 2012 R3 a pelo menos 17 meses e temos percebido o crescimento exponencial do volume do banco de dados e com isso trouxe alguns transtornos significativos:

1. Disponibilidade de armazenamento para o banco de dados da aplicação;
2. Disponibilidade de armazenamento do backup do banco de dados;
3. Disponibilidade de armazenamento para bases de homologação e desenvolvimento;
4. Aumento do tempo de restauração de um ambiente (seja ele homologação, ou disaster recovery);
5. Aumento do tempo de realização de backup;
6. Necessidade de banda larga maior para tráfego de backup em nuvem (se aplicável);

Para diminuirmos significamente o tamanho do banco, primeiro é preciso identificar quais são as tabelas que estão impactando este crescimento, a consulta abaixo demonstra qual é o volume de informação em cada tabela do banco de dados:

SELECT
    t.NAME AS Entidade,
    p.rows AS Registros,
    SUM(a.total_pages) * 8 AS EspacoTotalKB,
    SUM(a.used_pages) * 8 AS EspacoUsadoKB,
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS EspacoNaoUsadoKB
FROM
    sys.tables t
INNER JOIN
    sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN
    sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN
    sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN
    sys.schemas s ON t.schema_id = s.schema_id
WHERE
    t.NAME NOT LIKE 'dt%'
    AND t.is_ms_shipped = 0
GROUP BY
    t.Name, s.Name, p.Rows
ORDER BY
    Registros DESC

No meu caso haviam quatro tabelas que estavam com um volume muito grande e que haveria a necessidade de analisar o que poderia ser feito:

1. SYSDATABASELOG
2. AIFDOCUMENTLOG
3. AIFMESSAGELOG
4. AIFRESPONSE

Análise e descarte:

SYSDATABASELOG
Negociado com as áreas de negócio a periodicidade necessária de guarda dos registros, decidido que parâmetros deveriam ter os logs indefinidamente e transações poderiam ter o período de apenas seis meses, exceto transações abertas de clientes e fornecedores, que também não teriam prazo definido;

AIFDOCUMENTLOG
Mantidas apenas as transações da última semana (Utilizado o campo CreatedDateTime);

AIFMESSAGELOG
Mantidas apenas as transações da última semana (Utilizado o campo CreatedDateTime)

AIFRESPONSE
Mantidas apenas as transações da última semana (Utilizado o campo CreatedDateTime)

Todo o processo de limpeza usando "DELETE FROM" do SQL é bem demorado e para alguns casos, como em uma restauração de ambiente de homologação, foi utilizado o comando "TRUNCATE TABLE" para todas as tabelas acima.

Após a limpeza dos registros desnecessários, para que o volume do banco de dados em disco diminua, é necessário realizar um "SHRINK" do banco:

Redução do arquivo de banco de dados
Usando script:

USE [NOME DA INSTÂNCIA]
GO
DBCC SHRINKFILE (N'NOME DO BANCO DO AX' , 0, TRUNCATEONLY)
GO
DBCC SHRINKFILE (N'NOME DO BANCO DO AX' , TAMANHO)
GO

Usando menus do sql server:

1. Botão direito sobre o banco de dados;
2. Clicar em tarefas/reduzir/arquivos;
3. Em tipo de arquivo, selecionar "dados"
4. Em ação de redução, colocar em reorganizar páginas antes de liberar espaço não utilizado e em "reduzir arquivo para" colocar um pouco a mais do valor mínimo indicado;

As tarefas acima irão demorar algum tempo e quando executei escolhi um horário que os usuários não estavam usando o ERP.

Criação de um novo grupo no xml da nfe

Às vezes precisamos colocar alguma informação na Danfe que não está prevista nas tags que são padrão da NFe. E na Danfe pode conter apenas informações que estão no arquivo xml.

Uma forma de implantar esta informação é através da tag , que se encontra dentro do caminho nfeProc/NFE/infNFe/infAdic;

A classe que precisa ser alterada é a EFDocMsgFormat_XmlSubmit_BR, no método abaixo:

Copiando dados da mesma tabela entre companhias

Via job:

CustTable ctA, ctIns, ctB;

container emp;

;

emp = ['empresa'];

while select crosscompany : emp ctA
{
    select ctB where
    ctB.accountnum==ctA.accountnum;

    if(!ctB)
    {
        changecompany("Empresa destino")
        {
           ctIns.data(ctA);
           ctIns.company("Empresa destino");
           ctIns.insert();
        }
    }
}

Como recuperar um banco de dados do SQL Server que está no modo suspeito

Como recuperar um banco de dados do SQL Server que está no modo suspeito:

Usar o script abaixo um de cada vez:


EXEC sp_resetstatus 'yourDBname';
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb('yourDBname')
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('yourDBname', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER


Fonte: https://community.aspnix.com/microsoft-sql-server/2881-recover-structured-query-language-server-database-suspect-mode.html

Reduzir arquivo de log (.ldf) SQL Server 2008

Passos simples para reduzir o tamanho do arquivo .LDF no SQL SERVER 2008

1º - Alterar o modelo de recuperação para "simples" (botão direito sobre a base, propriedades/opções/modelo de recuperação);

2º - Reduzir o tamanho do arquivo (botão direito sobre a base, tarefas/Reduzir/Arquivos)

• Tipo de arquivo: Log
• Ação de redução: Reorganizar páginas antes de liberar espaço não utilizado, reduzir arquivo a: "tamanho a reduzir em MB";

3º - Reduzir o tamanho máximo do arquivo de log (botão direito sobre a base, propriedades/arquivos, no tipo de arquivo de log, aumento automático clicar no botão com as reticências "...", aumento de arquivo restrito (MB): colocar o tamanho máximo que se deseja ao arquivo de log em MB

4º - Voltar 1º passo e mudar o modelo de recuperação para "Cheio";

Para acompanhar o tamanho do arquivo de log podemos utilizar o comando abaixo:
dbcc sqlperf(logspace)

Desbloquear diário de pagamentos

Em alguns casos o usuário que "marcou" o diário de pagamento para liquidação pode não trabalhar mais na empresa, neste caso é necessário "desamarrar" o diário para que outra pessoa possa fazer a baixa.

1º passo
Identificar o RECId da linha de diário bloqueada, neste caso diário de pagamentos (CustTransOpen)

2º passo
Localizar a linha correspondente na tabela SpecTrans cujo campo REFRECID seja igual ao RECID da tabela de origem

3º passo
Após fazer o backup, apagar a linha identificada da tabela SpecTrans (via SQL ou AOT).

Com isso a mãozinha vermelha que fica bloqueando o diário some e é possível fazer os lançamentos necessários.

por Josemar Xavier em 13/12/2011