Continuando nossa série sobre licenciamento de SQL Server, lembrando que o que estamos falando aqui se aplica para a versão do SQL Server 2008 R2 (e não necessariamente serão as mesmas para o SQL Denali) e que as regras efetivamente devem ser vistas no PUR – Product Use Rights.

Hoje falaremos de SQL Server em ambientes virtualizados.

Já sabemos que caso eu deseja instalar o SQL Server numa máquina física eu preciso licenciar todos os processadores, ou usar Server/CAL.

Mas e em ambientes virtualizados? A resposta é o famoso: depende!

Primeiramente temos que nos ater a uma tabelinha que diz em quandos OSEs (operational system environments) vamos poder rodar o SQL Server caso compremos licenças por processador para TODOS os processadores.

O que isso quer dizer? Quer dizer que caso licenciemos TODOS os processadores é possível, dependendo da edição, instalar em mais de um ambiente que rode naquela mesma máquina (ambientes virtualizados).

Como podem ver é de acordo com a edição do seu SQL Server (saiba quais são as edições aqui).

Isso signica que se eu tenho um servidor com 4 processadores físicos (não importa o número de cores) e licenciei todos os processadores com licença enterprise (4 licenças) eu vou poder subir até 16 máquinas virtuais e com o SQL Server instalado em cada uma delas.

Se eu comprar 4 licenças Datacenter, posso subir ilimitadas (desde que seu hardware suporte) máquinas virtuais!

É importante frisar que há uma limitação técnica do SQL Server Enterprise de suporte a até 8 processadores! Se o servidor possuir mais que 8 processadores físicos, a edição a licenciar deve ser a Datacenter.

Bom Zavaschi… mas quando virtualizo eu posso apresentar um número menor de cores para a minha máquina virtual (hyper-v por exemplo é possível apresentar até 4, isso vai aumentar na próxima versão) e nesse caso eu não vou usar todos os recursos da máquina, preciso licenciar todos os processadores? Mesmo que eu queira saomente uma máquina virtual (1 OSE)?

A resposta é não! Neste caso há uma pequena conta a se fazer para saber o número de licenças por processador que você irá necessitar por OSE.

Vamos lá. A imagem abaixo mostra o SQL Server 2008 R2 rodando em uma máquina com um processador físico (dual core). Neste cenário o número de núcleos importa.

A conta a se fazer é:

# de processadores virtuais dando suporte os OSE virtual
/
# de núcleos (hyperthreading desativado) ou threads (se o hyperthreading estiver ativado) por processador físico
=
# de licenças de Processador necessárias (se de rnúmero fracionado, arredonde para cima)

Se estamos apresentando 2 processadores virtuais para a VM e ela possui dois cores, então a conta fica 2/2 que resulta em uma licença por processador.

Em um cenário maior:

Temos 4 processadores físicos octacore. Apresentamos 4 processadores virtuais para a máquina virtual. São necessárias quantas licenças de processador?

Fazendo a conta: 4 / 8 = 0,5. Logo, 1 licença (mesmo tendo 4 processadores)!

Novamente: isso é por OSE! Se tiver duas máquinas virtuais, cada uma com 4 processadores virtuais, seriam 2 licenças. A tabela abaixo resume o cálculo:

É isso pessoal. Apesar dos cenários e arquiteturas em alguns casos serem complexos, o processo de licenciamento só precisa ser acompanhado com a ótica correta. Aguardo o feedback de vocês!

Abraços,
Thiago Zavaschi

Tive o prazer de ser convidado pelo Nikolas (@nikolasmoya) para dar uma palestra na semana acadêmica de Ciência da Computatação da Pontifícia Universidade Católica do Paraná.

O evento ocorreu ao longo da semana passada e a minha palestra foi na segunda-feira (25/07). Particularmente para mim foi muito bacana pois pude retornar a universidade na qual me formei (em ciência da computação!) e onde fiz meu mestrado em informática também!

O tema foi sobre Business Intelligence. Hoje nas corporações é um tema muito relevante e recorrente, maso meu desafio foi como tratar do assunto quando estamos falando com estudantes (e de noite, quando já estão cansados)?

Procurei fazer algo um pouco mais descontraído e acho que o resultado foi bem bacana.

Segue a apresentação e os links que coloquei como referência nos slides:

Download da apresentação

− Centros de Treinamento TechNet/MSDN
http://technet.microsoft.com/pt-br/treinamento

− TechEd - www.techedbrasil.com.br

− http://powerpivotfaq.com

− http://ssas-info.com

− http://powerpivot-info.com

− www.microsoft.com/bi

− www.powerpivot.com

Abraços e espero os próximos anos!

Lembrando que ao longo dessa semana temos a semana de SQL Server (http://bit.ly/kQY8Zl) e hoje a noite palestro sobre BISM e a nova versão do PowerPivot (self-service BI)!

[]s
Thiago Zavaschi

Vocês conhecem as melhores práticas, estratégias e execução de capacity planning quando o assunto é compressão de dados?

A feature de compressão de dados (e de backup) está disponível desde o SQL Server 2008 mas ainda é pouco explorada nos ambientes que conheço.

Recomendo o seguinte whitepaper de maio de 2009 (não contempla o SQL Server 2008 R2, que ganhou a capacidade de compactação em Unicode também):

http://msdn.microsoft.com/en-us/library/dd894051(SQL.100).aspx

Para saber mais sobre a compactação no SQL Server 2008 R2, recomendo:

http://www.mssqltips.com/tip.asp?tip=2019

Os artigos são em inglês. Em breve publico uma adaptação aqui no blog para o português.

Abraços!

Recebi essa dúvida no meu e-mail e por ser pertinente estou fazendo esse post.

“Como saber quem está conectado no meu servidor do Analysis Services?”

A resposta é simples: existem DMVs no SSAS (!!!) que podem retornar informações sobre recursos, objetos e desempenho. As DMVs em geral são utilizadas no database engine, mas existem no servidor de análise também.

Mais diretamente, para saber quem está conectado no meu servidor SSAS basta executar:

SELECT * FROM $system.DISCOVER_CONNECTIONS

A DMV similar a procedure sp_who2 para o Analysis Services é a seguinte:

SELECT * FROM $system.DISCOVER_Commands

Para obter uma listagem de todas as DMVs que podem receber consultas, utilize:

SELECT * FROM $system.dbschema_tables
WHERE Table_Schema = '$SYSTEM'

Como referência posso citar o livro: Microsoft SQL Server Analysis Services Unleashed, capítulo 41: Resource Monitoring.

Abraços e até o próximo post!

Vamos iniciar nossas discussões sobre licenciamento?

Antes de mais nada precisamos entender que todas as regras para o licenciamento Microsoft (não somente do SQL Server), bem como o que envolve os cenários estão em um documento chamado PUR (Product Use Rights) que pode ser baixando aqui: http://www.microsoft.com/licensing/about-licensing/product-licensing.aspx.

Outra coisa é que vou apenas tratar da parte do SQL Server, não vou entrar na parte de Windows Server que possui sua forma de licenciamento (diferentes cenários do SQL Server, external connector, etc…) própria.

Mais uma coisa: este licenciamento é valido para o SQL Server 2008 R2. Só é possível comprar licenças da versão mais atual do produto, mas o downgrade (para 2008, 2005, por exemplo) é possível.

Vamos lá. Lembrando que estas explicações ainda não estão cobrindo os cenários com alta disponibilidade (cluster, mirroring, etc) e nem virtualização. Trataremos disso em posts futuros.

Server + CAL (Client Access License)

Toda a linha de servers da Microsoft possui o licenciamento através do que chamamos de CAL (Client Access License), o que não é um software, e sim um documento que garante o acesso, e é necessário para cada usuário ou dispositivo que realiza acesso a este servidor.

Para esta forma de licenciamento deve ser adquirido uma licença para o servidor (server físico, independentemente do número de processadores) mais uma CAL por usuário/device.

Então vamos imaginar um cenário:

- Tenho um servidor físico com 8 processadores e 50 usuários. O que preciso licenciar/pagar?

Você vai precisar de UMA licença de server MAIS 50 CALs de usuários.

O meio para se chegar ao servidor de banco de dados não importa para o licenciamento da parte SQL Server no esquema de CAL. Continua sendo uma por dispositivo ou por usuário.

É importante ressaltar que tecnologias que fazem multiplexação ou pooling de usuários (aplicação que mapeia um único usuário de banco de dados, por exemplo) não reduzem o número de CALs necessárias.

- Ou seja, tenho um aplicativo que usa apenas um usuário para comunicação com o banco, então preciso de apenas uma CAL?

Não. Neste caso você precisaria de uma CAL de usuário por cada usuário da aplicação.

Partições ou blades separadas são consideradas servidores independentes no que tange a licenciamento.

Há também diversas edições de SQL Server, algumas delas, como a Web e a Datacenter suportam licenciamento apenas por processador. Cobrirei isso em um post futuro focando apenas nas edições.

Qual a diferença de CAL por dispositivo e CAL por usuário?

- O valor da licença por usuário e por dispositivo é a mesma, mas em que cenários eu devo adiquirir uma ou outra?

Imagine que você tenha o seguinte cenário:

O mesmo usuário acessando a base de dados de diferentes dispositivos.

Caso seja adquirido CAL por dispositivo, seria necessário 2 CALs. No caso da licença por usuário seria necessário apenas uma. Logo, licenciar por CAL de usuário, neste cenário, é mais interessante.

Em geral o cenário por CAL de usuário é o mais comum, mas há casos em que licenciar o dispositivo é melhor. Veja o cenário abaixo:

Tenho diferentes usuários (no caso 4, mas pode ser que talvez nem se saiba quantos) que fazem acesso a minha base de dados, mas através de um único dispositivo. Um exemplo comum neste caso são aquele tótens de auto-atendimento (comuns em aeroportos).

Neste cenário seriam necessárias 4 CALs por usuário ou então apenas uma por dispositivo. Logo o recomendado neste cenário é a compra de CAL por dispositivo (pois sai mais barato).

- Ok, mas eu tenho que escolher se compro somente CAL por dispositivo ou somente CAL por usuário?

Não! Você pode comprar “X” User CALs e Y “Device CALs” para o mesmo cenário. O importante é verificar qual o cenário que se enquadra para você.

Quando devo/é interessante licenciar através de Server/CAL ?

• Quando é possível contar o número de usuários e dispositivos.

• Quando o somatório do valor da licença + todas as CALs é inferior ao valor necessário pelo licenciamento por processador (ver abaixo), isto é, poucos usuários.
• Quando você planeja escalar horizontalmente, ou seja, colocar mais servidores para atender aos mesmos usuários. Neste caso seria necessário comprar adicionalmente as licenças de servidor e não as CALs.

Imagine o primeiro cenário com mais de um servidor:

A expansão neste caso seria “X” CALs de usuário + 3 licenças de servidor (independente da quantidade de processadores das máquinas).

Mas e nos cenários que eu não sei o número de usuários, na web por exemplo? Vou ter que comprar MUITAS CALs?

Neste caso não. Devemos fazer então o licenciamento por processador.

Licenciamento por Processador

No modelo de licenciamento que não é o Server + CAL o número de processadores importa.

Com o licenciamento por processador, o número de usuários é ilimitado sob o ponto de vista de licenciamento (esbarrando apenas na capacidade técnica do servidor).

Para este caso, SEM virtualização, o número de núcleos (com ou sem hyper threading) não importa. O termo processador se refere ao número de pastilhas físicas presentes nos servidores.

Imaginem o seguinte cenário:

Apenas um servidor com quatro processadores (16 núcleos), mas sem saber a quantidade de usuários. Cenários web e extranet se encaixam muito bem aqui.

Neste caso seriam necessárias 4 licenças do tipo “por processador”, não importa a quantidade de núcleos dos processadores para este cenário;

- Coloquei o affinity do SQL Server para apenas 2 processadores, posso licenciar somente dois processadores (ou menos que o total de processadores da máquina)?

Não! Não é possível. Para um cenário sem virtualização (cobrirei em post futuro) TODOS os processadores físicos devem estar licenciados (seja standard, enterprise ou datacenter).

Não importa se o acesso é feito pela mesma pessoa usando dispositivos diferentes, ou diversos usuários na web. O que interessa é ter todos os processadores licenciados.

Bom pessoal, este for o primeiro post da série sobre licenciamento. Espero que ajude vocês a entenderem melhor os cenários de licenciamento necessários ao adotarem o SQL Server como plataforma de dados.

Há ainda diversos cenários, mais complexos, como virtualização, alta disponibilidade (cold backup), diferentes edições do SQL Server (no que isso influencia), SQL Azure (como é cobrado na nuvem). Todos esses tópicos veremos na sequência!

Até a próxima!

Abraços,
Thiago Zavaschi

Sei que estou postando fortemente sobre Business Intelligence, mas hoje gostaria de iniciar algo diferente.

Se eu fosse elencar as dúvidas que recebo mais frequentemente dos clientes e parceiros, com certeza seria licenciamento em primeiro lugar.

A plataforma de dados da Microsoft é o SQL Server e o seu braço na nuvem é o SQL Azure. Por isso vou dividir esse conjunto de posts da seguinte forma (vou adicionar os links a esse post conforme os posts seguintes saírem), mas não necessariamente nesta mesma ordem.

• Server com CAL ou por processador?
• SQL Server, Analysis Services, Integration Services, preciso de uma licença para cada um?
• SQL Server com Cluster, Mirror e Log Shipping, o que preciso licenciar?
• SQL Server virtualizado e ambientes híbridos: Virtualizado + não-virtualizado.
• SQL Azure – Espaço, transferência? Como funciona e quanto custa?

A ideia dos posts é não é entrar na precificação (com excessão do SQL Azure), pois há várias modalidades contratuais e esses aspectos de contratos e programas de relacionamento com a Microsoft eu não irei abordar.

Gostaria de um feedback de vocês que leem o blog (nos comentários) sobre esta sequência de posts. Isso é muito importante! Aceito sugestões!!

Abraços,
Thiago Zavaschi

Hoje continuo com o tema DAX.

Introdução ao Contexto de Execução

Antes de entrar nas especificidades de cada função, conforme anunciei no meu último post que o faria, é importante frisar que o resultado obtido é sempre baseado no contexto atual. O contexto pode vir da tabela que você está trabalhando (novas colunas ao modelo) ou ao conjunto tratado pela measure.

E o que pode afetar/criar esse contexto?

Basicamente o contexto vem dos filtros aplicados (filtros nas funções ou slicers). Isso afeta o resultado esperado, por exemplo ao utilizar um slicer (segmentador de dados) temos uma redução de contexto.

Quando estamos trabalhando com valores relativos, por exemplo, considere o seguinte conjunto de dados e a seguinte DAX:

=SUM(Tabela[Categoria])

Temos um resultado semelhante a:

Neste momento estamos trabalhando com o conjunto total dos dados, mas ao marcar um slicer, por exemplo “Rock”, temos o filtro sobre o conjunto usado:

Ok, Thiago até aí ok, mas em que cenários que devo me atentar quanto a isso? Por exemplo, e se você possuir uma expressão DAX para calcular uma média, onde o denominador seja o somatório total das vendas ?

Algo como:

Vendas / Todas as vendas independente de categoria ?

Você poderia pensar em algo como =SUM(Tabela[Categoria])/SUM(Tabela[Categoria]), e manter a divisao por categorias, mas a conta não faria sentido, pois tanto o numerador quanto o denominador resultariam em um valor flutuante de acordo com o contexto.

Como resolver então?

Existem três funções que podem ajudar que são: CALCULATE(), ALL() e ALLExcept().

O CALCULATE serve para manipular o contexto, e o ALL e ALLExcept servem para retornar regiões dos dados de forma invariável ao contexto dos slicers (ALL) e podendo ter excessões (ALLExcept).

Na prática ficaria algo como:

=SUM(Tabela[Valor])/CALCULATE(SUM(Tabela[Valor]),ALL(Tabela))

Assim, mesmo aplicando um slicer, o resultado da medida (measure) para aquela categoria é baseado no valor total(denominador) e não mais no contexto dos slicers, veja:

Por hoje é só pessoal! :)

Este artigo é parte de uma série de artigos sobre PowerPivot e DAX. Confira os outros artigos sobre PowerPivot no link: http://zavaschi.com/index.php/tag/powerpivot/

Abraços!
Thiago Zavaschi

Se vocês analisarem a sequência de posts sobre Business Intelligence (http://zavaschi.com/index.php/business-intelligence/) vocês vão perceber que estou dando um foco grande em DAX. O motivo é claro: com a chegada do SQL Server 11 (Denali) também chega um novo modelo para as bases multidimensionais do Analysis Services conhecido como BISM (BI Semantic Model).

Através do Visual Studio 2010 será possível criar modelos do BISM (da mesma forma que criamos os modelos do PowerPivot dentro do Excel) e fazer o deploy para o servidor do SSAS.

Uma das grandes diferenças é que a manipulação do modelo BISM será feita usando DAX (e não MDX), sim a mesma DAX que temos hoje no PowerPivot Excel, acrescida de uma série de novas funções e capacidades.

Temos 35 funções nesta categoria na versão atual, é possível que esse número aumente quando possuirmos os modelos BISM (e podemos subdividir em 3 sub categorias):

1. Funções que retornam uma data
2. Funções que retornam uma tabela de datas
3. Funções que resolvem uma expressão sobre um período de tempo

Os próximos posts sobre DAX serão sobre cada um destes 3 grupos!

Este artigo é parte de uma série de artigos sobre PowerPivot e DAX. Confira os outros artigos sobre PowerPivot no link: http://zavaschi.com/index.php/tag/powerpivot/

Abraços,
Thiago Zavaschi

É possível sim, claro que a configuração do permissionamento pode ser adaptado para cada caso. No exemplo aqui vou concentrar nesse caso perguntado.

Vamos criar um login e um user na database “demo”.

USE [master]
GO
CREATE LOGIN [usuario] WITH PASSWORD=N'123', DEFAULT_DATABASE=[demo], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
USE [demo]
GO
CREATE USER [usuario] FOR LOGIN [usuario]
GO

Vamos usar a mesma tabela de empregados que usamos no artigo anterior.

O usuário “usuario” tem permissão de select na tabela. O que podemos fazer é simplesmente:

1) Remover a permissão de select no objeto.

2) GRANT na permissão de VIEW DEFINITION:

DENY SELECT ON [dbo].[Empregado] TO [usuario]

GRANT VIEW DEFINITION ON [dbo].[Empregado] TO [usuario]

E teremos ao executar o select:

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object 'Empregado', database 'demo', schema 'dbo'.

Mas ao tentar ver a estrutura:

Espero que te ajude Carlos!

Grande abraço,
Thiago Zavaschi

No último artigo vimos o que, na minha opinião, é o carro chefe do SQL Server 2008 (“new” feature), o Resource Governor. Mas não é só isso!

Hoje vamos ver sobre auditoria! :)

Há diferentes formas de se fazer auditoria no SQL Server: triggers, CDC, Audit, entre outras.

O que veremos hoje é o audit e serve (não só) para responder dúvidas como:

“Tenho uma aplicação de recursos humanos e que possui uma tabela com o salário dos funcionários, tem como eu saber os usuários que executaram um comando de select sobre essa tabela?” (sim é possível, além de ser menos custoso do que rodar um profiler contra a base e ainda filtrando sobre a tabela desejada (parse de texto)).

Para efeito de simplicidade imagine que o seu cenário tenha a seguinte tabela:

O script para criação da tabela:

CREATE TABLE Empregado
( idEmpregado INT IDENTITY PRIMARY KEY,
nome VARCHAR(100) NOT NULL,
valor MONEY NOT NULL)
GO

O log de auditoria pode ir para três destinos distintos: arquivo, security log e application log (do servidor onde o SQL Server roda).

O primeiro passo é criar um Audit:

Pelo Management Studio: (Security > Audits > New Audit)

Ou através de scripts.

Para cada destino escolhido há configurações específicas. Segue o script para criar o Audit para arquivo:

USE [master]
GO
CREATE SERVER AUDIT [AuditoriaSalario]
TO FILE
(    FILEPATH = N'C:\Temp'
    ,MAXSIZE = 0 MB
    ,MAX_ROLLOVER_FILES = 2147483647
    ,RESERVE_DISK_SPACE = OFF
)
WITH
(    QUEUE_DELAY = 1000
    ,ON_FAILURE = CONTINUE
)

Após isso você precisa criar uma especificação da auditoria (Audit Specification) que pode ser Server Audit Specification (Security > Server Audit Specifications > New Server Audit Specification…) ou Database Audit Specification (DatabaseName > Security > Database Audit Specification), que mapeiam efetivamente os objetos (ou servidores) sendo monitorados e conecta a um Audit (que nada mais é que a configuração do local aonde estarão os dados da auditoria).

Existem MUITOS tipos de ações de auditoria (Audit Action Type). No nosso exemplo (para responder ao questionamento inicial) vamos utilizar Database Audit Specification (pois o objeto a ser monitorado é uma tabela de uma base de dados específica).

O comando abaixo cria a especificação (public que é o role sendo monitorado):

CREATE DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification-Salario]
FOR SERVER AUDIT [AuditoriaSalario]
ADD (SELECT ON OBJECT::[dbo].[Empregado] BY [public])

Depois disso temos que ativar a auditoria:

USE [master]
GO

ALTER SERVER AUDIT AuditoriaSalario
WITH (STATE = ON);
GO

USE [demo]
GO

ALTER DATABASE AUDIT SPECIFICATION [DatabaseAuditSpecification-Salario]
WITH (STATE = ON)
GO

Beleza.. Auditoria “de pé”! Vamos inserir alguns dados na tabela de Empregado (sintaxe SQL2008+):

INSERT INTO [demo].[dbo].[Empregado]
           ([nome],[valor])
     VALUES
           ('Thiago', 15000),
           ('Joao', 1000),
           ('Pedro', 7500)
GO

E na sequência vamos fazer um select para descobrir o meu salário:

SELECT 'Valor do Salário: ' + CONVERT(VARCHAR,valor) FROM Empregado WHERE nome = 'Thiago'

Se tudo foi configurado corretamente, devemos ter no arquivo essa informação logada.

O arquivo não é plain text, para ler basta executar o seguinte comando:

SELECT * FROM sys.fn_get_audit_file (N'C:\Temp\*',default,default);

E lá estão os selects que executei. Para facilitar, uma visão resumida:

SELECT
event_time 'horario',
database_name + '.' + schema_name + '.' + object_name 'objeto',
statement,
server_principal_name 'login',
session_server_principal_name 'user'
FROM sys.fn_get_audit_file (N'C:\Temp\*',default,default)
WHERE action_id = 'SL';

Que retorna (no meu caso):

Horario: 2011-01-19 20:04:37.0349242   
Objeto: demo.dbo.Empregado   
Statement: SELECT 'Valor do Salário: ' + CONVERT(VARCHAR,valor) FROM Empregado WHERE nome = 'Thiago'      
Login: SOUTHAMERICA\v-thzava   
User: SOUTHAMERICA\v-thzava

E relembrando que isso pode ser enviado ao security log ou app log (onde até mesmo um sysadmin do banco pode não ter acesso ).

É isso pessoal, espero que tenham gostado!

Em caso de dúvidas entrem em contato!

Abraços,
Thiago Zavaschi