Como alterar o nome da instância do SQL Server

Imagem

Olá,

Dúvida bastante recorrente

Fulano: Putz, criei a instância com o nome NPC100LEROLEROTESTE e agora quero mudar o nome, como eu faço?

Lembrando que instância padrão você acessa com o nome da máquina, e instância nomeada, com o NomeDaMáquinaNomeDaInstância.

Impressões sobre o exame 70-465 – Design database solutions for SQL Server 2012

Imagem totalmente random para representar o post

Olá,

Gostei bastante da prova e cá estou aqui pra compartilhar alguns pontos sobre a mesma..

Coisas legais

  • Casos de estudo: Questões baseadas em casos de estudos são bem interessantes pois como você recebe um cenário as questões são melhor contextualizadas, diminuindo questões de dupla interpretação e calando um pouco nosso amigo “depende”. Melhor ainda quando alguns cenários já foram, em outros momentos, presenciados, seja na vida real ou lidos via blogs e livros, e isso ajuda (me ajudou) bastante na hora de diagnosticar o problema da questão.
  • Features: A prova cobra de modo pesado conhecimento em praticamente todas as ferramentas do produto. Você não precisa dominar cada uma: é suficiente saber apenas o que cada uma faz e o que não faz e isso será cobrado em várias questões (bem mais de 15, no meu sorteio). Algumas questões vem praticamente de graça (por exemplo, quando a questão pede “a melhor opção para criação de políticas” e marcar PBM é quase que automático, e esse tipo de situação ocorreu em diversas questões). O que eu lembro que cai na prova: audit, agent alert, policy based management, resource governor, activity monitor, maintenance plain (…), Profiler, Xtended Events, DTC…
  • Melhor escolha: Essas questões são bem legais, porque geralmente apresentam uma cilada com duas ou mais respostas certas. Por exemplo, se você precisar listar as 10 maiores ocorrências de WAITS da sua instância, você usaria uma DMV ou um DBCC? Pro primeiro, você ordenaria e limitava o resultado. No segundo, você precisaria jogar em uma tabela, variável, etc pra depois fazer o mesmo que você faria no primeiro caso. Por isso, geralmente eu digo e repito: se você tiver 10 opções e dentre elas tiver alguma DMV, considere-a com carinho.
  • Alta Disponibilidade VS Disaster Recovery: Muitas questões muito bem orquestradas no sentido de separar uma coisa da outra e outras muito bem feitas. Saber os tipos de backup e qual o papel de cada um em um disaster recovery é muito importante. Sabendo o que cada um faz, e o TEMPO relativo que cada um demora, algumas questões são praticamente de graça. Backup de log é coisa de bonita de  Deus sempre, mas nem sempre é a melhor opção em uma operação de risco (previamente agendada) onde alguma cagada acontece e a recuperação precisa ser rápida. Talvez um Database Snapshot cairia melhor neste cenário de DR, por exemplo…
  • Indexação: Cai bastante coisa atrelado com os estudos de caso. Não são questões fáceis então recomendo dar uma lida antes sobre o assunto.

Coisas que eu não gostei

  • Mais questão de Mirroring, menos de Always-On. A funcionalidade de Mirroring será descontinuada pela MS nas futuras versões, então, esperava que os exames também fizessem isso, de alguma forma.
  • Algo já pontuado pelo Luti, é sobre as questões que possuem mais de uma resposta correta mas não possuem limites (por exemplo, cinco opções, e você pode marcar todas, ou uma). Se tiverem 4 corretas, e eu marcar 3, perco a questão inteira ou ganho proporcional ao valor da questão? Seria legal a Microsoft indicar isso nas questões ou nas instruções do exame, pra dissipar incerteza que no meu caso me fez gastar um tempo extra nessas questões.

Próximo passo (pessoal)

Exame 70-464! Destinei um tempo maior de revisão pra essa prova, já desenvolvimento não é minha praia e confesso que não tenho boa experiência com esse segmento (depois da 70-433) além de não ser atualmente minha atuação. Espero ter êxito nessa prova e compartilhar algumas dicas sobre ela também.

Referências

Recomendo fortemente a leitura dos posts abaixo (em ordem):

  • Luti – http://luticm.blogspot.com.br/2012/04/impressoes-da-prova-70-465.html
  • Alex Rosa – http://alexrosadba.wordpress.com/2012/11/01/70-465-designing-database-solutions-for-sql-server-2012-pass/

Considero as leituras acima bastante importantes caso você vá realizar o exame.

 

Bons estudos!

[]’s

Descubra a conta de Serviço do SQL Server

Registro

Olá,

Post dica rápida (e bem útil dessa vez, garanto) sobre como localizar a conta do SQL Server, direto no SQL Server.

Ás vezes existe a necessidade de se conferir qual é a conta de serviço, seja para simples conferência ou uso em scripts dinâmicos, por exemplo. Existem N formas de você fazer isso. Algumas delas:

1) Services: WinKey + R > Digite no executar services.msc > Procure o serviço do SQL Server > Botão direito > Aba Login, A conta está lá.

2) SQL Server Configuration Manager: SQL Services > Ver qual conta está no “Log as IN”. Basicamente, esse método é uma interface do primeiro.

3) Via bruxaria: (xp_cmdshell, xp_* e derivados). Exemplo:

Se você tiver o prazer de usar no mínimo o 2008R2, você pode usar as DMV’s abaixo.

4 – Modo DMV Lifestyle (SQL Server 2008R2 ou superior) – Motivo do título do post. 

Resumindo:Detalhes da Query

Se você tiver, dentre várias opções, alguma DMV, dê preferência, principalmente se precisar desta informação para realizar consultas.

Referências:

Conheça o Logical Backup Device

Logical Device

Olá,

O assunto de hoje é Logical Backup Device. Para maiores informações sobre o termo “Device” (Dispositivo) de backup no SQL Server ou sobre o termo que intitula o post, dê uma olhada nas referências.

Logical Backup Device (Dispositivo Lógico de Backup), que ao longo do post vou chamar de LBD, nada mais é do que um alias (ou abstração, para os mais teóricos) de um dispositivo físico (pode ser uma fita ou disco, geralmente este último). Significa que podemos referenciar um local físico passando apenas o nome do dispositivo lógico como destino.

Como seria um backup referenciando um LBD?

Observações:

– O nome do seu Logical Backup Device deve ser único (óbvio, lol)
– View de sistema: sys.backup_devices (consulte aqui todos os LBD’s criados)
– Pra criar um logical device, é necessário pertencer à role diskadmin (ou sysadmin).

Como criar

Aquela beleza de poder escolher N formas para cumprir  determinado objetivo.

Duas formas de criar o LBD (o modo hardcore, aka Powershell, não será abordado aqui);

a – Usando a GUI do Management Studio (Modo fácil);

Criando um LBD visualmente

Vale lembrar que o arquivo informado em File não é criado em tempo de execução. Você precisa criá-lo (lembre-se: é um arquivo binário).

b – Usando T-SQL (Modo normal)

Com as permissões necessárias, basta utilizar a procedure sp_addumpdevice.

O nome não é intuitivo e pode causar um certo estranhamento, pois antigamente, o termo dump era bastante utilizado em alguns cenários de tecnologias (e ainda é, no MySQL) por ser sinônimo de backup e agora nem tanto (sp_addbackupdevice seria muito mais amigável não só de nome como também combinaria com a view e tal…)

Confira as sintaxes úteis, que são a criação, a deleção e a consulta de informações em view de sistema relacionadas aos LBDs :

Modo TSQL

– name: Nome do seu dispositivo. É o nome que vai ser apontado no destino de backup;

– type: Tape = 1 e Disk = 2

– type_desc = descrição dos tipos acima

– physical_name = O caminho FÍSICO do dispositivo

Vale lembrar (de novo) que o arquivo informado em File não é criado em tempo de execução. Você precisa criá-lo (lembre-se: é um arquivo binário).

Mas qual a utilidade disto?

O fato de  se ter uma abstração física te dá a vantagem de alterar o caminho de um dispositivo em determinado ponto (na configuração do próprio lbd), e não em scripts que o referenciem. Vamos supor que você tenha um job de backup, de uma base em específica. Se o script contiver apenas o nome do LBD e não um caminho de disco local ou SAN, se você precisar alterar o caminho físico, basta alterar o LBD.

E como usar um LBD? Mais fácil enxergar na prática:

BKP E RST

Apenas um exemplo (tirado da vida real)

Uma aplicação X frequentemente fazia backup e restore da sua base e utilizava esse recurso do LBD. O fornecedor optou por utilizar apenas um arquivo pra fazer esse processo todo de backup e restore continuamente, sempre sobrescrevendo o mesmo em cada execução. A definição do (mais adequado possível) caminho físico fica por responsabilidade do DBA.

Também é interessante utilizar esse método onde você desenvolva algum script que precise de uma localização física para realização de backup e restore e você não pode garantir um caminho definitivo (seja de rede ou local). Adivinha qual a solução? LBD é uma boa. Já vi também implementações  de LBD para estratégias de backup bem excepcionais (Backup dividido). Ou seja, é uma solução que não atende um cenário apenas, embora não sejam cenários comuns.

Qual a vantagem disto?

O comando de Backup e Restore recebem um alias, uma abstração de um caminho físico. Logo, por exemplo, se meu caminho real tiver no disco D, e eu precisar retirar esse disco, posso mapear o LBD para algum outro local, por exemplo disco E, sem prejuízo para a aplicação. Também é útil em manobras emergenciais.

Por exemplo, manobras que envolvam diferentes discos (o que inclui troca de caminhos físicos com frequência) e/ou que sofram de falta de espaço podem fazer bom uso dessa abstração.

É útil para rotinas de backup convencionais? Não considero e não recomendo de jeito nenhum. O nível de organização que se tem em realizar um backup de banco por arquivo, o que inclui também convenção de nome bem definida (20140226_AdventureWorks_Full.bak por exemplo) é muito mais interessante  para uma rotina diária do que manter mais de um backup por arquivo (e isso pode pesar MUITO quando você precisar usar um device que tenha mais de uma base, e pior, bases diferentes).

Observação importante 

Uma recomendação da própria MS e que atualmente é uma boa prática (por razões óbvias): não deixe seus backups no mesmo array de disco que seus arquivos de dados e de log (note que eu disse array de disco e não discos e isso vale também para LBDs, pois, você pode ter duas letras/discos diferentes (D: e E: por exemplo) porém são partições/discos do mesmo disco/array. Quando se pensa em desastres, pense na pior hipótese sempre, algo como: o array todo pode falhar, e se seus arquivos de backup estiverem lá, você aprenderá da pior forma possível que backup no mesmo local físico onde seus dados estão não é backup. Isso é um ponto que irei sempre voltar ao longo das postagens.

 

Qualquer dúvida ou comentário adicional, fique à vontade para comentar.

 

Referências

Backup Devices: http://technet.microsoft.com/en-us/library/ms179313.aspx

Logical Backup Device  : http://technet.microsoft.com/en-us/library/ms189109.aspx

Diferenças entre Instância Padrão x Instância Nomeada

Olá,

Mais um fast-post (postagem rapidona, tradução livre) pra ilustrar um cenário bem comum para quem usa SQL Server eventualmente: o conceito de instâncias nomeadas e instâncias padrão (default). Peço que tenham paciência pois irei partir do começo, e quando digo “começo”, eu falo da parte de instalação do SQL Server.

O processo de instalação é relativamente simples (quer aprender como faz utilizando as melhores práticas?) e não será detalhado aqui. Recomendo este vídeo no MVA especialmente pois ilustra uma instalação completa.

A tela que define a configuração de sua instância é essa aqui:

Padrão ou nomeada?

Assumo que você já conhece o conceito de instância do SQL Server e por isso vamos abordar três tópicos:

  •  Instância padrão
  • Instância nomeada
  • SQL Server Express

Instância padrão

A lei suprema do universo é que, em determinada máquina, só pode ter uma e apenas uma (e apenas uma e apenas uma e apenas u…) instância padrão (Default Instance). Jamais, em hipótese alguma, você poderá ter mais de uma instância padrão na mesma máquina, mesmo se você instalar várias instâncias de versões do SQL Server diferentes.

Por exemplo, se você instalou uma instância padrão do SQL Server 2008 R2 em sua máquina, e deseja instalar uma instância do SQL Server 2012 pra testes, você não pode instalar uma instância padrão, a mesma PRECISA ser nomeada.

Depois de instalado, se o serviço do SQL Server estiver online (pode ser conferido no SQL Server Configuration Manager ou em services.msc do Windows), como logamos?

Assim:

Opções para logar em uma instância padrão:

  • (local) – Como ilustrado na imagem acima;
  • . – Também conhecido como ponto.  Puro unix-pattern 🙂
  • NOMEDASUAMAQUINA – A sua máquina só pode possuir uma instância padrão, logo,
  • MSSQLSERVER – Aponta também para a instância padrão. Note que no ato da instalação, quando se seleciona default, esse é o nome que aparece (Instância padrão) .

Instância nomeada

Enquanto você só pode ter uma instância padrão em uma máquina, poderá ter N instâncias nomeadas. Olha como é criada uma instância nomeada:

nomeada

E como logamos em uma instância nomeada?

Instância nomeada

Ou seja: NomeDaMaquina\NomeInstancia

E o que tem haver o SQL Server Express?

É o campeão em frustar recém-chegados ao SQL Server 🙂

O motivo é a edição EXPRESS, que é bastante baixada seja por desenvolvedores ou para quem está pegando o jeito com o SQL Server, obrigatoriamente é nomeada.

E como logar? Usando um dos  nomes abaixo:

  • NomeDaSuaMaquina\SQLEXPRESS;
  • .\SQLEXPRESS

Porque achei interessante mencionar o SQL Express? Porque um amigo meu topou com essa dificuldade e talvez outra pessoa também tope.

E qual a diferença entre instâncias padrão e nomeada?

Basicamente configurações de conectividade (leia-se: nome do servidor e porta).

Porta pode se tornar um fator problemático  (sem devido conhecimento) se você estiver conectando em uma instância nomeada e o SQL Server Browser não está habilitado nela. Mas isso é assunto pra outro post 🙂

Referência: http://technet.microsoft.com/en-us/library/ms165614(v=sql.90).aspx

 

[]’s

 

Na hora de logar, cuidado com os (in)sensitives!

Insensitive
Pra quem não sabe o que é sobre o que é case (in)sensitive clique aqui
Olá,

Agorinha recebi um pedido pra criação de login/senha.

Código:

E concedi as permissões necessárias para o programador (aqui chamado de bro) realizar o teste em desenvolvimento.
No telefone:

Eu: testa aí por favor.
Bro: cara, não deu certo não.
Eu: Fiz o teste em minha máquina e funcionou…(carregando o errorlog)
Bro: Aqui continua dando erro, olha, tentei cinco vezes. O login no SQL Server é INSENSITIVO né?
Eu: Depende do Collate do servidor SQL, aí no caso de desenvolvimento, é Latin1_General_CI_AI, que é insensitivo.
Bro: Cara, então não sei o que é, na boa, não consigo logar.
Eu: *depois de ler o errorlog* e a senha, como é que tá? Tudo em minúsculo?
Bro: sim, porque?

Pedi pra que ele capitalizasse o que precisa ser capitalizado (algumas letras da senha estão em maiúsculo).
Aí vem a pergunta mais que óbvia: Mas a instância não é case insensitive?

É sim! Nesse caso especificamente, tanto faz se o login estiver UserAPP, USERAPP,UsErApP, ambos vão funcionar, exceto se o collate do servidor estiver configurado de algum modo para SENSITIVE. No caso de senhas, por funcionamento interno do SQL Server (leia-se, transformação da senha para hash, que é um procedimento interno que garante segurança das autenticações) seu texto SERÁ SENSITIVO independente do seu collate ou da versão do SQL Server.

Curiosidade leve, mas, pode ser útil pra alguém 🙂

Roles do SQL Server – Public

public

 

 

 

 

 

 

 

 

Olá!

Continuando com a série de Roles do SQL Server, vamos conversar sobre a role Public.

Provavelmente o post mais rápido do blog =)

Public

De cara, vale dizer que public possui uma implementação diferente das outras roles de servidor. Alguma peculiaridades:

  • Todo login criado no SQL Server, por padrão está vinculado à role public;
  • Das roles de servidor padrão (entenda-se excluindo as roles de servidor customizadas), é a única server role que pode ter as permissões controladas através de GRANT, DENY e REVOKE;
  • É gerado em cada banco uma database role com o mesmo nome. Embora estejam estritamente relacionadas, não são a mesma coisa;

Qual a ideia afinal do public? Bem… Sabe o nosso direito de ser cidadão, independente de quem seja? Liberdade de ir e vir, liberdade de expressão, etc? Segue a mesma ideia. Os direitos (e restrições) valem pra todo mundo, exceto para os sysadmins (que não possuem nenhuma restrição). Public contém as instruções padrões para TODOS os logins que se autenticam na instância.

 

Acabamos de criar um login qualquer. Quais permissões ele possui? Até o momento nenhuma, exceto as automaticamente herdadas pelo public. Pra ficar mais claro ainda, vamos aos testes de laboratório. Logue com o usuário recém-criado e tente criar um base:

Obviamente, o esperado é…

Msg 262, Level 14, State 1, Line 1
CREATE DATABASE permission denied in database ‘master’.

Agora, logado em seu usuário que seja sysadmin ou que tenha privilégios suficientes para executar o comando abaixo, tire a prova…

Com o login NaoFazNada, tente criar a base novamente…

 

Observações de public

Embora conceder permissões para public sempre seja o caminho mais fácil, evite isso sempre que possível. É a mesma coisa de, na preguiça, conceder acesso para Everyone em determinado diretório no Windows Server… Resolver resolve, mas abre a porta pra qualquer um entrar. Será que isso pode causar dor de cabeça futuramente?

E mais algumas enquanto database-role…

Existe outro cuidado bastante peculiar quando falamos de public enquanto DATABASE-ROLE (É importante distinguir uma da outra). É comum encontrarmos por aí solicitações, por exemplo, de conceder permissão para executar functions de tratamento de caracteres para o public em determinado banco. Esse public  como database-role na verdade contêm as definições que TODOS os usuários com acesso em determinada base.

Não é foco desta postagem granular a atuação do public ao nível de banco, mas, sobre tal tipo de solicitação bastante recorrente, só tenho a dizer que, embora facilite demais a vida de quem utiliza essas funções, sempre se deve levar em conta o permissionamento mínimo, logo…

Futuramente, vou criar um post sobre o tema, mas enquanto isso…

Por fim..

A conclusão é: nunca confie demais algo ao público, você pode não saber quem está lá.

Fique à vontade para acrescentar algo nos comentários abaixo, caso queira. Nos vemos por aí.

Roles do SQL Server – Diskadmin e Processadmin

hard-drive-inside

 

 

 

 

 

 

 

 

 

 

 

Olá.

Depois de algum tempo sem postar (falta de tempo mas por motivos profissionais, graças à Deus) aqui estamos. Pra abreviar um pouco a série sobre as roles de servidor, não seguirei a mesma linha dos posts anteriores se não for extremamente necessário.

Vamos falar um pouco agora sobre duas roles em específico (até porque não temos muito o que falar sobre: DiskAdmin e ProcessAdmin)

Diskadmin

Administra dispositivos de backup (obs: dispositivos, não o backup). Hoje em dia, esta role foi pro museu. Um motivo forte pra isso é caiu no desuso o uso de dispositivos para backup em fita (antigamente era comum fazer backup diretamente na fita, e hoje, é algo raro, pois, o desempenho de uma fita é ligeiramente inferior à backup no disco.

Funcionalidades:

  • sp_addumpdevice/sp_dropdevice = Adiciona/deleta um dispositivo de backup novo  à instância.
  • sp_diskdefault  e DISK INIT = Deprecated desde o SQL Server 2000. Fora do escopo (adorei essa frase).
  • Add member to diskadmin = Milagre da multiplicação, o famoso “passa a corrente pra frente”, etc. Dispensa explicações se você está acompanhando a série do começo =)

É interessante notar que um Disdkadmin não equivale a um backup operator ou algo do tipo (fazendo aqui referência à outros SGBD’s) pois por padrão, ele não possui direito de backup, a menos que seja dado tal direito explicitamente por outras formas.  Isso é um tanto quanto engraçado, poder gerenciar pra onde o backup vai mas não poder fazer backup. É muita falta de moral (risos).

ProcessAdmin

Possui o poder de matar conexões. Mas não só isso. Literalmente, ele é um administrador de processos, logo, com certeza, consegue enxergar todos eles. Em suma, ele consegue verificar todas as conexões da instância de várias formas, como por exemplo: a procedure sp_who2 e a dmv dm_exec_connections.

Funcionalidades:

  • Add member to processadmin = Milagre da multiplicação…
  • KILL = Possibilita utilizar o comando KILL, que encerra uma conexão. Leia-se: pode desconectar quem quiser.

Apesar de parecer pouca coisa, tal role possui um poder de fogo considerável. Matar conexões é um tanto quanto perigoso e pode trazer problemas se tal permissão for concedida à pessoas inexperientes/mal-intencionadas.

Geralmente quem tem o poder de matar conexões é um sa (sysadmin), então, é muito mais interessante deixar tal tarefa para algum membro desta role do que “granular” o fato de administrar conexões com o ProcessAdmin.

 —-

Em breve, continuo o post sobre as server roles. Obrigado pela leitura e sinta-se à vontade para comentar.

Roles do SQL Server – Dbcreator

DBCREATOR

Mais um post da série SQL Server Vida e Obra   , dessa vez sobre uma role bem peculiar: dbcreator, também conhecido como filho do sa. Cuidado com essa permissão, beleza?

O que é o DBCREATOR?

A documentação oficial da Microsoft (meio datada, mas ainda vale), diz:

Members of the dbcreator fixed server role can create databases, and can alter and restore their own databases.

Em português simples traduzido no popular:

Membros da função fixa dbcreator podem criar bases de dados, e podem alterar e restaurar suas próprias bases

Bem, vamos explorar um pouco e mostrar que a role vai um pouco além do que o nome sugere (criar bases)…O que pode ser uma benção e uma maldição, dependendo do ambiente.

Aplicação

É uma conta com permissões importantíssimas. O primeiro ponto a ser observado é que um dbcreator possui permissão para criar, alterar e dropar qualquer banco, até os que não é de sua criação (sentiu o perigo?) assim como pode utilizar o comando RESTORE tanto pra banco quanto pra LOG (este porém restrito às suas bases e/ou com as permissões adequadas. Tal assunto será abordado futuramente com maiores detalhes).

Testes

Primeiramente vamos verificar as permissões que a role possui:

Listando (os riscados não serão abordados neste post.):

– Add member to dbcreator (também conhecido como milagre da multiplicação)
– ALTER DATABASE
– CREATE DATABASE
– DROP DATABASE
– Extend database (Alterar o tamanho de um arquivo da base)
– RESTORE DATABASE
– RESTORE LOG
– sp_renamedb  (Procedure que renomeia o banco)

Bem, vamos começar oficialmente com os testes….

1) Criação do login

Agora logue como DbaCriador no Management Studio (ou da forma que preferir, contanto que consiga se passar pelo login).

2) Rename e Drop

Perceba agora o quanto a role é potente no sentido de permissões:

Consegue observar o tamanho da possível encrenca? É sempre bom reforçar que, dentro de uma instância, o maior bem é o banco de dados, e sua destruição e criação são sem dúvida uma das permissões mais sagradas que um principal pode ter.

Não precisamos comentar também a habilidade de repassar a Role para outros membros, e com o poder “milagre da multiplicação” temos mais um problema: um dbcreator criando outro dbcreator!

Veja ainda logado como dbcreator:

Considerações finais

Considere essa role uma das mais próximas do sa propriamente dito (assim como a security admin). Ultimamente caiu um pouco em desuso, pois, geralmente quem tem permissão de criar bases, pelo menos nos ambientes que observei, já possuem permissão de sysadmin, logo, não possuem restrição alguma. Se realmente for necessário que um principal crie bases, existe uma abordagem muito mais esperta:

Privilégio mínimo na prática.