Boa noite pessoal,

Recentemente passei um perrengue pois não conseguia acessar uma instância que nossa equipe administraria mas que não tinha acesso ainda pois tratava-se de um sistema legado.

Resumindo: Ninguém tinha ideia de qual era a senha do famoso e odiado ‘SA’. E ninguém do lado do cliente tinha acesso administrativo na instância em questão. As aplicações estavam funcionando (ainda e por sorte) em modo ‘piloto automático’.

Em comum acordo com o cliente, realizamos o seguinte procedimento:

1. Criamos um usuário local no Windows com privilégio de Administrador;
Screen Shot 2014-10-18 at 19.36.57

2. Acessamos o Windows a partir deste usuário;

3. Paramos a instância do SQL SERVER e de todos os outros serviços relacionados a esta;

4. Alteramos a configuração da instância para ser iniciada em modo SINGLE USER (-m);

 Screen Shot 2014-10-18 at 20.57.51

5. Alteramos a configuração de autenticação do serviço do SQL SERVER para o usuário criado no passo 1;

Screen Shot 2014-10-18 at 20.58.23

6. Conectamos à instância via SQLCMD e …

Screen Shot 2014-10-18 at 21.22.18

7. Adicionamos o usuário recém-criado como sysadmin da instância;

8. Saímos do SQLCMD, pois somos loucos por Windows, interface gráfica e SSMS! 🙂

9. Alteramos o serviço do SQL SERVER para Local System como estava anteriormente e retiramos o parâmetro -m da instância;

10. Reiniciamos o serviço do SQL SERVER e iniciamos os outros serviços relacionados a instância e …

Screen Shot 2014-10-18 at 21.25.49

11. Acessamos o SQL SERVER com sucesso a partir do SSMS com o nosso usuário recém-adicionado à role de SYSADMIN!

Screen Shot 2014-10-18 at 21.30.04

Ps:

  • Esta não é a melhor prática para se obter acesso à um SQL SERVER e fere vários protocolos e melhores práticas de segurança da informação – a melhor forma é ter a documentação do ambiente devidamente atualizada.
  • Tudo foi feito com consentimento do cliente, no caso, atual dono do sistema que herdou o servidor. Não tente fazer nada por ‘debaixo dos panos’, muito menos indisponibilizar suas bases de dados sem que ele fique sabendo!
  • No passo 7 utilizamos a procedure sp_addsrvrolemember para adicionarmos nosso LOGIN ao grupo de sysadmin pois realizamos este procedimento em um SQL SERVER 2008 R2. No entanto, este comando está marcado para entrar em desuso. O ideal é utilizar o ALTER SERVER ROLE (compatível com SQL SERVER 2012+).

É isso pessoal, espero que ajude vocês caso tenham algum problema e até a próxima!

UPDATE: Se nada disso funcionar, tente inicar o SQL SERVER a partir de um prompt de comando com o parametro -m”SQLCMD” e a partir de outro prompt tente executar o SQLCMD.

Fontes de referencia:

Abaixo o vídeo com o passo a passo realizado:

Fala galera,

Há algum tempo o Adam Machanic e o Jonathan Kehayias postaram scripts que ajudam a “inchar” as bases de dados AdventureWorks do SQL SERVER, para conseguirmos fazer testes mais reais em cima de um WORKLOAD mais “plausível”.

Para os SQLGeeks de plantão:

https://www.sqlskills.com/blogs/jonathan/enlarging-the-adventureworks-sample-databases/

http://sqlblog.com/blogs/adam_machanic/archive/2011/10/17/thinking-big-adventure.aspx

 

Para baixar as bases de exemplo iniciais:

http://msftdbprodsamples.codeplex.com/

Enjoy! 😉

Fala pessoal,

Neste post vou falar sobre os limites e melhores práticas a respeito de configurações de memória no SQL SERVER.

O funcionamento

O SQL SERVER possui dois limites configuráveis de alocação de memória: inferior e superior.
Quando o serviço do mesmo é iniciado apenas uma pequena quantidade de memória é alocada (o suficiente para alocar as estruturas de funcionamento de buffers), não necessariamente o limite inferior configurado.
Quando o SQL SERVER alcançar o limite mínimo ele manterá o Buffer Cache no mínimo neste valor. O limite máximo indica para o SGBD não ultrapassar determinado valor de alocação de memória.
Vale lembrar que este limite configurável determina apenas o valor do Buffer Cache, o SQL SERVER normalmente necessita de mais 20% de memória para funcionamento adequado.

memoria SQL SERVER - mantenha configurada!

A boa prática

O ideal assim que terminamos de instalar a instância do SQL SERVER é reservar um valor específico como limite mínimo e um valor superior como limite máximo. Respeitando os seguintes fatores:

  • O SQL SERVER vai consumir em média mais 20% de memória acima do limite máximo e;
  • O Sistema Operacional também precisa trabalhar! Deixe em torno de 20% da memória total do servidor para ele.

A péssima prática

Consideramos péssimas práticas:

  1. Deixar de configurar os limites de memória do SQL SERVER;
  2. Configurar os limites de memória com valores iguais.

São péssimas práticas porque:

  1. Caso o S.O. sinalize pressão de memória o SQL não vai liberar nada;
  2. Mesma situação, não será possível dar uma “folga” para o S.O. caso haja pressão externa de memória.

Abaixo o vídeo com a nossa experiência: