Roles do SQL Server – Sysadmin

superman-logo-013

Olá,

Conforme prometido, o post de hoje será sobre a última server role que faltava pra humilde série aqui do blog: sysadmin! Na verdade é mais um post sobre CONTROL SERVER do que sysadmin, mas anyway…

Você conhece quem é sysadmin em seu ambiente e até onde ele pode chegar?
Sysadmin tem o privilégio máximo dentro de uma instância, podendo realizar qualquer ação, sem restrições. Uma das definições mais sinceras que eu já vi sobre o tema:

youReadMeRightSysadmin

Tradução tosca e livre: Sim, você leu corretamente. Sysadmin é sysadmin (administrador do sistema) e tem poderes divinos na instância.

 

Basicamente, ele possui dois poderes bem intuitivos:

-  Pode realizar qualquer atividade no servidor;
-  IGNORA qualquer checagem de segurança realizada pelo SQL Server (Ato conhecido como Bypass);

Permission Check Algorithm e Bypass

Antes de explicar o que é o bypass, é importante citar o algoritmo de checagem de permissão (Permission Check Algorithm), utilizado quando qualquer comando é executado no servidor.  Não citarei detalhes nesse post, mas uma série de verificações é realizada quando qualquer comando é disparado na instância…Uma das primeiras verificações que o algoritmo faz no comando é localizar nas informações de permissionamento se há algum  DENY que esteja relacionado com os logins  envolvidos. Se houver algum DENY, o acesso é mal-sucedido

E porque o algoritmo procura o primeiro DENY que seja de seu interesse?

Porque o DENY (Negação) SEMPRE sobreescreve qualquer outra permissão. Essa é uma verdade para toda entidade no SQL Server, exceto uma certa role de servidor, e adivinha qual é? O Sysadmin. é claro! Não importa qual ação realize dentro de determinada instância, se naquele contexto de execução pertencer a um sysadmin, automaticamente o servidor diz: – “Ok, você pode fazer tudo aqui, não preciso sequer checar as suas permissões”. Já viu um empregado barrar o patrão da casa? É tipo isso.

E aí ocorre o que é chamado de Bypass, que em tradução livre, significa ignorar, e é literalmente o que acontece quando a execução é realizada no contexto de um sysadmin: ele ignora o algoritmo de checagem de permissão. É mais ou menos o que acontece quando um carro do DETRAN ou da PM (em exercício de sua profissão) faz um cavalo de pau e sobe no meio fio  acelerando. Não tem problema (pra eles) eles agirem assim. Contudo, seres normais normalmente seriam checados e barrados/multados, pois não possuem permissão pra fazer esse tipo de coisa.

Como o SQL Server não precisa realizar as checagens, internamente, é uma etapa a menos no ciclo de vida de um comando. Isso durante algum tempo levantou o seguinte argumento: “todo comando executado pelo sysadmin é mais rápido”.  Não é mito, é uma verdade por causa do bypass que ocorre entre o comando e as checagens de segurança do SQL Server, mas o ganho de desempenho na minha opinião não é justificável e logo tal argumento é irrelevante no quesito de performance.

Sysadmin pode tudo?

super1

Sim, sysadmin faz tudo o que todas as roles faz e muito mais (como por exemplo, uso da conexão DAC, uso de procedures como xp_cmdshell, etc).  O SQL Server entende que, os logins inseridos nesta role são extremamente confiáveis e que não precisam ser verificados em momento algum.

Parece simples entender o quão poderosa é a role, mas ainda assim é comum encontrar perguntas como:

- Como eu proibo o sysadmin de fazer backup?
- Como eu proibo o sysadmin de logar no SQL Server?
- Como eu impeço o sysadmin de dropar login?

Uma resposta pobre (mas resolve o problema, rs): tire do sysadmin. Existem mil implementações malucas para impedir ações de sysadmin mas todas elas são ignoradas devido ao Bypass. Um bom exemplo são triggers: elas podem até restringir a atuação de um sysadmin, MAS, são frágeis podendo ser desabilitadas e/ou até alteradas pela suposta vítima.

Agora, uma resposta sensata: Talvez CONTROL SERVER seja a solução.

CONTROL SERVER

squirel

Existe uma permissão que foi criada com o intuito de ser uma alternativa  ao sysadmin chamada CONTROL SERVER. Essa permissão tem direito,  a fazer praticamente tudo o que um sysadmin faria. Como o proprio nome sugere, essa permissão concede o controle inteiro do servidor, e logo, imagina-se que seja algo perto do termo irrestrito.

Pergunta óbvia: Ué, então qual é a diferença entre essa permissão e a role sysadmin?

A resposta é simples! Como é uma permissão e não uma role, O SQL Server vai executar o algoritmo de checagem de permissões normalmente, sem realizar o bypass e vai considerar todas as etapas,  inclusive a etapa em que DENY é verificado! Ou seja, um DENY pode barrar quem possui um CONTROL SERVER.
Em outras palavras, é possível você ter um login com CONTROL SERVER mas que não possa criar bases (concedendo um DENY ALTER ANY DATABASE) por exemplo. Esse exemplo não se aplica para o sysadmin (é impossível negar que o sysadmin seja impedido de qualquer ação dentro determinada instância, conforme já vimos aqui). Contudo, um login com CONTROL SERVER já tem a faca e o queijo na mão: mesmo que ele tenha permissões negadas, existem N formas de ele mesmo recuperar as suas permissões através de escalação de privilégios. Vale lembrar também que um securable  com CONTROL SERVER pode ser propagado para outros logins mesmo que o WITH GRANT OPTION não tenha sido utilizado no ato da concessão do privilégio.

Outra observação: CONTROL SERVER apesar de ser a permissão mais elevada de todas não pode lidar diretamente com  server roles (por exemplo, incluir ou excluir alguém da role). Significa que um login com CONTROL SERVER não pode acrescentar outro em qualquer server role, e muito menos alterar ou remover logins dentre os sysadmin…

Securityadmin e Control Server, existe uma relação entre os dois?

alexrossposter-art

Em várias documentações, artigos e etc, inclusive da Microsoft, é dito que você deve tratar o securityadmin como equivalente à sysadmin. Essa é uma declaração um tanto quanto séria, certo? Vimos que tecnicamente securityadmin tem permissões importantes porém diferentes e nem  tantas quanto um sysadmin tem, como foi visto no post sobre essa role, na mesma série.

Veja esse truque: mesmo que ele mesmo não possua a permissão CONTROL SERVER, o securityadmin pode conceder essa permissão para outro login. É um conceito similar ao de “escalação de privilégios”, o que vai possibilitar, de fato, se aproximar de um privilégio similar ao sysadmin.

Lembram do post onde o securityadmin conseguiu burlar a restriçao de criação de bases criando outro login?
A mesma lógica é utilizada no exemplo abaixo:


CREATE LOGIN guardinha WITH PASSWORD = '', CHECK_POLICY=OFF

EXEC SP_ADDSRVROLEMEMBER 'guardinha','securityadmin'

 

2) Logue como guardinha. Tente dropar uma base, e você verá que ocorrerá um erro, assim como aconteceu no post passado. Ainda como guardinha, crie um outro login e atribua a permissão de CONTROL SERVER pra ele.


CREATE LOGIN darthVader WITH PASSWORD ='',CHECK_POLICY=OFF;
 GO
 GRANT CONTROL SERVER TO darthVader ;

 

Pronto. Basta logar como DarthVader e ter a força, pra fazer quase tudo o que um sysadmin faria.

Conclusão: É correto dizer que securityadmin equivale a um sysadmin? NÃO, pois primeiramente é necessário escalar privilégios de outros logins. E ainda assim, existem coisas que só o sysadmin pode fazer.

Sysadmin Only

Mal aí amigo, mas isso aí você não consegue fazer não

Nem tudo que o Sysadmin faz pode ser realizado por um login com CONTROL SERVER, pois caso algum código verifique:

  • Se o login está dentro de alguma SERVER ROLE, como por exemplo a função  IS_SRVROLEMEMBER();
  • Se determinado login está especificamente dentro da server role sysadmin (Via IF’s e similares);

Vamos sair da teoria e partir pra um exemplo prático? Esse é o código da SP_READERRORLOG, que é uma procedure utilizada para ler o errorlog (duh!), cuja concepção foi realizada pensando nos securityadmins.

Xp_readerrorlog De cara vamos uma verificação específica: se o login e/ou seu contexto de execução de quem tiver executando não for securityadmin, aborte a operação e mostre um erro. Um detalhe importante que vale citar aqui: como o sysadmin possui permissão total, ele passa em qualquer verificação da função IS_SRVROLEMEMBER.

É por isso que a única role que pode executar essa procedure além do securityadmin, é o sysadmin (pois ele retorna TRUE no valor de 1 em qualquer verificação realizada pela função IS_SRVROLEMEMBER). E justamente por causa dessa verificação, um login com CONTROL SERVER se não estiver em nenhuma das server roles citadas acima, não vai conseguir executar a procedure (simplesmente por causa da verificação que é bem específica). Curioso, não?

Existem vários workarounds pra resolver o problema, e alguns são óbvios e bastante fáceis. Não serão abordados aqui, mas são possíveis :)

Existem outras operações que também realizam a verificação específica de server roles, algumas especificamente o sysadmin.  Por exemplo, operações do SQL Server Agent, uso de conexão via DAC, dentre outros.
Quem deve ser Sysadmin?

uniforme

A resposta é clara e simples: pessoas na qual você pode confiar a instância inteira do SQL Server.

E lembre-se da regra sagrada do milagre da multiplicação (e por um milagre divino muita gente não sabe disso): Um sysadmin pode atribuir o mesmo privilégio para outros.

Tenha cautela com o sysadmin que não sabe o poder que tem e acaba descobrindo! Sysadmin que acaba de descobrir que tem superpoderes é igual a um mutante dos X-men que acabou de descobrir que tem superpoderes mas não tem muita noção de como controlá-lo. E geralmente um poder mal controlado e mal aplicado pode resultar em desgraça desastres.

 

Ciclope

 

Embora CONTROL SERVER seja uma permissão extremamente poderosa e possui milagre da multiplicação (aka pode propagar sua permissão para outros), ainda é inferior ao sysadmin e pode ser uma opção a ser considerada.

 

E assim chega ao fim a série sobre server roles! Foi divertido escrevê-la.

Alguma observação? Elogio, crítica? Marvel é melhor que a DC Comics? Sim ou com certeza?

Fique à vontade para comentar.

Referências

Why CONTROL SERVER doesn’t cut it  (Bom exemplo sobre um caso onde o CONTROL SERVER não é suficiente)

http://www.sqlservercentral.com/blogs/brian_kelley/2010/10/26/why-control-server-doesn-t-cut-it/

Permissions (Leia mais sobre o Permission Check Algorithm)

http://msdn.microsoft.com/en-us/library/ms191291.aspx

 

 

 

Executar como usuário diferente : Runas com ShellRunas.exe

Imagem

Olá,

Dica rápida de hoje: Às vezes, você precisa executar algum programa sob o contexto de outro usuário do Windows. Geralmente esse objetivo é alcançado quando se segura SHIFT + Botão Direito para localizar a opção “Executar como usuário diferente” (opção em português)  ou Run as different User (em inglês), popularmente conhecida como Runas.

Um exemplo:

Imagem

Porém, podemos topar com programas que não possuem o Runas em seu contexto. No exemplo, vamos usar o Excel 2010.

Imagem

Existem diversas soluções pra resolver a falta desta opção e apenas uma delas  é abordada neste post: se não temos um runas, vamos criá-lo com a ajuda de um utilitário da suite sysinternals chamado ShellRunas.

O processo de instalação é bem simples:

1) Saiba onde encontrar o instalador do ShellRunes (ou copie ele para algum diretório que você saberá alcançar via cmd. No exemplo usei o C: raíz);

2) Abra o cmd (Winkey + R) ;

3) Navegue até o diretório onde se encontra o executável (cd… cd.. opa, chegou :D) e digite ShellRunas.exe /reg. Você deve receber uma mensagem de confirmação dizendo que a opção foi registrada no menu de contexto.

Imagem

Pronto, agora se você tinha algum problema ao executar programas que não tinham o Runas em seu contexto, foi resolvido:

Imagem

Caso você queira tirar a opção, faça a mesma coisa do tutorial porém use o parâmetro /unreg

Espero que a dica tenha servido para alguém, pois aí valeu a postagem.

Até o próximo post!

AlwaysOn no SQL Server 2014 e novidades lunares que talvez te interessem!

Imagem

“Esse cara pode ser um san admin futuramente” – Fonte: NASA

Boa noite!
Tá vendo aquela lua que brilha lá no céu?
A lua tecnicamente não brilha por si só, apenas reflete a luz do sol. Legal, né?
Quero compartilhar duas notícias (na verdade mais importantes do que realmente parecem) que sairam recentemente e vi na internet. Links do Olhar Digital:

Fantástico!

E o que isso tem relação com o SQL Server 2014?
Quero compartilhar com vocês três assuntos diferentes:

1) HA e DR com SQL Server 2014 AlwaysOn Availability Groups;
2) Quando a zueira disponibilidade não tem limites, nem na terra nem na lua;
3) O que podemos esperar daqui pra frente?;

O que  é AlwaysOn?

Introduzida no SQL Server 2012, uma nova tecnologia de alta disponibilidade (High Availability, aka HA) e Recuperação de Desastre (Disaster Recovery, aka DR) chegou atraindo bastante atenção no mercado. Estamos falando do AlwaysOn (que agora virou uma buzzword/categoria também), mais especificamente do AlwaysOn Availability Groups (Grupos de disponibilidade) que repetidamente será escrito como AG, neste post, que permite a replicação de um grupo de bases de dados.

Veja bem, isso é uma solução inédita e não se trata apenas da evolução de outras features do SQL Server, embora constantemente ela seja bastante associada com o Mirroring, com uma certa razão, embora muito superior a este , já que o mirroring possibilita criar réplicas mas sempre 1:1 enquanto Grupos de disponibilidade replicam, grupos de várias bases para N réplicas, onde o valor de N dependerá da versão do SQL Server utilizada.

Nem vou abordar outras tecnologias de Alta Disponibilidade e DR nesse post, pois não é o foco. Quero falar (e apenas um  pouco) do AG.

Creio que pela imagem abaixo, é fácil entender como funciona essa solução: Crie réplicas de grupos de banco de dados. Mas não apenas! Aproveite as suas réplicas.

 

Imagem

Printei do Introducing SQL Server 2012 – Ross Mistry e Stacia Misner

A grande maestria deste esquema é que você pode utilizar as réplicas para aliviar a carga de trabalho (workload) que as suas bases principais (que por razões de nomenclatura é chamada de réplica principal) possuem normalmente com operações bastante comuns, como por exemplo, Backup e realização de relatórios (e aqui pode incluir também aquele “SELECT simples” que envolve umas quinze tabelas de setenta mil linhas, direto em produção, kkkkk) além de, é claro, contar com uma excelente solução de Disaster Recovery (na minha opinião é a melhor tecnologia de DR do produto), enquanto também conta com Alta Disponibilidade caso seja necessário.

A replicação da réplica principal para a(s) secundária(s) pode ser síncrona (garantindo que a réplica secundária sempre terá o mesmo dado da principal: isso custa performance em troca desse tipo de segurança) e a assíncrona (bem mais performática, garantindo que a secundária terá o mesmo dado da principal, embora demore um pouquinho mais (e bem, bem pouco) que modo síncrono pra que haja essa igualdade).

Você pode configurar suas réplicas para terem preferências de atividades (por exemplo, uma réplica preferencial para leituras e outra pra retirada de backups, por exemplo) para melhor aproveitamento do seu ambiente! E como se já não fosse legal o suficiente, você pode contar com até quatro (4) réplicas secundárias.
Para maiores informações, verifique as referências do post.

E o AlwaysOn Availability Groups no SQL Server 2014?

Toda vez que leio algo sobre o 2014 sinceramente fico feliz em como ele traz boas surpresas, mesmo que talvez eu nunca vá utilizar em produção :D
Depois do Hekaton um grande destaque foi a melhoria realizada no AG.
Sente o drama:
- No 2012, era possível ter quatro réplicas secundárias. No 2014, esse número dobrou. Oito réplicas agora!
- Possibilidade de se ter secundários no Azure (!!!)

E pode não parecer tão importante assim (porque muita gente sabe que o Azure é legal mas por algum motivo que desconheço é bastante ignorado) mas traz um conceito bastante interessante quando falamos de Disaster Recovery: Replicação Geográfica (Geo-replication).

Geo-Replication?

Em resumo, Replicação Geográfica é uma abordagem utilizada pelo Windows Azure para manter sua estrutura extremamente estável, para garantir que não haja de forma alguma perda de dados. Existem vários Datacenters do Azure pelo mundo e os dados são replicados entre eles justamente para garantir tudo isso.

Em outras palavras: no momento que você envia uma réplica pro Azure,  de modo transparente a mesma  será replicada para outros Datacenters ao redor do mundo, garantindo uma confiança maior ainda na segurança dos seus dados (no sentido de não perdê-los em caso de desastre).

Já imaginou ter seus dados replicados para um site de DR fora de seu ambiente (justamente por estar na nuvem) e que tem redundância por ele mesmo mesmo que você não precise?

Isso é muito bacana da Cloud Computing inteligente e está aí disponível no SQL Server 2014 utilizando o Azure.

Tem também o armazenamento de backups do SQL Server para o Azure, mas esse assunto, embora seja muito interessante e relacionado com o tema Disaster Recovery, não será abordado aqui :)

Alguns vídeos caso tenha interesse sobre o Windows Azure (e seus humildes datacenters):

Mas bem, sabemos que temos vários Datacenters na terra. Existe alguma chance de termos fora dela?

Tá, e de onde você tirou a ideia de reunir lua, alwaysOn e SQL Server num post só?

O primeiro motivo é óbvio: tava muito tempo sem postar e PAM! Me aparecem essa duas notícias. Achei legal compartilhar.
O segundo motivo: falar um pouco (quase nada, mas já é alguma coisa) sobre SQL Server 2014.
O terceiro motivo é pra interligar um relato engraçado sobre tudo isso.

Que relato?

Era uma vez alguns prezados dentro de um carro em movimento, conversando exatamente sobre essa nova habilidade do AG no SQL Server 2014 onde ter réplicas no Azure é uma possibilidade. Até que o prezado eu#### comentou que se um meteoro cair na terra, ainda assim ia ter réplicas de pé pra de alguma forma manter a continuidade do negócio (vale lembrar que tal meteoro em momento algum foi citado como “suficiente pra destruir a terra inteira”).

O final dessa conversa foi bastante polêmica, pois existem várias versões sobre ela onde cada um entendeu uma coisa diferente (e pra deixar a brincadeira rolar, não vou contar a original, pois vão me chamar de tendencioso, obviamente. Stakeholders do assunto, fique à vontade para usar os comentários  *risos*) mas a conclusão que grande parte dos envolvidos saiu é que: é bem provável que todas as soluções de HA e DR não saiam do nosso planeta mesmo que se fosse pra algo perto, tipo a lua. Lembro como se tivesse escutado hoje as palavras “imagina a latência disso aí kkkkkk” e veja bem…voltamos ao começo do post com as notícias onde empresas já visam locais mais seguros que a terra para armazenar arquivos de extrema importância e agora, ficamos sabendo de um link wi-fi criado pela NASA e MIT que dá um banho na maioria das conexões existentes no Brasil.

Lembro que li isso rindo:

Imagem

Vou deixar esse dilema para os conspiracionistas de plantão.

Sendo direto: Existe alguém que acredita que a lua seja um lugar extremamente seguro pra guardar ativos que considera importante. Ou não é tão seguro, mas pelo menos tá longe da Terra (sacou o pensamento de contigência?).

Será que os grandes players do mercado de SGBD’s possuem interesse em criar alguma solução  por lá também? A partir do momento que for rentável, não duvidaria dessa possibilidade. Vamos acompanhar….

Alguém chuta em qual versão do SQL Server (20XX) teremos réplicas lunares?

Teremos edições com nome mais sugestivos, tipo Interplanetary Edition?

Tem algum trocadilho engraçado, opinião, crítica, elogio, piada, versão do relato do meteoro pra compartilhar?

[]‘s

 

Referências:

Visão Geral AlwaysOn

Novidades no AlwaysOn no SQL Server 2014

 

Rápidas palavras sobre o Backup Compression

illformed-depth-of-field

Olá,

Existem várias técnicas e features no SQL Server relacionadas à compressão. Hoje vamos falar sobre compressão nativa de backup (não confundir com Data Compression).

O termo compressão na área de informática é o ato de reduzir o tamanho de um arquivo aplicando uma série de algoritmos, sendo  alguns deles destinados à retirar redundâncias após identificar padrões de dados repetidos(principalmente caracteres).

No final, o arquivo  que sofreu compressão possui menos bytes que sua forma original, e ainda assim, consegue representar o mesmo conteúdo quando for restaurado, pois assim como existe um processo para “encolher” os bytes de um formato normal para um formato comprimido, também existe um processo que realiza o inverso (traduz os bytes comprimidos para o formato original). Note que alguém precisa aplicar os algoritmos de compressão e fazer uma série de cálculos emcima deles. Alguém tem que trabalhar, não é mesmo? Esse alguém é a CPU, que realiza essa atividade tendo uma carga de trabalho maior que o normal.

Vantagens

O que podemos alcançar com a compressão? Menor espaço em disco ocupado pelos arquivos que sofreram compressão e ganho de desempenho em vários casos, seja na geração do arquivo ou na transmissão do mesmo via rede (se ele está menor, certamente demorará menos para ser copiado, por exemplo). Você já deve imaginar que um menor tamanho do arquivo nos traz uma vantagem inestimável: ganho em operações I/O, e a vantagem disso é refletida de várias formas, como por exemplo, a transferência via rede aumenta consideravelmente, menor uso de memória e menor espaço ocupado em disco.

A grande sacada da compressão de backup é que, no ato em que um BACKUP DATABASE, aquele backup está sofrendo compressão no ato da sua execução. O SQL Server não espera realizar o backup do arquivo para depois aplicar compressão. O arquivo em questão já “toca” o disco com tamanho reduzido.  E de quebra seu backup poderá ser realizado mais rápido.
Veja um exemplo de uma base depois de um COMPRESSION:

Exemplo de base depois de compact...não pera.

Exemplo de base depois de compact…não pera.

 

Errei a imagem…

Dois backups. Um com compressão e o outro não.

Dois backups. Um com compressão e o outro não.

 

“Desvantagens”

O uso da compressão exige um trabalho extra da CPU, e portanto, deve ser utilizada cuidadosamente, dependendo do cenário. Por exemplo, se você faz backup em horário de rush onde o servidor está com alto processamento de CPU, talvez não seja interessante tirar um backup comprimido, pois a transação do backup pode impactar em outras, gerando concorrência e atrasos nelas.

Na minha opinião, considerar isso como “desvantagem” é extremamente relativo. Prefiro chamar de “o preço que se paga”. Soa mais justo pois nada nesse mundo é de graça e não existe mágica sem truque. E com a compressão, não é diferente.

"Todo almoço tem seu preço, meu filho" - JOBS, Steve

“Todo almoço tem seu preço, meu filho” – JOBS, Bill

Se você tem esse trade-off onde você ganha economia de espaço e operações de I/O mais rápidas (bom pro disco, memória e rede) e em compensação precisa pagar por um pouco mais de processamento na CPU, será que não vale a pena? Na maioria dos casos onde o uso de CPU não é intensivo, será mesmo que existe desvantagem nessa troca?
Já trabalhei em um cenário onde backups compactados (FULL na Quarta e Domingo, DIFF nos demais dias) eram tirados toda noite por volta de 1h. Janela tranquila, CPU mais mansa que peixe beta, o uso deste recurso se mostrou bastante compensatório, principalmente porque no final os backups eram estocados em fita. Em resumo: a causa de maior medo ao utilizar o recurso que é o aumento de trabalho de CPU foi algo a ser desconsiderado nesse caso. E creio que existem inúmeros cenários similares.

Você pode utilizar compressão nos arquivos de backup FULL, DIFERENCIAL e LOG.

Restrições

As duas principais restrições envolvendo compressão de backup:

1) Quando você guarda seus backups em um mediaset (ou seja, mais de um backup por arquivo), todos devem ser comprimidos ou nenhum. Não se pode ter no mesmo mediaset um backup comprimido e outro não.

2) Restrições de versões/edições do SQL Server (ver o tópico Compatibilidade)

Para mais informações, verifique as referências no final do post.

 

Compatibilidade

O recurso foi introduzido no SQL Server 2008 Enterprise (Developer e Trial herdam também) e desde o SQL Server 2008 R2 está disponível em todas as edições do produto. Um detalhe importante é que se você tentar restaurar um backup compactado tirado duma instância 2008 Enterprise e tenta restaurar em uma instância 2008 Standard, um erro ocorrerá no Management Studio.

No  SQL Server 2005 e anteriores, não existe solução nativa para compressão de backups. A solução neste caso seria o uso de ferramentas de terceiros e o uso de criatividade: Uma das formas mais conhecidas é montar uma rotina em cmd shell pra realizar compressão utilizando algum utilitário, como o Winzip, para aplicar compressão DEPOIS que o backup já está em disco. Embora tais métodos não sejam tão práticos por não serem nativos, são possibilidades.

DEMO

Para ilustrar as diversas formas de compressão de backup, montei um cenário em ambiente de teste e tirei dois backups, um com compressão e outro sem compressão (modo normal).

Primeiramente, print do tamanho da base:

Prova Tamanho

 

 

 

 

 

E os backups realizados:

 

Script

 

Com esse simples teste, você já percebe algo surpreendente sobre a performance do backup com compressão pelos resultados comentados: ele demorou praticamente metade do tempo e consequentemente, realizou a operação de I/O com quase o dobro de eficiência. A parte divertida do negócio, além da performance incrível na realização do backup

 

Isso por si só (performance na parte de I/O) já é bastante significativa. Mas….e o tamanho do arquivo final?

Dois backups. Um com compressão e o outro não.

 

E tem como eu estimar o ganho que terei com a compressão de backup? Não existe para este caso nenhuma procedure (até o momento) nativa que realize essa estimativa, principalmente porque o ganho vai depender bastante do banco de dados em questão. A ideia é que você faça um backup utilizando compressão e analise os resultados. No banco de sistema MSDB, é possível verificar o ganho da base de exemplo:


SELECT
backup_set_id,
database_name,
backup_size,
compressed_backup_size,
backup_size/compressed_backup_size as [Ganho]
FROM msdb.dbo.backupset
WHERE database_name = 'DBIG'

O resultado:

Ganho

 

Sem fazer um código mais detalhado (com os devidos tratamentos), a última coluna revela que o backup comprimido é praticamente 6x menor que o tamanho original do backup (praticamente 83% menor).

 

Note também que no primeiro backup não utilizei compressão. O valor inserido na coluna compressed_backup_size é exatamente o valor do backup_size. Já no segundo caso, temos o tamanho correto da base comprimida. Exatamente por isso, que não é possível realizar estimativas (exatamente porque não existe um valor pra servir de base).

É importante mencionar também que, caso a base esteja utilizando TDE (Transparent Data Encryption), o ganho na compressão do backup é irrisória ou perto de zero.

EDIT: Se sua base já tiver compressão de dados, você pode utilizar compressão de backup também e pode se surpreender com a quantidade de ganhos que isso traz. Vários profissionais já fizeram o teste e comprovaram que o grau de compressão é ainda maior, e faz sentido. Imagine que a compressão de dados cria dicionários (utilizados pelos algoritmos de compressão) baseado em páginas e a compressão de backup cria um dicionário para a base inteira…

Como fazer?

Existem várias formas de realizar um backup compactado:

1. Uso de cláusula WITH COMPRESSION

Forma mais simples.

Compress

 

 

2.  Via SP_CONFIGURE

Permite que você mude a configuração padrão fazendo com que todo backup utilize compressão por padrão (mesmo sem declarar no corpo do backup a cláusula COMPRESSION nos parâmetros via WITH):

 

Run Value

 

 

 

 

 

 

Apenas ative essa opção se você estiver totalmente seguro que sabe o que está fazendo e o que será impactado.

3.  Via Management Studio

Sem tirar nem pôr faz a mesma coisa que a segunda opção (seta o default pra compressão e reconfigure), a diferença é que isso é feito de modo gráfico. Botão direito na instância, Propriedades, Database Settings e pronto:

Sem tirar nem por

 

Bônus: Para quem  tiver curiosidade, existe um trace flag que trabalhando junto com a compressão aumenta ainda mais a transferência de I/O em disco. O motivo disso é uma alteração no comportamento de estimativa de espaço que o SQL Server deve reservar pro backup que está sendo realizado. Caso se sinta curioso(a), veja o link nas referências [3].

 

E os restores?

EDIT: Depois de publicar o post, me perguntaram em relação à performance do RESTORE, se o ganho é tão perceptível quanto o BACKUP. Fiz uns testes rápidos na mesma máquina (e sob as mesmas condições de uso) e os resultados foram:

 

– Restore backup comprimido

RESTORE DATABASE successfully processed 484625 pages in 114.127 seconds (33.174 MB/sec).

– Restore backup normal

RESTORE DATABASE successfully processed 484627 pages in 133.096 seconds (28.446 MB/sec).

Mais um ponto pro backup comprimido =)

Finalizando
Compressão é sinônimo de economia. Em vários casos, essa economia pode ser tão compensatória em relação ao preço que se paga que podemos até dizer que é um recurso que economiza espaço de graça.

E aí, você já usou ou está pensando em usar compressão nativa do SQL Server nos backups?

Conhece ou usa alguma ferramenta de terceiros? Alguma observação sobre isso?

Quer relatar algum resultado de testes realizados?

Acha que é cilada?

É boa, pode usar sim?

Vai ter copa?

Fique à vontade para comentar.

 

Referências:

[1] Compressão - http://pt.wikipedia.org/wiki/Compress%C3%A3o_de_dados

[2] Backup Compression - http://technet.microsoft.com/pt-br/library/bb964719.aspx

[3] Trace Flag 3042 – http://support.microsoft.com/kb/2001026/pt-br

Vamos estudar SQL Server 2014?

Imagem

Oi,

Pra variar, é um dos posts que eu escrevo quando o pão já esfriou \o/

O SQL Server 2014 saiu oficialmente tem pouco tempo (1° de Abril) e muito tem se falado sobre ele.

Várias features melhoradas, abraça a nuvem como uma mãe abraça um recém-nascido e que tudo tá muito rápido, tão rápido que todo mundo que fala sobre ele se emociona/empolga. Agora temos dados não apenas em memória, mas designados para a memória. É outra história. É algo alucinadamente mais rápido que o convencional já nos traz. É outro paradigma que já fez o 2014  se tornar um marco, e que será algo ainda maior…

Porém, poucas pessoas de fato estão explorando as novidades e caso esse seja o nosso seu caso, que tal começar agora?

 

Mas e as referências? O que temos?

Download: Baixe a versão Trial aqui

EDIT: O Gustavo mencionou o Cumulative Update 1, que contém um bucado de fixes. Muito bem lembrado!

Documentação: Books online for the win.

Livro: Como manda a tradição, saiu uma nova versão do SQL Server, sai um livro. Procure por Introducing SQL Server 2014

Bases pra teste: se você deu um sorriso e pensou em AdventureWorks2014, ainda não. Mas tem a versão 2012 que pode ser o rato de laboratório enquanto ele não é atualizado.

O time de produto disponibilizou um script para transformar algumas tabelas do AW2012 em tabelas in-memory. Baixe aqui.

Novidades: Nada melhor do que o What’s New pra começar a ver o que tem de bom. Tem muita coisa que eleva o SQL Server em outro nível (Feature que tinha um nome daora, Hekaton, que agora se chama In-Memory OLTP), outras que podem auxiliar em determinados cenários onde se tem discos rápidos (exemplo: SSD’s mas não somente) como o Buffer Pool Extension e pra quem já é sortudo o bastante para trabalhar com AlwaysOn, houveram diversas melhorias, como a integração com o Azure, fazendo com que poucas coisas possam dificultar a continuidade do negócio, como por exemplo, um meteoro que destrua a terra inteira.

Pra conferir TODOS os demais recursos , clique aqui (referência completa e extensa).

Um compilado de várias séries realizadas sobre o assunto (MSFT Blogs)

Temos também vários artigos na internet, blogueiros, tuiteros e algumas pessoas da comunidade técnica falando sobre isso vez ou outra (e algumas falam sobre o 2014 desde 2013 inclusive, com conteúdo top!), e não é difícil encontrar tais conteúdos. Eu vou fazer minha parte e de vez em quando postar (humildemente) alguma coisa sobre isso também.

 

 

E bem, ainda quero terminar meu post sobre sysadmin da série Roles do SQL Server, vida e obra.

Em breve…

 

 

 

Roles do SQL Server – Setupadmin e Securityadmin

molde

 

Olá,

Penúltimo post sobre a série, o tema serão as roles Setupadmin e Securityadmin.

Setupadmin

É uma role simples de entender e mais ainda de descrever.

  • Add member to setupadmin: Também conhecido como milagre da multiplicação. Adiciona outro membro da role.
  • Add/drop/configure linked servers: Possui a permissão de adicionar, editar e deletar configurações de Linked Servers. É, basicamente, a função primária dessa role.
  • Mark a stored procedure as startup: Tá aí uma funcionalidade interessante (embora não seja, comumente, necessária). É possível configurar uma stored procedure para ser executada toda vez que o SQL Server é iniciado. Para quem tiver interesse, tem uma referência pro Books Online no final do post.

Em suma, geralmente, quem realiza configurações de linked servers na maioria das vezes são pessoas que detém a maioria ou todas as  credenciais do ambiente. Geralmente, essa tarefa é realizada por pessoas com permissões mais elevadas. Se você imaginou sysadmin, ponto pra ti.

Securityadmin

O último post da série é sobre sysadmin, então, nada mais justo que o seu filho seja apresentado primeiro.

Abaixo de sysadmin, Securityadmin é a server-role mais importante sem sombra de dúvida, com permissões bastante elevadas.

Vejamos:

  • Add member to securityadmin: O milagre da multiplicação já mencionado em outros posts.
  • Grant/deny/revoke CREATE DATABASE: Aqui vai uma permissão no mínimo curiosa. Qualquer securityadmin consegue manipular as permissões de CREATE ANY DATABASE para qualquer outro login. E por muita curiosidade (pode testar pra conferir), o mesmo ocorre para o comando ALTER ANY DATABASE. Em suma, securityadmin pode realizar esses comandos abaixo sem pudor nenhum:
GRANT CREATE ANY DATABASE TO loginQualquer;
GRANT ALTER ANY DATABASE TO loginQualquer

Esse tópico merece uma demo rapidinha, só pra degustação….

Crie um login  chamado mestre:

CREATE LOGIN mestre WITH PASSWORD = '', CHECK_POLICY=OFF;
EXEC SP_ADDSRVROLEMEMBER 'securityadmin',mestre;

Agora, logue como o  “mestre”.
Você sabe que, como securityadmin, pode conceder permissão de CREATE e ALTER ANY DATABASE. Mas o que acontece quando se tenta conceder permissão pra si mesmo?

GRANT CREATE ANY DATABASE TO mestre;

Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.

Aí o mestre pensa: pô, mas se eu não posso conceder permissão pra eu mesmo…


CREATE LOGIN minimestre WITH PASSWORD ='',CHECK_POLICY=OFF;

GRANT CREATE ANY DATABASE TO minimestre;

Problema resolvido. Agora o mestre vai usar o login que acabou de criar, o minimestre, e vai executar o comando:

CREATE DATABASE TomeEssaSociedadeHAHA

Guarde esse workaround com você. Você verá o quanto isso é importante no post sobre sysadmin.

  • Read the error log: Sem dúvida outra habilidade importante que o securityadmin pode desempenhar. O errorlog do servidor possui informações importantes, principalmente no que tange à configuração do SQL Server.
    A procedure a ser utilizada, neste caso, é a sp_readerrorlog.
    Uma curiosidade interessante: A XP_READERRORLOG, que é mantida por motivos de compatibilidade e faz exatamente a mesma coisa da sp_readerrorlog não vai ser executada pelo securityadmin. É uma pequena curiosidade pra quem gosta de aprender uma coisa diferente por mais pequena que pareça todos os dias.
  •  sp_addlinkedsrvlogin/sp_droplinkedsrvlogin: Adiciona, altera ou remove mapeamentos entre um login de instância e uma conta de segurança em servidores remotos. Em suma, essas permissões dão direito à edição em logins também no contexto de linked servers.
  • sp_dropremotelogin: Possibilita remoção de um login que está em servidores remotos que está mapeado para um login local. Esse recurso está em deprecated, btw.
  • sp_defaultdb – sp_defaultlanguage  sp_password: Possibilita alterar algumas informações dos logins. Essas procedures estão deprecateds, e agora, a construção que deve ser utilizada é a ALTER LOGIN. A correspondência de cada comando seria:

sp_defaultdb -> ALTER LOGIN  mestre WITH DEFAULT_DATABASE = master

sp_defaultlanguage -> ALTER LOGIN mestre WITH DEFAULT_LANGUAGE = british

sp_password -> ALTER LOGIN mestre WITH PASSWORD = ’123′

  • sp_droplogin: Deleta um login do SQL Server. Essa procedure está em deprecated e você deve utilizar a construção correspondente (no caso, seria DROP LOGIN)
  • sp_denylogin: Procedure específica para negar acesso à logins do Windows (seja de usuários individuais e grupos).
  • sp_revokelogin: Procedure que revoga uma permissão de login. Como é um comando deprecated, não vamos nos atentar a ele.
  • sp_grantlogin: É a criação do login propriamente dito. A procedure foi substituída pela instrução….CREATE LOGIN, claro :D
  • sp_helplogin: Procedure que trás informações sobre o login (como banco default, linguagem e usuários e em quais bancos ele tem permissão (e de que) :

 

Polis

 

  • sp_remoteoption: Permite mostrar e alterar configurações para logins remotos. Essa opção é deprecated.

 

Em suma, é uma server role poderosa. Pode ser usada caso você precise de alguém para gerenciamento de logins, mas por algum motivo não é interessante conceder sysadmin. É uma opção, mas é importante saber alguns pormenores, como o exemplo de criação de bancos.

 

EDIT PLANEJADO: Existe uma permissão muito importante que faz com que a Microsoft diga que securityadmin  equivale à sysadmin. Não coloquei essa informação de inicio, pois, precisava antes desenvolver a ideia do sysadmin. Peço que, caso tenha interesse, leia o post do sysadmin, pois ele é essencial para complementar a real importância do securityadmin.

 

Próximo e último post da série: sysadmin!

[]‘s

 

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 caso possua essa necessidade.

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 novo 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 tal afirmação, mude o nome da máquina, faça um SELECT @@SERVERNAME e veja que o nome antigo ainda consta nos registros.

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, fique ligado.

Reforçando  a resposta do post: quiser mudar o nome da instância, reinstale com o nome correto :)

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