Novo blog está no ar!!! WOW…
Chegou a hora de mudar e resolvi ter um domínio próprio. Daqui em diante farei posts somente neste novo site – tiagobalabuch.com
Com um mudança radical o novo blog tem um estilo diferenciado, espero que vocês gostem e se acostumem rapidinho. Se alguma coisa não estiver funcionando direito, me avisem que eu tento corrigir 🙂
Dessa maneira esse blog será desativado.
Até breve!
Ao tentar instalar o SQL Server 2012 em um cluster recebi o seguinte erro:
There was an error to lookup cluster resource types. Error: There was a failure to call cluster code from a provider. Exception message: Generic failure . Status code: 4104. Description: Error code 0x86D80018.
Depois de muito pesquisar e pouco encontrar sobre o problema, resolvi envolver a equipe de SO para me ajudar.
Tentamos entendender o que o SQL Server estava fazendo achamos algo realmente estranho.
Ao listar os tipos de recursos do cluster tivemos uma surpresa.
Um tipo de recurso chamado: SQL Server(2008A)
Como e porque esse recurso foi criado é um mistério, mas esse tipo de recurso não fazia nenhum sentido para nós.
Após validar que nenhum outro recurso dependia desse recurso bizarro tivemos a certeza que poderíamos apaga-lo.
Para remover esse recurso via Failover Cluster Administrator:
Depois disso a instalação finalizou com sucesso!!
Acredito que todo DBA tem aquele ambiente que não é muito importante e que não damos a atenção necessária, pois bem é nesse ambiente que as coisas erradas acontecem!!!
Ao configurar o TEMPDB de forma que o arquivo iniciasse com um tamanho padrão de 10GB simplesmente coloquei para 100GB.
Porem sem perceber inclui um 0 a mais no tamanho no arquivo (104857600KB, pronto, gerei um problema enorme!).
Para minha “surpresa” o a instancia SQL Server não inicializava. Até o momento eu tinha configurado o TEMPDB de maneira certa, na minha visão é claro, para um volume de 50GB estaria apenas utilizando 10GB e não teria problemas.
Resolvi olhar o ErrorLog para avaliar o que poderia estar errado para que a instancia não iniciasse. E mais uma vez para minha surpresa encontrei a seguinte mensagem:
Could not create tempdb. You may not have enough disk space available. Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server. Check for additional errors in the event log that may indicate why the tempdb files could not be initialized.
É realmente eu tinha feito uma besteira, pois gerar o erro de falta de espaço em disco não era possível (na minha visão). Voltei e comecei a analisar o comando que tinha executado e percebi o que tinha feito para minha decepção!!!
Mas e agora, o que fazer? Não tinha como aumentar o espaço em disco, o SQL Server não iniciava para alterar as configurações.
A primeira coisa a fazer era voltar backup do master, é obvio que não tinha feito backup antes de alterar o arquivo, lembra daquele ambiente que você não da muita importância, então!!!
Para resolver isso tive q iniciar a instancia de uma forma diferente:
No site da MSDN vc encontra todas as opções de startup disponível http://msdn.microsoft.com/en-us/library/ms190737.aspx
Eu utilizei as opções –f (mínimo de configuração) e –m (Single User)
Agora sim 🙂 , após a instancia iniciar pude executar o comando para alterar a database TEMPDB para o seu tamanho correto! Feito isso, realizei um stop na instancia e iniciei novamente sem nenhum parâmetro auxiliar e a tudo subiu corretamente!!
Uffa… problema resolvido e lição aprendida!!!
Até a próxima…
Recentemente estive envolvido em um projeto da equipe de segurança para melhorar a vulnerabilidade do ambiente SQL Server e a questão de segurança vai muito além de permissões de acesso a instancia e ao banco de dados.
Vou listar algumas dicas que podem melhorar a vulnerabilidade de seu ambiente.
Se tem você tem mais alguma dica de segurança, por favor compartilhe!!
Recentemente estava assistindo alguns vídeos no Pluralsights e um código usado em um vídeo do Dan Sullivan para demonstrar Cached Plan me chamou a atenção.
Gostei e resolvi compartilhar, e fiz uma alteração apenas para incluir o nome da database.
create function SqlAndPlan (@handle varbinary(max)) returns table as return select sql.text ,db_name(qp.dbid) dbname -- eu adicionei essa informação ,cp.usecounts ,cp.cacheobjtype ,cp.objtype ,cp.size_in_bytes ,qp.query_plan from sys.dm_exec_sql_text (@handle) as sql
cross apply sys.dm_exec_query_plan(@handle) as qp
join sys.dm_exec_cached_plans as cp on cp.plan_handle = @handle
go
Primeiramente é criado uma função auxilizar para retornar informações plano de execução, onde é passado como parâmetro o plan_handle que uma referencia ao plano de execução em si e também uma referencia ao texto que causou a construção do plano de execução.
Com essa função podemos obter informações uteis, porem temos que ter o plan_handle especifico. Isso é interessante se queremos saber o cached plan de um unico plano de execução, porem, se quiseremos saber todos os cached plan e contidos na instancia, como fazemos? Teremos que passar um a um?
Não! Vamos criar uma view que irá percorrer todos os plan_handle e usar a função SqlAndPlan criada acima para obter as informações.
create view PlanCache
as
select
sp.dbname -- eu adicionei essa informação
,sp.text
,sp.usecounts
,sp.cacheobjtype
,sp.objtype
,sp.size_in_bytes
,sp.query_plan
from
sys.dm_exec_cached_plans as cp
CROSS APPLY SqlAndPlan(cp.plan_handle) as sp go Caso tenha alguma sugestao de melhoria no codigo, por favor, compartilhe. []’s
Referências:
Pluralsight – http://pluralsight.com
sys.dm_exec_sql_text – http://msdn.microsoft.com/pt-br/library/ms181929.aspx
sys.dm_exec_query_plan – http://msdn.microsoft.com/pt-br/library/ms189747(v=sql.110).aspx
sys.dm_exec_cached_plans – http://msdn.microsoft.com/pt-br/library/ms187404.aspx
Maníaco por SQL Server 