none
Reduzir Banco de Dados VS propriedade SIZE RRS feed

  • Pergunta

  • Boa tarde.

    Criei um plano de manutenção para reduzir automaticamente alguns BDs. Na execução do plano, ocorre o erro:

    "A propriedade Size não está disponível para Banco de dados '[TESTE]'. Talvez essa propriedade não exista para esse objeto ou não seja possível recuperá-la devido a direitos insuficientes de acesso."

    Executando o comando via QUERY "DBCC SHRINKDATABASE(N'TESTE', 10, TRUNCATEONLY)" o erro não ocorre. 

    Alguém já passou por isso?

    terça-feira, 10 de novembro de 2020 19:17

Todas as Respostas

  • Sidinei,

    Qual é a versão e edição do SQL Server que você esta utilizando?

    A conta de usuário que você esta utilizando tem permissão para realizar procedimentos de manutenção no banco de dados?


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 10 de novembro de 2020 21:52
    Moderador
  • Pedro, SQL 2017 e estou usando o sa.

    Até criei um usuário com todas as propriedades, refiz o plano e o erro permanece.

    Gerando qualquer outro evento do plano, (backup, integridade, etc) funciona perfeitamente.

    quarta-feira, 11 de novembro de 2020 13:29
  • Sidinei,

    Certo, certo, obrigado era somente para ter certeza que você estava utilizando o SQL Server e um usuário com nível de permissão suficiente.

    Vou compartilhar um exemplo para você ter um melhor entendimento:

    -- Liberando 10% do espaço final do arquivo de dados --
    DBCC ShrinkDatabase('Cipa',10)
    Go
    
    -- Diminuindo o Tamanho do Banco e liberando espaços existentes --
    DBCC ShrinkDatabase('Cipa',TruncateOnly)
    Go
    
    -- Diminuindo o Tamanho do Arquivo de Banco para 1 MB --
    DBCC ShrinkFile('Cipa_Data',1)
    Go
    
    -- Diminuindo o Tamanho do Arquivo de Banco e liberando espaços existentes --
    DBCC ShrinkFile('Cipa_Data',TruncateOnly)
    Go
    
    -- Diminuindo o Tamanho do Arquivo de Log para 1 MB --
    DBCC ShrinkFile('Cipa_LOG',1)
    Go
    
    -- Diminuindo o Tamanho do Arquivo de Log e liberando espaços existentes --
    DBCC ShrinkFile('Cipa_LOG',TruncateOnly)
    Go

    Verifique os formas de utilizar tanto o comando DBCC ShrinkDatabase e Dbcc ShrinkFile.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    quarta-feira, 11 de novembro de 2020 21:34
    Moderador
  • Pedro ou Junior Galvão rss, antes que eu esqueça, sou um fã do seu trabalho. Li muitos blogs e já utilizei muito do seu conhecimento.

    Considerando a sua resposta, tenho algumas afirmações:

    1. O comando "DBCC SHRINKDATABASE(N'TESTE', 10, TRUNCATEONLY)" foi feito pelo Plano de Manutenção e não por mim.
    2. Executando o mesmo comando via Query, não ocorre o erro;
    3. Tenho outro cenário semelhante, mesmo SQL 2017 com o login sa, gerado via plano de manutenção, onde o comando ficou "DBCC SHRINKDATABASE(N'MONITSQL', 5, TRUNCATEONLY)" e não ocorre o erro;
    4. Levei esse banco "MONITSQL" via backup para o servidor com erro, e o erro é reproduzido, então não parece ser problema no Database;
    5. Levei o banco "TESTE" do servidor com erro para o outro servidor, e o Plano de Manutenção roda sem erro;

    Já revirei a internet tentado achar algo sobre "propriedade size" ou "property size", só encontrei dicas sobre a troca do dbowner.

    Tem mais alguma dica?

    quinta-feira, 12 de novembro de 2020 14:38
  • Pedro ou Junior Galvão rss, antes que eu esqueça, sou um fã do seu trabalho. Li muitos blogs e já utilizei muito do seu conhecimento.

    Considerando a sua resposta, tenho algumas afirmações:

    1. O comando "DBCC SHRINKDATABASE(N'TESTE', 10, TRUNCATEONLY)" foi feito pelo Plano de Manutenção e não por mim.
    2. Executando o mesmo comando via Query, não ocorre o erro;
    3. Tenho outro cenário semelhante, mesmo SQL 2017 com o login sa, gerado via plano de manutenção, onde o comando ficou "DBCC SHRINKDATABASE(N'MONITSQL', 5, TRUNCATEONLY)" e não ocorre o erro;
    4. Levei esse banco "MONITSQL" via backup para o servidor com erro, e o erro é reproduzido, então não parece ser problema no Database;
    5. Levei o banco "TESTE" do servidor com erro para o outro servidor, e o Plano de Manutenção roda sem erro;

    Já revirei a internet tentado achar algo sobre "propriedade size" ou "property size", só encontrei dicas sobre a troca do dbowner.

    Tem mais alguma dica?

    Sidnei,

    Antes de mais nada muito obrigado por suas palavras, fico feliz em saber que de alguma forma estou ajudando, como também sempre aprendendo.

    Eu fiz uma pequena confusão no post anterior, pensei uma coisa e escrevi outra já aproveitei a corrigi.

    Acredito que o problema esteja justamente no login que esta sendo envolvido na execução do plano de manutenção, inclusive este foi um questionamento que eu fiz anteriormente.

    Você destacou que via query diretamente esta funcionando, então seria interessante verificar qual conta de login que esta utilizada para se executar este plano de manutenção.

    Por gentileza, você poderia executar o código abaixo:

    SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
    FROM sys.database_files;

    Através do select acima, poderemos obter informações sobre a distribuição de espaço disponível em disco para os arquivos que compõem este respectivo banco de dados.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    quinta-feira, 12 de novembro de 2020 16:21
    Moderador
  • Sidinei,

    Uma possível dica inicial seria identificar o espaço ocupado pelos arquivo de log nos respectivos bancos de dados em seu ambiente, para tal vamos utilizar o comando DBCC SQLPerf:

    DBCC SQLPERF(LOGSPACE) 
    GO  

    Depois vamos resetar as estatísticas de espera que possam estar vinculadas as questões de leitura e escrita dos arquivos de log, suspeito que possa estar acontecendo alguma contenção no TempDB, execute o comando abaixo:

    DBCC SQLPERF("sys.dm_os_wait_stats",CLEAR)
    Go
    Mais uma vez obrigado por suas palavras e desculpe-me pela "confusão" na respostas do post de ontem.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]


    quinta-feira, 12 de novembro de 2020 16:26
    Moderador
  • Veja que estranho.

    Meio dia foi reiniciado o servidor devido a uma atualização do Windows, então executei o plano novamente e funcionou. 

    Se esse procedimento resetou as estatísticas e reorganizou o tempdb, você identificou o problema. Foi isso que aconteceu?

    quinta-feira, 12 de novembro de 2020 21:08
  • Sidnei,

    Afirmar eu não posso, mas acredito que era isso mesmo.

    Que bom que deu certo.


    Pedro Antonio Galvão Junior [MVP | MCC | MSTC | MIE | MTAC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados Relacional e Data Warehouse | Professor Universitário | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    quinta-feira, 12 de novembro de 2020 21:37
    Moderador
  • Perfeito. Se voltar a ocorrer, farei o procedimento.

    Obrigado e abraço!

    sexta-feira, 13 de novembro de 2020 12:32