Histórico da Página

Existe um recurso no SQL Server que é o “Recovery model”. Ele é responsável por determinar como será tratado o log das transações, entre outras coisas.

Recomendamos que antes de iniciar uma conversão este parâmetro seja marcado com a opção “Simple”.

Image Added

1) Simple. Quando o Recovery está simples, o SQL faz um TRUNCATE LOG ON CHECKPOINT, ou seja, o log é zerado a cada checkpoint. Isso significa que seu log não cresce, mas você não consegue recuperar o banco no momento da falha, pois não há log para backup (está sempre ZERADO).

2) Full. Nesse caso tudo é gravado. Inclusive o Checkpoint fica registrado no log. Você poderá fazer backup do log e ainda recuperar o servidor no momento de uma falha. O problema é que o Log cresce muito e você deve monitorar esse crescimento para não consumir seu disco e parar o banco.

3) BULK-LOGGED é um intermediário. Esse é usado quando vamos inserir registros em lotes e que não precisa de muita informação no log pois os dados vem de fontes externas como TXT, XML ou outro banco. Esse também não te dá suporte a restore no ponto de falha. Lembra do comando BULK INSERT ? Então, é para esse tipo de operação.

Dois recursos poderão ajudar em várias análises de conversão. É comum alguma conversão demorar na migração de dados de algumas tabelas, e são problemas de desempenho que só vamos identificar em processos de migração de dados, às vezes não seriam detectados na utilização do próprio ERP.

O primeiro recurso é o DBCC, este comando do SQL Server desfragmenta os dados de uma tabela. É normal que ao longo do tempo inserções e deleções impliquem em fragmentação da tabela. Principalmente se for uma tabela com muitos milhões de registros.

Durante o processo de conversão de um cliente, a tabela ULOGALTSTATUSDISC, de log de notas, possuía 3,5 milhões de registros, e a consulta aplicada a esta tabela pelo Conversor estava gastando muito tempo. Após analisar a consulta e alterar algumas coisas, mesmo assim a consulta ainda gastava muito tempo.

Então foi feita a desfragmentação da tabela ULOGALTSTATUSDISC, de vários minutos a consulta passou a ser executada em apenas 11 segundos.

Como exemplo vamos analisar a tabela “ULOGALTSTATUSDISC”:

- Analisar a tabela através do comando DBCC SHOWCONTIG(ULOGALTSTATUSDISC)

Image Added

Observações: Cada “Extents Scanned” armazena oito páginas, isso daria um total de 18960 páginas (2370 x 8), sendo que estão sendo utilizadas 10297 páginas (Pages Scanned), ou seja, esta tabela possui desfragmentação, pois está sendo alocadas 18960 páginas para armazenar 10297 páginas. Os indicadores “Scan Density” e “Avg.

Page Density” quanto mais próximo de 100% melhor a fragmentação da tabela.

- Executar o desfragmentador através do comando DBCC DBREINDEX(ULOGALTSTATUSDISC)

- Analisando a tabela novamente

Image Added

O segundo recurso é a procedure “RMAtualizaEstatisticas”, que também pode ajudar na performance, pois a mesma atualiza os índices das tabelas do ERP.

Image Added

Tabelas que o comando pode ser executado, para melhor performance.

DBCC DBREINDEX(EALUNOS)

GO

DBCC DBREINDEX (UMATRICPL)

GO

DBCC DBREINDEX (UMATALUN)

GO

DBCC DBREINDEX (ULISTAPRESENCA)

GO

DBCC DBREINDEX (EALTNOTA)

GO

DBCC DBREINDEX (EDESCLAN)

GO

DBCC DBREINDEX (EALUSERV)

GO

DBCC DBREINDEX (EETAPAS)

GO

DBCC DBREINDEX (UPLANOAULA)

GO

DBCC DBREINDEX (EMODCONTR)

GO

DBCC DBREINDEX (UDEFGRADE)

GO

DBCC DBREINDEX (EHISTMAT)

GO

DBCC DBREINDEX (UMATTURMA)

GO

DBCC DBREINDEX (EPROVAS)

GO

DBCC DBREINDEX (ETURMAS)

GO

DBCC DBREINDEX (ULOGALTSTATUSDISC)

GO

DBCC DBREINDEX (EALUNOTPR)

GO

Configurações do BDE

É recomendado que os valores sejam alterados.

CONFIGURATION > DRIVERS > NATIVE > MSSQL > CONNECT TIMEOUT para 900 e TIMEOUT para 210000.

Image Added