Banco De Dados Gigante (.mdf)

[silvafelipe]

Boa tarde pessoal,

aqui na empresa utilizamos o RM apenas para a solução de BI, ou seja, utilizamos apenas o modulo de inteligência de negócios. Os logs estão desativados (tabela zlog zerada), o arquivo de logs do banco .ldf esta compactado e pequeno, porem o banco em si (CORPORERM) está pesando nada mais nada menos que 63GB , e na empresa temos apenas 15 usuários. Já olhei praticamente todos os tópicos relacionados ao assunto, rodei os scripts de compactação, atualização de estatísticas e nada resolveu. Ao selecionar as tabelas por tamanho, as duas primeiras são GDIC e GLIBRARY , existe algo para se limpar nessa tabela?

Ats,

Felipe Silva

[omar]

Boa tarde pessoal,

aqui na empresa utilizamos o RM apenas para a solução de BI, ou seja, utilizamos apenas o modulo de inteligência de negócios. Os logs estão desativados (tabela zlog zerada), o arquivo de logs do banco .ldf esta compactado e pequeno, porem o banco em si (CORPORERM) está pesando nada mais nada menos que 63GB , e na empresa temos apenas 15 usuários. Já olhei praticamente todos os tópicos relacionados ao assunto, rodei os scripts de compactação, atualização de estatísticas e nada resolveu. Ao selecionar as tabelas por tamanho, as duas primeiras são GDIC e GLIBRARY , existe algo para se limpar nessa tabela?

Ats,

Felipe Silva

Veja nas configurações dos cubos. Desmarca as opções de layout e dados por usuário.

[Jair - Fórmula]

Quais os tamanhos fisicos destas primeiras tabelas como citou ??

[silvafelipe]

Olá Omar,

obrigado pela resposta. Efetuei o seu procedimento porem o tamanho da base ainda continua grande, hoje o arquivo .mdf esta 66GB.

Olá Jair,

segue o select com as 15 primeiras tabelas:

TABELA LINHAS TAMANHO

GDIC 79238 19728

GLIBRARY 113277 10152

GLINKSREL 19578 2952

GAUTZMENU 6639 2552

QCUBODATA 13477 2000

]GUSRACTIONEXEC 5072 880

SZJCID 14193 672

DCODIFICACAOMUNICIPIO 14092 656

SZMUNICIPIOS 9408 504

DCAMPOSDIPJ 4068 368

SMECINSTITUICAO 5526 344

SZMENSAGEM 487 328

SCARTORIOMEC 7589 312

DMUNICIPIO 5561 288

GMUNICIPIO 5565 200

Obs:

Select object_name(id),rowcnt,dpages*8 as tamanho from sysindexes

where indid in (1,0) and objectproperty(id,'isusertable')=1

order by tamanho desc

Obs 2: Estou preocupado com isso pois esta quase atingindo o tamanho limite do HD onde o banco se encontra instalado.

Editado 3 de Dezembro de 2014 por silvafelipe

[Jair - Fórmula]

Clique em propriedades em cima do seu banco de dados e veja se o tamanho exagerado não está no arquivo de Log.

Se for, vc tem que dar um shrink no seu banco de dados...

Pelos tamanhos que listou acima, vc não tem nada exagerado no seu banco RM não, ok?

[silvafelipe]

Oi Jair,

o arquivo de log já esta compactado, tem menos de 1GB, no meu caso é o arquivo do banco mesmo .mdf que esta com 66GB. Como havia falado antes, nós utilizamos apenas a rotina de inteligencia de negócios com alguns cubos, no máximo uns 30. O banco inicialmente tinha menos de 2 GB e dentro de 1 ano cresceu tudo isso. Estou achando que pode ser aqueles históricos (Ultimas atualizações) que ficam quando a gente atualiza um cubo, mas não sei onde fica isso no banco e nem como desativar, é a única informação que é gerada em grande escala. Fora isso não sei o que pode ser.

Clique em propriedades em cima do seu banco de dados e veja se o tamanho exagerado não está no arquivo de Log.

Se for, vc tem que dar um shrink no seu banco de dados...

Pelos tamanhos que listou acima, vc não tem nada exagerado no seu banco RM não, ok?

[omar]

Veja as tabelas Qcubo*.* São nelas que estão armazenadas as informações dos cubos. Qualquer alteração, faça primeiro num backup.

Rode um shrink depois de esvaziar alguma tabela. Tem uma das tabelas que guarda os dados processados pelo cubo, pode ser limpa.

Editado 4 de Dezembro de 2014 por omar

[silvafelipe]

Boa tarde Omar,

BINGO, o meu problema estava sendo causado pela tabela QCUBODATA, deletei os dados da mesma e meu banco voltou ao normal. O problema agora é que ela continua gravando os dados e crescendo, vou ver se encontro uma maneira de desativar esse histórico de atualizações.

Muito obrigado por sua ajuda e dos demais colegas.

Ats,

Felipe silva.

Veja as tabelas Qcubo*.* São nelas que estão armazenadas as informações dos cubos. Qualquer alteração, faça primeiro num backup.

Rode um shrink depois de esvaziar alguma tabela. Tem uma das tabelas que guarda os dados processados pelo cubo, pode ser limpa.

[omar]

Boa tarde Omar,

BINGO, o meu problema estava sendo causado pela tabela QCUBODATA, deletei os dados da mesma e meu banco voltou ao normal. O problema agora é que ela continua gravando os dados e crescendo, vou ver se encontro uma maneira de desativar esse histórico de atualizações.

Muito obrigado por sua ajuda e dos demais colegas.

Ats,

Felipe silva.

Bom dia.

Esta tabela está aumentando devido às configurações do cubo. Aqui utilizamos muito os cubos, mas não deixamos os dados por usuário. Tamanho normal. Temos mais de 200 cubos ativos, sendo muito utilizados. Sempre que atualizamos os cubos, os dados antigos são removidos e os novos acrescentados.

Editado 10 de Dezembro de 2014 por omar

[Jair - Fórmula]

Oi Felipe.

Bom dia.

Que bom que resolveu o problema ai.

Só não entendi como pode ter sido essa tabela, já que no seu select analisando o tamanho das tabelas constava desta forma:

TABELA LINHAS TAMANHO

GDIC 79238 19728

GLIBRARY 113277 10152

GLINKSREL 19578 2952

GAUTZMENU 6639 2552

QCUBODATA 13477 2000

GUSRACTIONEXEC 5072 880

SZJCID 14193 672

...

[joaourpia]

Oi Felipe.

Bom dia.

Que bom que resolveu o problema ai.

Só não entendi como pode ter sido essa tabela, já que no seu select analisando o tamanho das tabelas constava desta forma:

TABELA LINHAS TAMANHO

GDIC 79238 19728

GLIBRARY 113277 10152

GLINKSREL 19578 2952

GAUTZMENU 6639 2552

QCUBODATA 13477 2000

GUSRACTIONEXEC 5072 880

SZJCID 14193 672

...

Felipe,

Também queria entender melhor esse procedimento. Conforme Jair falou sua tabela estava pequena, mas quando você deletou tinha mas arquivos? É que estou com um problema parecido.

[omar]

Felipe,

Também queria entender melhor esse procedimento. Conforme Jair falou sua tabela estava pequena, mas quando você deletou tinha mas arquivos? É que estou com um problema parecido.

Boa tarde.

Mistério... Basta limpar os dados da tabela que diminui o tamanho do banco de dados...

[Andrea Reis]

Pessoal,

tudo tranquilo? Por acaso bati o olho no título deste tópico e BD é algo que me interessa bastante, portanto me permitam dar uma contribuição para o entendimento deste "mistério".

Obviamente a quantidade de linhas de uma tabela é um bom indicador para identificarmos tabelas "problemáticas", como nossa famigerada ZLOG

Porém o tamanho em banco de dados é documento! rs

Para fazer esse tipo de verificação eu costumo utilizar a seguinte sentença:

SELECT
    OBJECT_NAME(object_id) As Tabela, Rows As Linhas,
    SUM(Total_Pages * 8) As Reservado,
    SUM(CASE WHEN Index_ID > 1 THEN 0 ELSE Data_Pages * 8 END) As Dados,
        SUM(Used_Pages * 8) -
        SUM(CASE WHEN Index_ID > 1 THEN 0 ELSE Data_Pages * 8 END) As Indice,
    SUM((Total_Pages - Used_Pages) * 8) As NaoUtilizado
FROM
    sys.partitions As P
    INNER JOIN sys.allocation_units As A ON P.hobt_id = A.container_id
GROUP BY OBJECT_NAME(object_id), Rows
ORDER BY  Reservado DESC

Que me fornece a quantidade de linhas, o espaço reservado(muito importante, pois as vezes é muito maior que o realmente utilizado), dados etc

Veja um exemplo de duas tabelas

Tabela	        Linhas	Reservado  Dados	Indice	NaoUtilizado
ZLOG	        1446124	399952	   371792	27776	384
HCFILAMENSAGEM	6292	85264	   15248	69872	144

Percebam que o tamanho de dados da tabela HCFILAMENSAGEM é mais que duas vezes superior a quantidade de linhas, enquanto que a quantidade de dados da ZLOG corresponde a cerca de 25% da quantidade de linhas.

Agora o motivo disso? simples!

A tabela ZLOG contem apenas tipo de campo varchar, int, datetime...que consomem pouco espaço em disco.

A tabela HCFILAMENSAGEM, por exemplo tem um campo que grava um xml...já deu para entender?

Com relação a tabela QCUBODATA, a mesma possui um tipo de campo de imagem, ora o que mais consome do que isto? rsrs

A sugestão para o colega Felipe, talvez seja interessante criar um job no banco para realizar a deleção de dados desta tabela com uma data de modificação maior que x dias. Lembrando que o delete aumenta o LDF, então importante fazer uma manutenção periódica do mesmo.

Com relação ao reservado que mencionei vejam o exemplo desta tabela...bom exemplo de que devemos levar em conta este item.

Tabela	        Linhas	Reservado	Dados	Indice	NaoUtilizado
GJOBXLOG	2753	149520	        320	149072	128

Espero que tenha enriquecido o tópico.

Contem sempre comigo,

Andréa Reis

Editado 20 de Fevereiro de 2015 por Andrea Reis

[Jair - Fórmula]

Muito boa a sua contribuição também Andréa. Sempre é importante informação adicional, e rica como a sua.

Obrigado.