none
SQL não apresenta erro de espaço em disco. RRS feed

  • Pergunta

  • Bom dia,
    Estou com o seguinte problema e gostaria de uma ajuda.
    Tenho uma aplicação desenvolvidada em delphi com SQLServer2000 em um servidor com 3 discos em raid 5. Fomos realizar manutenção no banco e percebemos que a unidade de D: destinada a base de dados estava sem espaço "0 de espaço". Achamos estranho pois o sistema continuava salvando os dados sem apresentar erro e conseguiamos recuperar os mesmos pela aplicação... restauramos o BKP em outra base e percebemos que o mesmo (sem problemas, sem estar corrompido, restaurando perfeitamente) só possui dados de duas semasnas atraz...O que está acontecendo? os dados estão sendo salvos? pq o SQL não apresentou erro de espaço?
    segunda-feira, 22 de fevereiro de 2010 11:15

Respostas

  • Hmm, ok,

    Veja essa madrugada se o problema ocorre.
    Uma coisa que me chamou a atenção é o seu Raid5, logfiles não devem ficar em Raid5, pode ser Raid1 ou Raid 1-0. Como está configurado o Recovery (Full, Simples, Bulk) ?

    Para checar como estão seus índices:
    DBCC SHOWCONTIG ("NOMEDATABELA")

    Para checar como estão as statics:
    DBCC SHOW_STATISTICS ("NOMEDATABELA", NOMEDOINDICE);

    Se precisar de ajuda para idenficar possíveis problemas com os comandos, poste aqui os resultados pra gente ver.

    Att,
    Ricardo Muramatsu

    http://ricardomura.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 12:39
  • Arthur_TI,

    para encontrar a causa do problema, acredito que você tenha que detectar o processo no SQL Server que está consumindo processamento.

    Como o Windows é multi-thread, um executável é executado como um único processo e todas suas atividades são divididas em threads. No SQL Server, cada processo no SQL Server é um thread no Windows e na documetação oficial não existe informação de como descobrir o trhead/processo(do SQL Server) que está gerando alto consumo.

    No entanto, existe um bom artigo sobre isso no link abaixo que pode te ajudar a detectar o problema. Eu já usei algumas vezes para descobrir processos problemáticos no SQL Server.

    http://support.microsoft.com/default.aspx/kb/117559/en-us

    Se a resposta resolveu sua questão ou problema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 13:44
  • Estranho que agora o problema aparenta ser CPU, é o mesmo processo?
    Este processo começou as 17:30 e varou a noite mantendo-se em 100% de processamento. Memória e I/O de disco não há problemas (neste caso).

    Veja se existe algum job programado para este horário.

    http://ricardomura.spaces.live.com
    segunda-feira, 1 de março de 2010 19:04

Todas as Respostas


  • Bom dia, rode a sp_spaceused na database que é armazenada nessa unidade e post o resultado aqui.
    Fabrício França Lima | MCP, MCTS, MCITP | fabricio_lima_es@hotmail.com
    segunda-feira, 22 de fevereiro de 2010 12:20
  • Bom Dia,

    Será mesmo que ele não apresentava erros ? Ou será que a aplicação "deu uma mascarada".
    Outra possibilidade é que o espaço estava vazio porque o arquivo ocupou toda a área, mas há a possibilidade do arquivo possuir espaço interno para crescimento.

    Tente criar uma tabela e inserir vários registros para verificar se realmente é gerado um erro. Visualize também as entradas no ErrorLog.

    [ ]s,

    Gustavo Maia Aguiar
    http://gustavomaiaaguiar.spaces.live.com/blog

    O cálculo do uptime, do downtime e da disponibilidade em T-SQL
    http://gustavomaiaaguiar.spaces.live.com/blog/cns!F4F5C630410B9865!952.entry


    Classifique as respostas. O seu feedback é imprescindível
    segunda-feira, 22 de fevereiro de 2010 12:53
  • Pode ser meio besta, mas quando criou o banco será que não definiram um tamanho fixo para o datafile/logfile ocupando todo o espaço em disco?
    Se for isso apesar de esquisito você não terá problemas para gravar dados, a não ser que o espaço do datafile/logfile seja totalmente utilizado.
    http://ricardomura.spaces.live.com
    segunda-feira, 22 de fevereiro de 2010 15:52
  • Bom dia pessoal,

    Seguinte, acho que fiz um diagnóstico inicial equivocado, o problema inicial era pico de processamento, o processador chegava a 100% e não baixava mais, durante o processo de manutenção, percebi a falta de espaço e logo diagnostiquei que o problema era paginação porem, já liberei espaço, já reinstalei o SQL e o problema de processamento continua.

    Obs.: O processo que conssome o processador é o SQL chegando a 560,000 k. Quando paro o SQL o processamento volta para uma média entre 5% e 8%.

    Estou rodando um performance para tentar pegar alguma coisa, alguem tem alguma sugestão?
    quarta-feira, 24 de fevereiro de 2010 12:07
  • Arthur,

    Você consegue identificar se o problema ocorre durante algum tipo de workload ou manutenção de registros? Existem locks nestes momentos?

    Qual a configuração do seu hardware? Qual a versão do S.O e do SQL ? Aplicou os SP's ? Migrou estas bases de alguma outra versão do SQL? Se sim efetuou um rebuild de indices e atualização das statistics? Como efetuou a migração?


    Att,
    Ricardo Muramatus
    http://ricardomura.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 12:18
  • O problema ocorre durante a madrugada e após as 12 hs, o que coinside nesses horarios são os planos de manutenção. Acabei de desabilita-los, inclusive o BKP, alem disso, a aplicação possui jobs de replicação que tambem desabilitei.

    A maquina é um XEON 2.0 com 1 G RAM e disco 3 discos que totalizam 75G em raid 5.
    Sistema Operacional Windows Server 2003
    Banco SQLServel 2000 SP3
    A base nunca foi migrada.

    Att,
    Arthur Souza
    quarta-feira, 24 de fevereiro de 2010 12:24
  • Hmm, ok,

    Veja essa madrugada se o problema ocorre.
    Uma coisa que me chamou a atenção é o seu Raid5, logfiles não devem ficar em Raid5, pode ser Raid1 ou Raid 1-0. Como está configurado o Recovery (Full, Simples, Bulk) ?

    Para checar como estão seus índices:
    DBCC SHOWCONTIG ("NOMEDATABELA")

    Para checar como estão as statics:
    DBCC SHOW_STATISTICS ("NOMEDATABELA", NOMEDOINDICE);

    Se precisar de ajuda para idenficar possíveis problemas com os comandos, poste aqui os resultados pra gente ver.

    Att,
    Ricardo Muramatsu

    http://ricardomura.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 12:39
  • Essas são as duas tabelas mais utilizadas do banco:


    Tabela 1
    DBCC SHOWCONTIG scanning 'educMat' table...
    Table: 'educMat' (1029682816); index ID: 0, database ID: 9
    TABLE level scan performed.
    - Pages Scanned................................: 2535
    - Extents Scanned..............................: 379
    - Extent Switches..............................: 378
    - Avg. Pages per Extent........................: 6.7
    - Scan Density [Best Count:Actual Count].......: 83.64% [317:379]
    - Extent Scan Fragmentation ...................: 80.74%
    - Avg. Bytes Free per Page.....................: 220.3
    - Avg. Page Density (full).....................: 97.28%

    Tabela 2
    DBCC SHOWCONTIG scanning 'fncCarne' table...
    Table: 'fncCarne' (77295385); index ID: 0, database ID: 9
    TABLE level scan performed.
    - Pages Scanned................................: 36146
    - Extents Scanned..............................: 4981
    - Extent Switches..............................: 4980
    - Avg. Pages per Extent........................: 7.3
    - Scan Density [Best Count:Actual Count].......: 90.72% [4519:4981]
    - Extent Scan Fragmentation ...................: 84.70%
    - Avg. Bytes Free per Page.....................: 146.9
    - Avg. Page Density (full).....................: 98.18%
    DBCC execution completed. If DBCC printed error messages, contact your system administrator.

    quarta-feira, 24 de fevereiro de 2010 12:53
  • Avg. Pages per Extent (quanto mais perto de 8 melhor)
    Logical Scan Fragmentation (quanto menor melhor)
    Extent Scan Fragmentation (quanto menor melhor)
    Avg. Page Density (full) (quanto mais perto de 100% melhor)

    Um rebuid poderia ajudar mas não acho que seja este o problema uma vez que ocorre algo durante a noite.

    Vamos aguardar essa madrugada com os serviços que você desativou, podem estar concorrendo entre si.
    No histórico dos jobs tente identificar qual problema ocorreu primeiro, possivelmente estará alí seu problema. Por exmeplo:
    Falha no backup 01:03:47
    Falha na replicação 01:05:00
    Falha na manutenção 01:02:20 **Eu começaria por aqui por ser a primeira ocorrência de falha.

    Att,
    Ricardo Muramatus

    http://ricardomura.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 13:19
  • Arthur_TI,

    para encontrar a causa do problema, acredito que você tenha que detectar o processo no SQL Server que está consumindo processamento.

    Como o Windows é multi-thread, um executável é executado como um único processo e todas suas atividades são divididas em threads. No SQL Server, cada processo no SQL Server é um thread no Windows e na documetação oficial não existe informação de como descobrir o trhead/processo(do SQL Server) que está gerando alto consumo.

    No entanto, existe um bom artigo sobre isso no link abaixo que pode te ajudar a detectar o problema. Eu já usei algumas vezes para descobrir processos problemáticos no SQL Server.

    http://support.microsoft.com/default.aspx/kb/117559/en-us

    Se a resposta resolveu sua questão ou problema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 13:44
  • exato, ele deu uma falha relacionando o msdtc, que no pouco que conhesso, está ligado ao SQLAgente e conseguentimente aos jobs, por isso que deletei todos os jobs, inclusive o de manutenção...
    quarta-feira, 24 de fevereiro de 2010 13:56
  • Não precisava deletar, era só desativar :(

    Bom eu não manjo de replicação espero ter ajudado.

    Att,
    Ricardo Muramatsu

    http://ricardomura.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 14:14
  • Amigo,

    seguem algumas imagens que ilustram meu problema... mesmo sem os jobs a memoria e o processamento estão la em cima porem, não travou ainda.
    http://img269.imageshack.us/img269/8443/screenhunter01feb241127.gif
    http://img130.imageshack.us/img130/1640/screenhunter02feb241135.gif
    http://img8.imageshack.us/img8/9546/screenhunter03feb241135.gif
    quarta-feira, 24 de fevereiro de 2010 14:38
  • Parece um problema de memória. Note que o processamento (vermelho correto?) não está sempre no topo, teve alguns picos apenas. Mas a memória (em azul certo?) esteve sempre no topo.

    Como está o Avg. Disk Queue Lengh no quadrinho Average?

    Att,
    Ricardo Muramatsu

    http://ricardomura.spaces.live.com
    quarta-feira, 24 de fevereiro de 2010 15:07
  • bom dia amigo,

    Retireios jobs e o SQL deu uma estabilizada porem, esse fim de semana ele travou novamente... estava com o performance rodando.... tenho o arquivo aqui porem, não sei como posta-lo, tem um e-mail?
    segunda-feira, 1 de março de 2010 12:43
  • ricardomuramatsu ARROBA hotmail.com

    Att,
    Ricardo Muramatsu

    http://ricardomura.spaces.live.com
    segunda-feira, 1 de março de 2010 12:46
  • Estranho que agora o problema aparenta ser CPU, é o mesmo processo?
    Este processo começou as 17:30 e varou a noite mantendo-se em 100% de processamento. Memória e I/O de disco não há problemas (neste caso).

    Veja se existe algum job programado para este horário.

    http://ricardomura.spaces.live.com
    segunda-feira, 1 de março de 2010 19:04