SQL Server erro instalação - Updating Permission Setting for File ResumeKeyFilter.Store Failed

SQL Server erro instalação - Updating Permission Setting for File ResumeKeyFilter.Store Failed

Durante a instanlaçao de uma nova instancia SQL Server 2016 no Windows Server 2016.
Fomos surpreendidos por uma falha ate momento não esperada e desconhecida pela equipe.

Configuração de permissão para o arquivo ResumeKeyFilter.Store falhou.

Updating permission setting for file ‘H:\System Volume Information\ResumeKeyFilter.Store’ failed. The file permission setting was supposed to be set to ‘D: P(A;OICI;FA;;;BA)(A;OICI;FA;;;SY)(A;OICI;FA;;;CO)(A;OICI;FA;;;S-1-5-80-3880718306-3832830129-1677750213-2598158969-1042248003)’.
Click ‘Retry’ to retry the failed action, or click ‘Cancel’ to cancel this action and continue setup.

* Seu nome de arquivo pode variar, mas as etapas permanecem iguais.

SOLUÇÃO (Fix)

Podemos corrigir o erro acima mencionado, usando essas etapas. Mas observe que essa não é uma idéia muito inteligente para manter os dados na raiz de uma unidade. Devemos criar uma pasta e manter os arquivos do banco de dados dentro do diretório especifico.

1. Primeiro para ver esta pasta oculta hidden folder(System Volume Information) clique na aba view, selecione Hidden Items e vá para a aba options clique na aba view e desmarque Hide Protected Operating System File (Recomended).
2. Vá para a pasta “G: \ System Volume Information” e clique com o botão direito no arquivo ResumeKeyFilter.Store clique em propriedades e na aba de segurança, adicione seu usuário de instalação. Neste caso, era um usuário de domínio, e então adicionamos a conta sob permissão (controle total).

Depois que a permissão foi dada, clicamos na opção "Repetir - Retry" e a configuração foi concluída sem mais nenhum erro.

Espero que isso ajude você a corrigir o erro de instalação.

SQL SERVER - Log De Transações, Identificando os responsáveis

Sexta-feira dia de maldade (famosa frase das sextas-feiras) nos remete a refletir quais os maiores impactos e problemas para um ambiente de produção? UPDATE Sem WHERE ? DROP Table ?

Brincadeiras a parte, neste modulo iremos orientar como ler o log de transações e assim podemos identificar  ações, quem descartou uma tabela (DELETE -DROP) Por exemplo, Ou quaisquer outras ações executadas.

O SQL Server transaction log contém registros descrevendo alterações feitas a uma base de dados. Ele armazena informação suficiente para recuperar uma base de dados em um tempo específico no tempo, para refazer ou desfazer uma alteração. Mas, como visualizar seu conteúdo, localizar uma transação específica, ver o que aconteceu e reverter uma alteração como uma remoção de registro acidental.Para visualizar o que está armazenado em um transaction log ativo, ou em um backup de transaction log não é tão simples, abrir o arquivo LDF e TRN em um editor binário ele exibirá registros inteligíveis impossibilitando a leitura direta.


FN_DBLOG

Usando fn_dblog é uma função não documentada no SQL Server que lê a parte ativa de um transaction log. Esta função em si retorna 129 colunas, é recomendado selecionar apenas colunas específicas e filtrar os resultados para um tipo de operação específico, a partir do conjunto de resultados retornados pelo fn_dblog, localize as transações que você quer inspecionar.

1 2 3 4 5 6

SELECT [Transaction Id], [Begin Time], SUSER_SNAME ([Transaction SID]) AS [User], [Transaction Name] FROM fn_dblog (NULL, NULL) WHERE [Transaction Name] = 'DELETE' GO

* Pré-requisito para monitoração em banco de dados é um banco em modelo de recuperação FULL
Completo, portanto o log de transações registra todos os detalhes necessários.

Por favor, lembre-se, se você estiver usando o SA ou o login do administrador do sistema para acessar o seu sistema, você não será capaz de encontrar um usuário final que alterou sua tabela.
É sempre uma boa ideia criar um login e um usuário diferentes para o seu sistema, principalmente a níveis de acessos específicos, assim, quando você precisar rastrear qualquer usuário, será mais fácil para gestão.

SQL SERVER - O assistente para restauração de banco de dados no SSMS Management Studio está muito lento.

Recentemente enfrentamos uma situação muito interessante. Para ser muito honesto, eu estava inicialmente perdido por alguns momentos quando descreveram essa situação e queriam que eu resolvesse o erro deles. Eles estavam enfrentando uma situação muito especial em que o SQL Server Management Studio estava funcionando bem, mas quando tentavam restaurar qualquer banco de dados, o Assistente de banco de dados de restauração do SSMS demorava uma eternidade para ser aberto.

Os desenvolvedores ficaram muito surpresos com esse problema e já passaram muito tempo no servidor. Depois de tentativas frustradas, eles decidiram me procurar e queriam que eu resolvesse o erro deles. Vamos ver quais são os vários esforços que tentamos durante a chamada para resolver o problema e qual deles funcionou exatamente.

Falha na tentativa 1: reinstalar o SSMS

Isso não funcionou para nós.

Falha na tentativa 2: instalar a versão mais recente do SSMS

Novamente, assim como a reinstalação do SSMS, a versão mais recente do SQL Server Management Studio não funcionou.

Falha na tentativa 3: aumentar a memória para o sistema operacional

Como estávamos em uma máquina virtual, tentamos aumentar a memória no sistema operacional, mas isso também não foi bem-sucedido.

Falha na tentativa 4: tentativa de restaurar outro banco de dados

Não importa qual banco de dados nós tentamos restaurar o Assistente de banco de dados de restauração do SSMS não apareceria facilmente.

Falha Tentativa 5: Tentei quando o servidor não estava ocupado

Honestamente, isso também não funcionou.

Tentativa Bem-sucedida: Excluir Histórico de Backup

Bem, depois de passar mais de 30 minutos em várias tentativas mal-sucedidas diferentes, assim como um DBA, eu também estava um pouco perdido no momento. No entanto, quando percebi que apenas o seu assistente de banco de dados de restauração é lento, mas nenhuma outra parte no SSMS, de repente me lembrei sobre o histórico de backup.

Sempre que abrimos o Assistente de restauração de banco de dados nesse momento, o SQL Server recupera o histórico inteiro do backup de banco de dados da tabela msdb.dbo.backupset e é exibido na seção Conjuntos de backups a serem restaurados. Eu verifiquei com o DBA e eles não estavam excluindo nenhum histórico de backup como parte do processo de manutenção.

A próxima coisa que fizemos foi excluir o histórico de backup com o seguinte comando, onde eu deletei todo o histórico antes da data de 1º de janeiro de 2018.

1 2	USE msdb; EXEC sp_delete_backuphistory @oldest_date = '01/01/2018';

Uma vez que eu apaguei o histórico deles, de repente o assistente de banco de dados de restauração começou a abrir muito rapidamente.

Lição aprendida de que você deve ter um plano de manutenção adequado. Excluir o histórico de backup é apenas uma das etapas da tarefa de manutenção, você pode planejar dentro das suas rotinas e criar um plano de manutenção muito robusto que não lhe dará surpresas inesperadas, como descrito em postagem de blog de hoje.

Grande abraços, sucesso.