Roles do SQL Server – Serveradmin

Imagem

Olá,

Continuando a  antiga série básica sobre roles do SQL Server, vamos dar uma olhada na role: serveradmin.

Essa role é responsável por realizar atividades inerentes à configuração do servidor. As permissões, listadas graças à procedure sp_srvrolepermission são:

 

Add member to serveradmin: Também conhecido como milagre da multiplicação. É o poder de conceder a role serveradmin para outro login.

dbcc freeproccache: Possibilita o uso do comando DBCC (referências no final do post), que consegue remover elementos da área que chamados de plan cache (área na memória reservada para o SQL Server armazenar planos de execução). Esse comando DBCC pode remover um plano de execução armazenado ou todos, depende dos parâmetros que você passar (podendo ser sql, plan handle ou um valor default). Entenda que é um comando que tem relação com o servidor, que por sua vez está relacionado intimamente com a área de memória.

sp_configure/ RECONFIGURE: O SQL Server possui o que chamamos de Security by default (segurança por padrão). Muita coisa está desabilitada, e, para ativar essas opções, é necessário utilizar uma procedure de sistema chamada sp_configure. RECONFIGURE por sua vez é um comando necessário para atualizar o valor de algumas alterações realizadas nas configurações (não todas, algumas requerem que o servidor seja reiniciado e aí o reconfigure por si só não é suficiente). Nem precisa comentar sobre o quão crítica e importante é esta procedure. Configurações extremamente importantes são feitas aqui, sendo algumas delas (de várias, consulte a sys.configurations e a documentação pra ver o restante): memória mínima e máxima do servidor, fillfactor padrão do servidor, serviço de e-mail etc, acesso remoto, etc.

SHUTDOWN: Comando que possibilita o desligamento da instância. Lembrando que esse comando possui também a cláusula WITH NOWAIT (e isso pode significar, dependendo do cenário, restarts com um “crash recovery” muito demorados, ou em outras palavras, aquele reset na instância que causa uma demora descomunal onde as bases demoram uma vida e meia pra estarem online (esse assunto é bem legal, e tem relação com outros fatores que poucas pessoas se importam, como por exemplo, tamanho de VLF’s dos Transaction Logs). Mas bem, de qualquer forma, é um comando importante e digamos até vital no quesito de importância.

sp_fulltext_service:  Altera algumas configurações do fulltext em âmbito de servidor. Fora do escopo, btw. Mas vale dizer que quem trabalha com a feature, sabe o quão importante é possui um fulltext bem configurado.

sp_tableoption: Permite alterar algumas opções de tabelas (user-defined tables, jamais tabelas e views de sistema). Algumas delas tem influência também no comportamento do SQL Server vs locks nessas tabelas. Conclui-se, então, que essa configuração também é importante, embora pouco utilizada (pra se mexer nessa configuração, na minha opinião, é necessário um cenário bem específico).

Enfim…

Trata-se de uma role importante, e deve concedida sabiamente. É um pouco rara de se ver atualmente, pois a figura do DBA geralmente utiliza a sysadmin, que possui todos os privilégios possíveis em uma instância, e como as permissões de um serveradmin são naturais para um sysadmin, acaba sendo pouco utilizada (e consequentemente, com capacida pouco conhecida). E alguns cenários (não tão comuns assim), se faz  necessário que outras pessoas além do DBA, por exemplo, possam configurar a instância (ou desliga-la) mas que não necessariamente precisam de algo além disso, e aí, nestas situações, roles serveradmins são boas pedidas. O único porém, sempre, ao se falar de server roles, é justamente o fator “Add members to”. É importante ter isso em mente SEMPRE ao se conceder uma server role.

 

É isso. Próximas postagens (duas) vou finalizar essa humilde série sendo o último post o maior deles (esse post sobre sysadmin foi minha maior e confesso, a única motivação para começar a série). Meio louco dizer isso só agora, mas achei importante, hehehe.

[]‘s

Referências

Server roles (relembrando): http://msdn.microsoft.com/en-us/library/ms188659.aspx

SP_CONFIGURE: http://technet.microsoft.com/pt-br/library/ms188787.aspx

DBCC DROPFREECCACHE: http://technet.microsoft.com/pt-br/library/ms174283.aspx

 

 

 

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 NPC100\LEROLEROTESTE 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áquina\NomeDaInstância.

Mas então….Não existe uma forma documentada pela Microsoft de alterar o nome da instância stand-alone, mas você pode sim alterar o nome da máquina (que por sinal faz parte do nome da instância) e isso é bom, pois, atualizando os metadados do SQL Server, você evita diversos problemas onde algum trecho de código, independente de onde seja, aponte para o servidor antigo e uma falha de comunicação aconteça.

Por exemplo, se você mudar o nome da sua máquina de NPC999, a sua instância precisa ser acessada pelo nome NPC999\LEROLEROTESTE. Se você quer mudar o nome da instância SQL propriamente dita (LEROLEROTESTE), instale outra com o nome desejado.

Qual o procedimento para alterar o nome da máquina dentro do SQL Server ?

Para instâncias default (padrão):

sp_dropserver 'NPC100'
GO
sp_addserver 'NPC999', 'local';

Para instâncias nomeadas:

sp_dropserver 'NPC100\LEROLEROTESTE'
GO
sp_addserver 'NPC999\LEROLEROTESTE'

Lembre-se de, em ambos os casos, reiniciar o serviço do SQL Server para que você já consiga acessar usando o nome nome.

Mudei o nome da máquina mas nunca usei essa procedure aí, nunca deu nada!

Se você mudar o nome da máquina mas não utilizar a procedure acima para atualizar o nome do servidor nos metadados no SQL Server (pra ser mais exato, na sys.servers), pro SQL Server, o nome da máquina é o antigo. Pra comprovar essa teoria, mude o nome da máquina, faça um SELECT @@SERVERNAME e veja que o nome antigo ainda consta.

Então, se por um acaso, se você em algum momento se perguntar de novo como mudar o nome da instância, e alguém copiar e colar esse procedimento que altera o nome DA MÁQUINA, prestenção.

E lembrando: quiser mudar o nome da instância, reinstale.

[]‘s

Referê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):

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

 

Bons estudos!

[]‘s

Descubra a conta de Serviço do SQL Server – Sem bruxarias e relacionados

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:


declare @CC varchar(100)

exec xp_regread @root_key = 'HKEY_LOCAL_MACHINE'
,@key = 'SYSTEMControlSet001ServicesMSSQLServer'
,@valuename = 'ObjectName'
,@value = @CC output

select @CC

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. 

/* Retorna informação da instância do SQL Server direto do registro */
select * from sys.dm_server_registry

/* Retorna informações aos serviços (claro, o de engine envolvido) da instância */
select * from sys.dm_server_services

Detalhes da Query

Resumindo:

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?

BACKUP DATABASE [AdventureWorks2008R2]
TO BackupCactuar

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: NomeDaMaquinaNomeInstancia

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:

  • NomeDaSuaMaquinaSQLEXPRESS;
  • .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

—-

É isso. Mês que vem terminarei o post sobre as funções de servidor (Server Roles) e vou começar a escrever mais sobre o que atualmente estou estudando.

[]‘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:

CREATE LOGIN UserAPP WITH PASSWORD = 'UserAPP$1_.', CHECK_POLICY=OFF

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 :)

Até nunca mais, 2013. Obrigado por tudo!

Olá!

Foto random

Está um pouco óbvio pelo título, mas vale ressaltar: esse post não é técnico (nem um pouco) e surgiu da minha vontade de registrar algumas impressões que tive esse ano. Devo dizer que pra mim, 2013 foi de longe o ano mais importante de toda a minha vida (não da minha apenas, e por isso ele se tornou mais valioso ainda).

Várias resoluções e coisas boas aconteceram, coisas ruins também (algumas bem chatas, contudo no final se resumem à aprendizado), mas no geral, se fosse colocar num gráfico de pizza, uma parte maior com certeza tá verde. =)

Uma coisa que me deixou incrivelmente contente (e é sério) foi de ver amigos meus conquistarem seus objetivos. A lista é grande: vários conseguiram trabalhar em locais que queriam ou que os valorizassem, outros foram bem sucedidos em seus projetos, outros passaram em concursos que desejavam, outros compraram suas casas, outros casaram, outros conseguiram aprovação no ensino superior, enfim, fico mais contente ainda em saber que 2013 foi um ano bom não só pra mim.

Nos últimos três meses do ano, tenho avaliado muito do meu comportamento, meus hábitos, principalmente os ruins, e tenho procurado melhorar neles. Foi também o ano em que tive as conversas mais sinceras sobre vida, planos, projetos e isso muito me ensinou. É meio clichê dizer que muita coisa vai mudar em 2014, mas eu posso garantir que isso realmente vai acontecer e quem me conhece perceberá, e a causa foi essa: feedback: não abra mão de realizar/recebe-lo sempre que for possível.

E as resoluções de 2014?!

Haha, eu tomei liberdade de publicar aqui no site pra criar mais compromisso ainda no cumprimento destas tarefas:

Pessoais

  • Praticar pelo menos uma atividade física (é verdade…);
  • Engordar no mínimo 3Kg de modo saudável (quem viver verá);
  • Alcançar uma excelente produtividade no trabalho mantendo a saúde num estado idem;
  • Melhorar a qualidade do meu tempo livre (pra mim o grande desafio do ano, já dei o pontapé inicial e está me trazendo resultados, a longo prazo tende a melhorar mais ainda);

Técnicas

  • Postar no site pelo menos (no mínimo) três vezes por mês. Apesar de não estar postando tanto prometo mudar esse quadro no próximo ano. Estou bastante descontente com minha frequência de postagem atual e certamente o quadro vai mudar esse ano;
  • Obter a MCSE SQL Server 2012 (estou me preparando desde ano passado);
  • Dedicar com maior ênfase outras tecnologias de banco de dados e de áreas correlatadas (SO, por exemplo).
  • Aperfeiçoar conhecimentos em T-log, waits e blocks, cluster e Powershell;

Tenho vários outros objetivos, mas que estão em public, só estes.

Voltarei nessa página de tempos em tempos pra ver se tá tudo procedente com a forma que eu tô levando a vida, hehe.

[]‘s

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.


--> Cria um login sem direito algum
CREATE LOGIN NaoFazNada WITH PASSWORD='123', CHECK_POLICY=OFF

 

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:


CREATE DATABASE pensaNumCaos

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…


--> Dá direito de criação para public (ou seja, qualquer um)
GRANT CREATE ANY DATABASE TO PUBLIC

Com o login NaoFazNada, tente criar a base novamente…

Funcionou

E porque isso seria necessário? Estamos falando de permissionamento, não de configuração :)

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.

E mais algumas enquanto database-role…

Existe outro cuidado bastante peculiar quando falamos de public enquanto DATABASE-ROLE. É 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 na verdade contêm as definições que todos os usuários possuem naquele banco de dados específico.  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…

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

IO and system

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 (leia-se fitas, eu mesmo nem peguei essa época =p). Hoje utilizamos mais disco para tal finalidade.

DiskAdmin

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.

PROCESSADMIN

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.