Database States e suas interações

Olá,

O estado do banco de dados (do inglês, state) vai definir algumas de suas características, tais como acessibilidade e disponibilidade dos dados. Todo banco de dados SQL Server está em um determinado estado. No SQL Server, um banco de dados pode assumir 7 estados diferentes, sendo eles:

  • ONLINE
  • OFFLINE
  • RESTORING
  • RECOVERING
  • RECOVERY PENDING
  • SUSPECT
  • EMERGENCY

A descrição de cada um destes estados pode ser encontrada neste link (http://technet.microsoft.com/en-us/library/ms190442.aspx) do BOL (Books Online para quem está se habituando agora com estes termos – em outras palavras, é o Help do SQL Server).

O ponto que quero destacar aqui é como os estados se um banco de dados interagem. A troca de um estado pode ocorrer de duas formas: através de ação manual por parte do usuário ou automaticamente através de uma ação do próprio SQL Server.

Por exemplo, o DBA pode a qualquer momento alterar o estado de um banco de dados para OFFLINE, procedimento realizado manualmente. Por outro lado, no momento que essa base for alterada para ONLINE, o SQL Server a altera para um estado intermediário (RECOVERING), onde o processo de recovery (ANALYSIS-REDO-UNDO, tópico para outro post) é realizado. Se este processo for realizado com sucesso e o SQL Server não detectar nenhum erro, o SQL Server automaticamente altera o estado da base para ONLINE.

A importância de se conhecer a interação entre estes estados está no fato de auxiliar o DBA a saber a origem daquele estado e talvez lhe ajudar a identificar algum tipo de problema.

Um simples consulta pode retornar o estado atual de um banco de dados:

Consulta na sys.databases

Consulta na sys.databases

 

A imagem abaixo lista todas as possíveis interações entre os estados de um banco de dados.

Interações entre os estados do banco de dados

Interações entre os estados do banco de dados

 

Bons estudos!

Erickson Ricci

Como configurar a quantidade de arquivos do errorlog

Olá,

Por padrão o SQL Server mantém apenas 6 arquivos históricos do errorlog. Se o SQL Server for reiniciado será gerado um arquivo de errorlog novo e o último arquivo (mais antigo) será descartado.

Há uma maneira simples de configurar esta quantidade de arquivos. Através do Management Studio, vá até a pasta Management, SQL Server Logs, e clique com o botão direito na pasta. Acesse o menu Configure. (Veja imagem abaixo)

image1A tela a seguir será apresentada:

image2Nesta tela você poderá alterar a quantidade de arquivos de errorlog que o SQL Server irá manter.

Lembre-se que, se você quiser, você pode “reciclar” o atual arquivo do errorlog executando manualmente a procedure sp_cycle_errorlog.

 

Bons Estudos!
Até mais.

Erickson Ricci

Entenda o erro 18056 – The client was enable to reuse a session with SPID ##

Olá,

Todo DBA já deve ter visto alguma vez na vida o erro 18056. E se viu, provavelmente teve dificuldades para entendê-lo e tratá-lo. Por conta de todas as dúvidas e mal-entendimentos sobre este erro, alguns engenheiros de escalação da Microsoft fizeram alguns posts para esclarecer todas estas dúvidas.

Deixarei aqui a referência de todos os artigos relacionados a este erro.

How It Works: Error 18056 – The client was unable to reuse a session with SPID ##, which had been reset for connection pooling

How It Works: Error 18056 – The client was unable to reuse a session – Part 2

Error 18056 can be unwanted noise in certain scenarios

Breaking Down 18065

Todos estes artigos ( e todos os outros do blog ) são altamente recomendados. Leitura essencial para um bom DBA.

 

Bons estudos! Enjoy!!!
Erickson Ricci