none
Maintenance Plans - Dúvida RRS feed

  • Pergunta

  • Estou fazendo uns planos de manutenção para os servidores SQL Server 2008 (BUILD - 10.0.5500.0 / SP3), e todas as bases estão em Simple. Fiz um plano de manutenção diário (1:00AM) onde ele realiza as seguintes etapas:

    1 - Reorganize Index Task ( All Databases  / Compact Large Objects)

    2 - Check Database Integrity Task (All Databases / Include Indexes)

    3 - Execute T-SQL Statement Task (Onde faz o shrink dos arquivos .mdf e .ldf, o codigo encontra-se no final do post)

    4 - Back Up Database Task (All Databases / FULL)

    5 - Maintenance Cleanup Task (para limpar os arquivos de back up "older than 3 days")

    6 - History Cleanup Task (para limpar todos os dados de historico "older than 4 weeks")

     

    Alem deste Maintenance Plan  eu criei outro plano onde é executado apenas aos domingos (12:00PM):

     

    1 - Rebuild Index Task (All Databases / Reorgaize pages with the default amount of free space / Sort results in tempdb)

    2 - Update Statistics Task (All Databases / All existing statistics / Full Scan)

     

    Agora vamos as dúvidas:

    1 - Alguem aqui é perito o suficiente para dizer se falta alguma coisas nos planos de manutenção ou se eles estão ok?

    2 - É preciso fazer um Update Statistics após o "Reorganize Index"? Ou apenas após o "Rebuild Index"(como estou fazendo)?

    3 - Tenho uma duvida sobre os Maintenance Plans: No fluxo caso o segundo passo falhe ele irá realizar os proximos? Caso não, ele fará Rollback no 1º? Ou seja se algum passo falhar o que foi feito anteriormente foi commitado? E o posterior não será feito?

    4 - Eu coloquei o Reorganize index diariamente pois é menos custoso e o Rebuild index, que é mais custoso, apenas aos domingos que quase ninguém faz acesso às bases. Foi um bom planejamento?

    5 - O shrink deve ser feito antes do back up correto? Até para que o arquivo de back up fique menor né? Ou deveria ser feito depois por motivo de segurança?

     

     

    Segue abaixo o T-SQL do passo 3 do 1º plano de execução, para análise e para se alguem quiser utiliza-lo(Shrink dos arquivos .mdf e .ldf de todas as bases da instância):

     

    --  This script shrinks all the databases in the instance

    use master

    DECLARE @Statement varchar (2000)

     

    SELECT @Statement = ''

    SELECT @Statement = 'DBCC SHRINKDATABASE(?, NOTRUNCATE)'

     

    EXEC sp_MSforeachdb @command1=@Statement

    GO

     

    use master

    DECLARE @Statement varchar (2000)

     

    SELECT @Statement = ''

    SELECT @Statement = 'DBCC SHRINKDATABASE(?, TRUNCATEONLY)'

     

    EXEC sp_MSforeachdb @command1=@Statement

    GO

     

    --  This script shrinks the log file for all the databases in the instance

    use master 

    DECLARE @Statement varchar (2000)

     

    SELECT @Statement = ''

    SELECT @Statement = @Statement + 'USE ?; '

    SELECT @Statement = @Statement + 'SELECT ''?''; '

    SELECT @Statement = @Statement + 'DECLARE @Log_Logical_FileName varchar (60); '

    SELECT @Statement = @Statement + 'SELECT @Log_Logical_FileName = rtrim(name)  FROM dbo.sysfiles WHERE (status & 0x40) <> 0; '

    SELECT @Statement = @Statement + 'dbcc shrinkfile (@Log_Logical_FileName, 1,truncateonly); '

    SELECT @Statement = @Statement + 'SELECT fileid, name, filename, size, growth, status, maxsize FROM dbo.sysfiles WHERE (status & 0x40) <> 0; '

    SELECT @Statement 

     

    EXEC dbo.sp_MSforeachdb @command1=@Statement

    GO

    --  This script shrinks the data file for all the databases in the instance

    use master 

    DECLARE @Statement varchar (2000)

     

    SELECT @Statement = ''

    SELECT @Statement = @Statement + 'USE ?; '

    SELECT @Statement = @Statement + 'SELECT ''?''; '

    SELECT @Statement = @Statement + 'DECLARE @Data_Logical_FileName varchar (60); '

    SELECT @Statement = @Statement + 'SELECT @Data_Logical_FileName =  rtrim(name)  FROM dbo.sysfiles WHERE (status & 0x40) = 0; '

    SELECT @Statement = @Statement + 'dbcc shrinkfile (@Data_Logical_FileName, 1,truncateonly); '

    SELECT @Statement = @Statement + 'SELECT fileid, name, filename, size, growth, status, maxsize FROM dbo.sysfiles WHERE (status & 0x40) = 0; '

    SELECT @Statement 

     

    EXEC dbo.sp_MSforeachdb @command1=@Statement

    GO

     


    • Editado Igor Auler sexta-feira, 27 de janeiro de 2012 20:09
    sexta-feira, 27 de janeiro de 2012 20:08

Respostas

  • Boa Tarde

    1- Também seria perda de tempo fazer o SHRINK DATABASE ANTES de reorganizar ou recriar os índices ?
    Considerando que a recriação pode fazer com que o MDF aumente, é sim um perda de tempo. Na verdade não se trata de ser antes ou depois. O SHRINK normalmente é perda de tempo. Você irá encolher seu banco para deixar ao tamanho mínimo e aí durante a semana ele cresce de novo. Aí você reduz, aí ele cresce, aí você reduz, aí ele cresce. Esse brincadeira de estica e puxa é perda de tempo, pois, você gasta recursos de processamento e contribui para a fragmentação do arquivo já que a cada crescida o arquivo não necessariamente irá crescer contiguamente

    2 - Tambem é perda de tempo fazer SHRINK do LOG ?
    Ao meu ver, se você precisa fazer muitos SHRINKs de LOG há uma falta de planejamento ou previsibilidade do ambiente. Se o log cresceu, é porque foi mal dimensionado ou porque a frequência com que está sendo backupeado não é suficiente. Ainda assim, efetuar o SHRINK do LOG é muito menos prejudicial do que o dos dados

    3 - Afinal, é perda de tempo fazer update statics após o REBUILD? E após o Reorganize ?
    É perda de tempo você atualizar as estatísticas que já foram contempladas pelos índices. Você deveria atualizar somente as que não fazem parte. Nunca testei o efeito no REORGANIZE, mas creio que ele não atualiza as estatísticas

    4 - Por isto eu coloquei o REORGANIZE diariamente e o REBUILD apenas aos domingos. Para que os indices não se desfragmentem muito. Isto tambem seria perda de tempo ?
    A questão não é achar que o REBUILD é mais pesado ou restritivo e sim quando cada um deve ser utilizado. Use o REBUILD para  tabelas muito fragmentados e REORGANIZE para índices ou tabelas pouco fragmentadas. Pode ser que durante a semana uma determinada tabela não se fragmente muito e aí o REORGANIZE é mais interessante (mesmo no fim de semana). Pode ser também que em um único dia, um determinado índice fragmente-se demais e aí o REBUILD faz-se necessário mesmo que diariamente. A regra que dita é o índice e não o tempo.

    5 - Sobre o SHRINK dos arquivos de log (.ldf) eu deveria fazer antes do backup correto ?
    Tire o backup de log que você não precisará fazer o SHRINK. O backup de log irá liberar a área interna do arquivo (mesmo sem devolver para o SO). Isso permitirá que novas transações sejam arquivadas no log sem fazer ele crescer. Fazer o SHRINK antes do log é perda de tempo, pois, se o arquivo estiver cheio, o SHRINK não funciona e se o arquivo estiver vazio, o SHRINK vai reduzir e depois ele precisará crescer de novo.

    6 - O SHRINK é feito diario e não apenas aos domingos.
    Isso é ruim. Se aos fins de semana já é péssimo que dirá diariamente. Retire isso do seu plano e mantenha o SHRINK dos logs apenas se for realmente necessário, ou seja, quando o backup de log não dá vazão.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Igor Auler terça-feira, 31 de janeiro de 2012 12:24
    segunda-feira, 30 de janeiro de 2012 14:47
    Moderador
  • Boa Noite,

    1 - O REBUILD Online faz o mesmo efeito do REBUILD tradicional? Caso faça, é sempre bom fazer o online correto?
    O resultado final é o mesmo, mas o meio é diferente. O REBUILD ONLINE terá um impacto bem menor em relação à concorrência já que permitirá o acesso aos índices e tabelas mesmo durante o REBUILD (apenas por um momento há um bloqueio). Já o REBUILD tradicional (Offline) impede o acesso ao índice durante o REBUILD, mas exigirá menos recursos de processamento e TempDB. Se puder fazer offline ótimo, senão puder, faça ONLINE.
     
    2 - Todas as bases aqui estão em recovery model = simple. Faço um Backup full em todos databases, diariamente, este processo tambem faz o backup do Log correto? Caso sim, quando ele faz este backup ele limpa o arquivo de log(zera)? É como se fosse um SHRINK? Por isto não preciso fazer o SHRINK do arquivo .ldf? Estou com duvida nesta parte.
    Se você tem as bases em RECOVERY MODEL SIMPLE não há sentido fazer backups de log (nem é possível backupear o log com esse RECOVERY MODEL). No RECOVERY MODEL SIMPLE, a cada CHECKPOINT, o SQL Server retira as transações do LOG deixando área livre dentro do arquivo. Se você  tiver um tamanho adequado, nunca precisará fazer o SHRINK, pois, a cada CHECKPOINT o SQL Server irá deixar o arquivo livre evitando que ele cresça. Usar o SHRINK no log nesse caso é perda de tempo. Se o arquivo cresceu (mesmo o SQL Server limpando-o), é porque ele realmente precisou de toda aquela área e provavelmente irá crescer de novo. Usar o SHRINK é manter uma queda de braço desnecessária, pois, é você reduzindo e o banco aumentando. Pra que ? Só pra desperdiçar processamento e fazer uma falsa economia de espaço, pois, o disco continuará tendo a mesma vida útil e você já pagou pelo espaço (usando ou não).

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 31 de janeiro de 2012 02:01
    Moderador
  • Boa Tarde,

    Ao meu ver você está desperdiçando tempo e recursos de processamento.
    Colocar o SHRINK após o Reorganize ou o Rebuild é o maior pecado capital que se pode cometer nas rotinas de manutenção.

    Maiores detalhes em:

    Here's a good reason not to run SHRINKDATABASE...
    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/13/629059.aspx

    Agora vamos às dúvidas:

    1 - Alguem aqui é perito o suficiente para dizer se falta alguma coisas nos planos de manutenção ou se eles estão ok?
    O SHRINK está sobrando. Retire-o do plano.
    Enquanto você puder atualizar as estatísticas de forma FULL é ótimo. Mas uma hora seu plano vai ficar bem demorado se as tabelas crescerem além da conta
     
    2 - É preciso fazer um Update Statistics após o "Reorganize Index" ? Ou apenas após o "Rebuild Index"(como estou fazendo)?
    http://sqlserverpedia.com/blog/sql-server-bloggers/update-statistics-before-or-after-an-index-rebuild/

    3 - Tenho uma duvida sobre os Maintenance Plans: No fluxo caso o segundo passo falhe ele irá realizar os proximos? Caso não, ele fará Rollback no 1º? Ou seja se algum passo falhar o que foi feito anteriormente foi commitado? E o posterior não será feito?
    O plano é um pacote SSIS. Tudo vai depender do que você está montando. Você pode optar por continuar após a falha da primeira tarefa ou não. No caso de falhas, não haverá rollback de tudo (seria um enorme desperdício)
     
    4 - Eu coloquei o Reorganize index diariamente pois é menos custoso e o Rebuild index, que é mais custoso, apenas aos domingos que quase ninguém faz acesso às bases. Foi um bom planejamento?
    Não necessariamente. O Reorganize só é menos custoso que o Rebuild se a fragmentação estiver baixa. Tabelas muito fragmentadas vão gastar mais tempo com o Reorganize do que com o Rebuild. O Rebuild OnLine não provocará o mesmo impacto que o Rebuild tradicional e pode ser usado mesmo com mais usuários utilizando. Claro que se você puder diminuir a frequência é um bom sinal.
     
    5 - O shrink deve ser feito antes do back up correto? Até para que o arquivo de back up fique menor né? Ou deveria ser feito depois por motivo de segurança?
    O SHRINK não deve ser feito. Pra que encolher no fim de semana algo que vai crescer durante a semana ? Perda de tempo...

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    sábado, 28 de janeiro de 2012 20:41
    Moderador

Todas as Respostas

  • Boa Tarde,

    Ao meu ver você está desperdiçando tempo e recursos de processamento.
    Colocar o SHRINK após o Reorganize ou o Rebuild é o maior pecado capital que se pode cometer nas rotinas de manutenção.

    Maiores detalhes em:

    Here's a good reason not to run SHRINKDATABASE...
    http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/06/13/629059.aspx

    Agora vamos às dúvidas:

    1 - Alguem aqui é perito o suficiente para dizer se falta alguma coisas nos planos de manutenção ou se eles estão ok?
    O SHRINK está sobrando. Retire-o do plano.
    Enquanto você puder atualizar as estatísticas de forma FULL é ótimo. Mas uma hora seu plano vai ficar bem demorado se as tabelas crescerem além da conta
     
    2 - É preciso fazer um Update Statistics após o "Reorganize Index" ? Ou apenas após o "Rebuild Index"(como estou fazendo)?
    http://sqlserverpedia.com/blog/sql-server-bloggers/update-statistics-before-or-after-an-index-rebuild/

    3 - Tenho uma duvida sobre os Maintenance Plans: No fluxo caso o segundo passo falhe ele irá realizar os proximos? Caso não, ele fará Rollback no 1º? Ou seja se algum passo falhar o que foi feito anteriormente foi commitado? E o posterior não será feito?
    O plano é um pacote SSIS. Tudo vai depender do que você está montando. Você pode optar por continuar após a falha da primeira tarefa ou não. No caso de falhas, não haverá rollback de tudo (seria um enorme desperdício)
     
    4 - Eu coloquei o Reorganize index diariamente pois é menos custoso e o Rebuild index, que é mais custoso, apenas aos domingos que quase ninguém faz acesso às bases. Foi um bom planejamento?
    Não necessariamente. O Reorganize só é menos custoso que o Rebuild se a fragmentação estiver baixa. Tabelas muito fragmentadas vão gastar mais tempo com o Reorganize do que com o Rebuild. O Rebuild OnLine não provocará o mesmo impacto que o Rebuild tradicional e pode ser usado mesmo com mais usuários utilizando. Claro que se você puder diminuir a frequência é um bom sinal.
     
    5 - O shrink deve ser feito antes do back up correto? Até para que o arquivo de back up fique menor né? Ou deveria ser feito depois por motivo de segurança?
    O SHRINK não deve ser feito. Pra que encolher no fim de semana algo que vai crescer durante a semana ? Perda de tempo...

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    sábado, 28 de janeiro de 2012 20:41
    Moderador
  • Bom dia Gustavo,

                    1- Sobre o SHRINK: o link que você me passou é muito interessante, mas pelo que entendi é total perda de tempo fazer o SHRINK APÓS um reorganize ou rebuild index. A dúvida é: També seria perda de tempo fazer o SHRINK DATABASE ANTES de reorganizar ou recriar os indices?

                     O artigo fala sobre shrink DATABASE, desculpe se estou falando besteira, mas no script de SHRINK que eu coloquei, ele tambem faz SHRINK do Log(.ldf) , portanto, tambem é perda de tempo fazer SHRINK do LOG? (acredito que não né?)

    ---Qual a diferença ntre SHRINK DATABASE, e os SHRINKs de arquivos de data(.mdf) e de log(.ldf)?

     

                   2 - Excelente post, porem ele só fala sobre REBUILD index, gostaria de saber se após o REORGANIZE index também é preciso fazer update statics? O Rebuild pelo que entendi ele já faz o update statics automaticamente nas estatisticas que fazem parte de um indice, mas não nas que não fazem parte. Mas eu deveria rodar um update statics após o Rebuild para atualizar as estatísticas que não fazem parte de indices ou é perda de tempo também?

                       Afinal, é perda de tempo fazer update statics após o REBUILD? E após o Reorganize?

     

                    3 - Agora que eu vi que posso editar nas setas. O completion seria , ir para o próximo passo em caso de sucesso ou falha, correto?

                    4 - "Não necessariamente. O Reorganize só é menos custoso que o Rebuild se a fragmentação estiver baixa." Por isto eu coloquei o REORGANIZE diariamente e o REBUILD apenas aos domingos. Para que os indices não se desfragmentem muito. Isto tambem seria perda de tempo? Eu deveria fazer apenas REBUILD(caso a fragmentação esteja muito alta) ou REORGANIZE (Caso a fragmentação esteja baixa). Seria isto? E indiferentemente de qual abordagem eu utilize, eu não deveria fazer isto diariamente?

                     5 - Sobre o SHRINK dos arquivos de log (.ldf) eu deveria fazer antes do backup correto? ( E agora antes do rebuild ou reorganize index pelo que eu entendi né?)

    "Pra que encolher no fim de semana algo que vai crescer durante a semana ?"  O SHRINK é feito diario e não apenas aos domingos. Não sei se você entendeu direito mas eu tenho uma rotiana diária e outra apenas aos domingos como descirito no primeiro post do topico.

     

    Obrigado pela atenção.




    • Editado Igor Auler segunda-feira, 30 de janeiro de 2012 14:23
    segunda-feira, 30 de janeiro de 2012 14:07
  • Boa Tarde

    1- Também seria perda de tempo fazer o SHRINK DATABASE ANTES de reorganizar ou recriar os índices ?
    Considerando que a recriação pode fazer com que o MDF aumente, é sim um perda de tempo. Na verdade não se trata de ser antes ou depois. O SHRINK normalmente é perda de tempo. Você irá encolher seu banco para deixar ao tamanho mínimo e aí durante a semana ele cresce de novo. Aí você reduz, aí ele cresce, aí você reduz, aí ele cresce. Esse brincadeira de estica e puxa é perda de tempo, pois, você gasta recursos de processamento e contribui para a fragmentação do arquivo já que a cada crescida o arquivo não necessariamente irá crescer contiguamente

    2 - Tambem é perda de tempo fazer SHRINK do LOG ?
    Ao meu ver, se você precisa fazer muitos SHRINKs de LOG há uma falta de planejamento ou previsibilidade do ambiente. Se o log cresceu, é porque foi mal dimensionado ou porque a frequência com que está sendo backupeado não é suficiente. Ainda assim, efetuar o SHRINK do LOG é muito menos prejudicial do que o dos dados

    3 - Afinal, é perda de tempo fazer update statics após o REBUILD? E após o Reorganize ?
    É perda de tempo você atualizar as estatísticas que já foram contempladas pelos índices. Você deveria atualizar somente as que não fazem parte. Nunca testei o efeito no REORGANIZE, mas creio que ele não atualiza as estatísticas

    4 - Por isto eu coloquei o REORGANIZE diariamente e o REBUILD apenas aos domingos. Para que os indices não se desfragmentem muito. Isto tambem seria perda de tempo ?
    A questão não é achar que o REBUILD é mais pesado ou restritivo e sim quando cada um deve ser utilizado. Use o REBUILD para  tabelas muito fragmentados e REORGANIZE para índices ou tabelas pouco fragmentadas. Pode ser que durante a semana uma determinada tabela não se fragmente muito e aí o REORGANIZE é mais interessante (mesmo no fim de semana). Pode ser também que em um único dia, um determinado índice fragmente-se demais e aí o REBUILD faz-se necessário mesmo que diariamente. A regra que dita é o índice e não o tempo.

    5 - Sobre o SHRINK dos arquivos de log (.ldf) eu deveria fazer antes do backup correto ?
    Tire o backup de log que você não precisará fazer o SHRINK. O backup de log irá liberar a área interna do arquivo (mesmo sem devolver para o SO). Isso permitirá que novas transações sejam arquivadas no log sem fazer ele crescer. Fazer o SHRINK antes do log é perda de tempo, pois, se o arquivo estiver cheio, o SHRINK não funciona e se o arquivo estiver vazio, o SHRINK vai reduzir e depois ele precisará crescer de novo.

    6 - O SHRINK é feito diario e não apenas aos domingos.
    Isso é ruim. Se aos fins de semana já é péssimo que dirá diariamente. Retire isso do seu plano e mantenha o SHRINK dos logs apenas se for realmente necessário, ou seja, quando o backup de log não dá vazão.

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    • Marcado como Resposta Igor Auler terça-feira, 31 de janeiro de 2012 12:24
    segunda-feira, 30 de janeiro de 2012 14:47
    Moderador
  • Gustavo,

            muito obrigado, você em ajudou muito. Gostaria de tirar mais 2 dúividas:

    1 - O REBUILD Online faz o mesmo efeito do REBUILD tradicional? Caso faça, é sempre bom fazer o online correto?

     

    2 - Todas as bases aqui estão em recovery model = simple. Faço um Backup full em todos databases, diariamente, este processo tambem faz o backup do Log correto? Caso sim, quando ele faz este backup ele limpa o arquivo de log(zera)? É como se fosse um SHRINK? Por isto não preciso fazer o SHRINK do arquivo .ldf? Estou com duvida nesta parte.

     

    Obrigado pela ajuda.

    segunda-feira, 30 de janeiro de 2012 17:09
  • Boa Noite,

    1 - O REBUILD Online faz o mesmo efeito do REBUILD tradicional? Caso faça, é sempre bom fazer o online correto?
    O resultado final é o mesmo, mas o meio é diferente. O REBUILD ONLINE terá um impacto bem menor em relação à concorrência já que permitirá o acesso aos índices e tabelas mesmo durante o REBUILD (apenas por um momento há um bloqueio). Já o REBUILD tradicional (Offline) impede o acesso ao índice durante o REBUILD, mas exigirá menos recursos de processamento e TempDB. Se puder fazer offline ótimo, senão puder, faça ONLINE.
     
    2 - Todas as bases aqui estão em recovery model = simple. Faço um Backup full em todos databases, diariamente, este processo tambem faz o backup do Log correto? Caso sim, quando ele faz este backup ele limpa o arquivo de log(zera)? É como se fosse um SHRINK? Por isto não preciso fazer o SHRINK do arquivo .ldf? Estou com duvida nesta parte.
    Se você tem as bases em RECOVERY MODEL SIMPLE não há sentido fazer backups de log (nem é possível backupear o log com esse RECOVERY MODEL). No RECOVERY MODEL SIMPLE, a cada CHECKPOINT, o SQL Server retira as transações do LOG deixando área livre dentro do arquivo. Se você  tiver um tamanho adequado, nunca precisará fazer o SHRINK, pois, a cada CHECKPOINT o SQL Server irá deixar o arquivo livre evitando que ele cresça. Usar o SHRINK no log nesse caso é perda de tempo. Se o arquivo cresceu (mesmo o SQL Server limpando-o), é porque ele realmente precisou de toda aquela área e provavelmente irá crescer de novo. Usar o SHRINK é manter uma queda de braço desnecessária, pois, é você reduzindo e o banco aumentando. Pra que ? Só pra desperdiçar processamento e fazer uma falsa economia de espaço, pois, o disco continuará tendo a mesma vida útil e você já pagou pelo espaço (usando ou não).

    [ ]s,

    Gustavo Maia Aguiar
    Blog: http://gustavomaiaaguiar.wordpress.com
    Vídeos: http://www.youtube.com/user/gmasql


    Classifique as respostas. O seu feedback é imprescindível
    terça-feira, 31 de janeiro de 2012 02:01
    Moderador
  • Gustavo,

                 estou com problema no meu plano de manutenção e não consigo descobrir que parte do plano está dando erro. Já joguei o log do step para um arquivo a parte e amanhã terei um Log melhor(não posso executar este plano de manutenção durante o expediente). Porem minha dúvida é:

    O que seria mais correto:

    1. Criar um plano de manutenção só, cheio de setas linkando as ações;
    2. Ou criar um plano de manutenção para cada ação, e criar um job com vários Steps para que seja melhor visualizar onde está dando o problema?

    Att.

    quinta-feira, 2 de fevereiro de 2012 16:37