Melhores práticas – Compressão de Dados
Olá pessoal,
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!
Como saber quem está conectado no meu servidor do Analysis Services?
Olá pessoal!
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!
SQL Server e SQL Azure – Licenciamento + Billing
Então pessoal, como estão?
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.
-
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
Permissão para ver a estrutura, mas sem os dados!
Recentemente o Carlos Barini (http://twitter.com/cabarini) me perguntou se era possível liberar para um user ver a estrutura de uma tabela, mas não ter a permissão de leitura na tabela.
É 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
Auditoria no SQL Server – SQL Audit
Olá a todos!
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
SQL Server Resource Governor WhitePaper
E ae galera!
Então.. para complementar o assunto sobre Resource Governor segue o link para um whitepaper MUITO bom da Microsoft sobre o assunto:
http://msdn.microsoft.com/en-us/library/ee151608%28SQL.100%29.aspx
Recomendo a leitura!
Abraços,
Thiago Zavaschi
SQL Server Resource Governor
Oi pessoal!
Há algum tempo atrás eu havia iniciado um artigo para a SQL Magazine, mas devido a alguns compromissos não pude finalizar/enviar para a revista.
O artigo está praticamente finalizado e é sobre Resource Governor. Segue o artigo:
Introdução
O Resource Governor é um mecanismo da plataforma SQL Server, tendo seu aparecimento na versão 2008, para controlar o acesso a recursos de memória e processamento. Boa gerência dos recursos disponíveis para o SQL Server pode significar o sucesso ou o fracasso da sua solução de negócio baseada neste sistema gerenciador de bancos de dados (SGBD).
A ideia deste artigo é demonstrar o recurso, onde e como se aplica, e sensibilizar o leitor no que tange a considerações relacionadas à concorrência que ocorre sobre os recursos do(s) servidor(es).
Já viu este cenário?
A aplicação tem seu desenvolvimento concluído (ou é gerado um release ao final de um ciclo), é colocada em um ambiente de validação/homologação e nesta etapa são feitos os testes para verificar a regra de negócio. Colocando os méritos das técnicas de validação um pouco de lado e assumindo que está tudo de acordo, a aplicação é, por fim, posta em produção. E é aí que os problemas mais graves começam...
Algumas semanas depois da aplicação estar em produção, os usuários começam a relatar problemas como a lentidão no sistema, timeouts (especialmente se for uma aplicação web), e etc. Esses problemas são relatados ao mesmo tempo em que as verificações feitas no banco de dados indicam que o consumo de memória e CPU estão próximos ao limite.
Uma análise mais detalhada mostra que a causa da lentidão é causada pela geração dos relatórios, pois os mesmo são extraídos a partir da base de dados de produção. Existem diversas estratégias que podem ser utilizadas para contornar o problema: replicação, espelhamento (mirroring), solução utilizando BI e bases OLAP, etc, etc, etc. Mesmo com a adoção de uma destas estratégias o uso do resource governor é interessante conforme veremos na sequência.
Em um cenário em que a compra de um novo servidor ou a utilização de uma solução de BI não é factível o resource governor pode dar um grande auxílio!
Mas o que é o resource governor?
O resource governor é “simplesmente” um mecanismo para a gerência dos recursos de memória e processador utilizados pelo SQL Server. Com o resource governor é possível classificar as queries disparadas contra a base de dados em workload groups pré-definidos, e estes, por sua vez, são mapeados em resource pools que efetivamente definem as limitações de memória e processamento.
As queries precisam ser classificadas em um dos workload groups criados, tal tarefa é executada por uma função de classificação (classifier function). O código desta função deve ser muito escrito, para garantir o tratamento adequado das queries, que podem ter características de mais de um workload group. A figura 1 contempla um esquema deste mecanismo.
Mas em quais cenários o Resource Governor é interessante ser aplicado? Principalmente para três cenários: Controle de queries “soltas” executadas no banco; controle da concorrência previsível de workloads (base de produção x relatórios, por exemplo); e a priorização dos workloads.
Figura 1. Arquitetura macro do mecanismo de Resouce Governor
Criando Resource Pools
Os resource pools representam os recursos físicos do servidor (memória e CPU). No SQL Server 2008 estes pools definem as quantidades máxima e mínima da utilização dos recursos. Existem livros que tratam resource pools como sendo instâncias virtuais do SQL Server, eu penso que é quase isso, visto que poderíamos ter uma separação mais consistente (além de memória e CPU). No SQL Server 2008 existem dois resource pools pré-definidos: Internal e o Default.
O pool internal é usado somente pela engine do SQL Server, não é possível apagá-lo ou fazer quaisquer alterações sobre as suas capacidades mínimas e máximas sobre os recursos.
O pool default será usado pelos workloads que não estão associados a nenhum resource pool. Caso o resource governor não esteja configurado na sua instância do SQL Server, todas as suas queries executarão neste pool. Não é possível apagá-lo ou alterá-lo, com exceção aos seus valores máximos e mínimos associados aos recursos que podem ser configurados.
Os administradores de bancos de dados podem criar novos resource pools. Seguindo o raciocínio do cenário anterior, vamos criar dois pools: um para as queries “normais” e outro para as queries executadas para extrair dados para os relatórios. A listagem 1 mostra o comando Transact-SQL para a criação do Resource Pool. Um detalhe importante é que a soma dos valores mínimos dos pools não pode ser maior que 100 %. O valor máximo individual de cada pool é de até 100 %, mas devemos lembrar de que este valor não será o real caso haja mais de um pool com este valor máximo. O cálculo do valor máximo efetivo deve ser feito subtraindo a soma dos demais mínimos, e este sim será o valor mais elevado atingido pelo SQL Server. Para nossos exemplos, inicialmente colocaremos ambos os pools com percentual máximo de 100 % de CPU.
Listagem 1. Criação dos Resource Pools
CREATE RESOURCE POOL NormalQueries
WITH (MAX_CPU_PERCENT = 100)
CREATE RESOURCE POOL RelatorioQueries
WITH (MAX_CPU_PERCENT = 100)
A sintaxe associada aos Resource Pools e os parâmetros passíveis de configuração, podem ser vistos na listagem 2 (o “valor” é um número correspondido de 1 a 100, para os valores máximos, e de 0 a 100 para os valores mínimos). Acredito que o nome dos parâmetros e a sintaxe são auto explicativos e por isso não entrarei em maiores detalhes, para mais informações consultar o Books Online do SQL Server 2008). Um detalhe importante é a utilização de aspas (“, ”) ou de colchetes ([, ]) na palavra default para evitar conflitos com a palavra reservada DEFAULT, isto vale para as sintaxes subseqüentes também).
Listagem 2. Sintaxe e Parâmetros Configuráveis - Resource Pool
CREATE|ALTER|DROP RESOURCE POOL { pool_name | "default" }
[WITH
( [ MIN_CPU_PERCENT = valor ]
[ [ , ] MAX_CPU_PERCENT = valor ]
[ [ , ] MIN_MEMORY_PERCENT = valor ]
[ [ , ] MAX_MEMORY_PERCENT = valor ] )
]
[;]
Se não forem criados Resource Pools próprios, isto é, sempre utilizar o pool padrão, podemos dizer que é um comportamento similar ao encontrado no SQL Server 2005. Devemos também nos atentar para a limitação do número de pools que é de 20 (incluindo os dois pré-definidos).
Criando Workload Groups
Já vimos como fazer a criação dos resource pools, mas também foi visto que necessitamos de workload groups mapeados nestes pools para configurar o resource governor, pois se associarmos usuários diretamente aos pools poderia ser extremamente custoso qualquer gerência, para não dizer quase impossível. Acredito que um dos elementos mais interessantes dos workload groups é a capacidade de definir prioridade (baixa, média, alta) aos mesmos, o que aumenta ainda mais a granularidade da configuração possível. Por padrão a prioridade é a média (MEDIUM).
Um pool pode mapear zero ou mais workloads, por sua vez, mapeados com as queries dos usuários, mas um workload group só pode estar em um único pool (e sempre estará em um).
Vamos criar três workload groups (para exemplificar múltiplos workloads por pool): AdhocAdm, UsuariosNormais, Relatorios. Os comandos Transact-SQL para a criação dos workloads, para o nosso exemplo, podem ser vistos na listagem 3. A cláusula USING serve para mapear o workload sendo criado a um pool existente. Como já mencionado, as queries que se encaixarem nos workload groups não associados a um resource pool, utilizarão o resource pool default (sempre existente).
Listagem 3. Criação dos Workload Groups
CREATE WORKLOAD GROUP AdhocAdm
USING NormalQueries
CREATE WORKLOAD GROUP UsuariosNormais
USING NormalQueries
CREATE WORKLOAD GROUP Relatorios
USING RelatorioQueries
A listagem 4 mostra a sintaxe completa associada à manipulação de workload groups e também os parâmetros configuráveis.
Listagem 4. Sintaxe do Workload Group e seus Parâmetros Configuráveis
CREATE|ALTER|DROP WORKLOAD GROUP { group_name | "default" }
[WITH
([IMPORTANCE = { LOW | MEDIUM | HIGH }]
[[,] REQUEST_MAX_MEMORY_GRANT_PERCENT = valor ]
[[,] REQUEST_MAX_CPU_TIME_SEC = valor ]
[[,] REQUEST_MEMORY_GRANT_TIMEOUT_SEC = valor ]
[[,] MAX_DOP = valor ]
[[,] GROUP_MAX_REQUESTS = valor ] )
]
[USING { pool_name | "default" }]
[;]
A sintaxe associada é um pouco mais complexa que a dos resource pools e por isso entrarei nos méritos de cada parâmetro.
IMPORTANCE: Define a prioridade do workload group, por padrão (se não especificada) é a média. Este grau de prioridade é usado para cálculos entre workgroups dentro do mesmo resource pool e não afeta os outros workload groups associados a outros resource pools.
REQUEST_MAX_MEMORY_GRANT_PERCENT: Especifica a quantidade máxima de memória que uma requisição única consegue utilizar do pool. Esta porcentagem é relativa ao tamanho da memória disponível ao pool (MAX_MEMORY_PERCENT). O parâmetro valor precisa ser zero ou um inteiro positivo até 100. O valor padrão (se não especificado) é 25.
REQUEST_MAX_CPU_TIME_SEC: Especifica o máximo de tempo (segundos) que uma query pode esperar por um recurso até ficar disponível antes da query falhar. O valor precisa ser 0 ou um inteiro positivo. Por padrão este valor é zero. O Resource Governor não impede a query de executar caso o tempo limite seja atingido, mas um evento é gerado (mais informações no Books Online do SQL Server 2008, ver sobre “CPU Threshold Exceeded Event Class”).
REQUEST_MEMORY_GRANT_TIMEOUT_SEC: Especifica o tempo máximo (segundos) que uma query pode esperar por memória (work buffer memory) até ficar disponível. O valor necessita ser um valor maior ou igua a 0 (padrão). Atingir o tempo limite não significa necessariamente que a execução da query irá falhar, isto só ocorrerá se existirem muitas solicitações concorrentes, a query executará na verdade com uma quantidade menor de memória disponível (o que pode afetar o desempenho da mesma).
MAX_DOP: Especifica o grau máximo de paralelismo (DOP: degree of parallelism) para requisições paralelas. O valor precisa ser 0 ou um número inteiro positivo, onde o valor máximo é de 64. O valor padrão é 0, e significa que útilizará o valor global configurado.
GROUP_MAX_REQUESTS: Especifica o número máximo de requisições simultâneas que são permitidas executar em um mesmo workload group. O valor precisa ser 0 ou um inteiro positivo. O valor padrão é 0 (requisições ilimitadas, teoricamente).
Por fim, a cláusula USING indica qual resource pool será utilizado, por padrão será o pool default.
Com o mapeamento resource pool ó workload group feito, devemos configurar a Classifier Function (função de classificação) que definirá qual o workload associado à chamada sendo feita.
Função de Classificação (Classifier Function)
Seguindo o raciocínio com base na figura 1, vemos que para efetuar o direcionamento das queries que chegam ao servidor SQL Server (idealmente colocado em um servidor físico diferente do servidor de aplicação) é necessária uma função de classificação. Para a construção do algoritmo de classificação é possível utilizar os parâmetros presentes na string de conexão, tais como: endereço IP; nome da aplicação; nome do usuário; entre outros. Sabendo o que é possível utilizar, é necessário definir as políticas que estarão presentes na função. Entre as funções auxiliares disponíveis podemos citar: SUSER_NAME(), HOST_NAME(), SUSER_SNAME(), etc. Temos também as novas funções: CONNECTIONPROPERTY(), ORIGINAL_DB_NAME() e também as novas opções para LOGINPROPERTY(). Para maior detalhamento do comportamento destas funções, favor olhar o Books Online do SQL Server 2008.
Para efeito de exemplificação utilizaremos os seguintes critérios:
Caso o usuário tenha aberto uma sessão através do SQL Server Management Studio (nome da aplicação) então deverá ser classificado no workload AdhocAdm.
Caso seja o usuário ‘Relatorio’, então será classificado para o workload de Relatorios.
Todos os demais que não se enquadrarem em nenhuma das regras anteriores serão classificados para o workload de UsuariosNormais.
Acompanhe o script de criação destas regras na listagem 5.
Listagem 5. Criação da Classifier Function
USE MASTER
GO
CREATE FUNCTION fnClassificadora()
RETURNS SYSNAME WITH SCHEMABINDING
BEGIN
DECLARE @x SYSNAME
IF APP_NAME() LIKE 'Microsoft SQL Server Management Studio%'
BEGIN
SET @x = 'AdhocAdm';
RETURN @x;
END
DECLARE @user VARCHAR(50) = SUSER_SNAME();
IF @user = 'Relatorio'
BEGIN
SET @x = 'Relatorios';
RETURN @x;
END
SET @x = 'UsuariosNormais';
RETURN @x;
END
A função de classificação demonstrada é bastante simples, mas contempla todas as definições que mencionei anteriormente. Fique atento, uma mesma sessão pode se encaixar em mais de um workload group, imagine (segundo nosso exemplo) se o usuário fosse “Relatorio”, mas utilizando o SQL Server Management Studio, logo caracterizando a presença em dois grupos distintos. Uma função de classificação bem programada também é peça fundamental de uma configuração bem sucedida do resource governor, com isso poderíamos ter uma função relativamente grande e complexa (dependendo do caso).
A função de classificação está criada, agora falta associá-la ao resource governor. A listagem 6 demonstra o comando Transact-SQL para realizar a associação.
Listagem 6. Associação da Classifier Function com o Resource Governor
ALTER RESOURCE GOVERNOR
WITH (CLASSIFIER_FUNCTION = dbo.fnClassificadora)
Todas as configurações não terão efeito até que o RECONFIGURE seja executado. O script para o RECONFIGURE pode ser observado na listagem 7.
Listagem 7. Execução do RECONFIGURE
ALTER RESOURCE GOVERNOR
RECONFIGURE
Este foi o último ponto de configuração do resource governor, isto significa que a partir desse momento as queries serão executadas segundo os critérios configurados.
---
É isso pessoal, espero que ajude vocês nos seus estudos!
Grande abraço,
Thiago Zavaschi
SQL Server Analysis Services sobre HTTP/HTTPs
Olá pessoal,
Quando pensamos no SSAS, lembramos que o único modo de autenticação que temos é através de Windows Authentication. Não há algo como o Mixed mode do SQL Server.
Mas os clientes que vão consumir os dados do nosso servidor de análise nem sempre está no mesmo domínio que nós. Então como proceder?
É possível sim (SSAS enterprise only) fazer essa conexão externa através de um pump. Ou seja, você cria uma passagem no seu IIS para o seu servidor de análise.
Primeiramente ative seu IIS no seu servidor. (Aqui estou utilizando o IIS7, os passos para o IIS 6 podem ser observados de uma maneira geral neste post, em inglês: Configuring SSAS over HTTP, apesar de falar do SQL Server 2000, os passos são parecidos).
Crie um site no IIS. Dentro deste site crie um diretório virtual e mapeie para um diretório físico. No meu caso nomeei o diretório como “olap” e mapeei para “C:\inetpub\wwwroot\olap”.
Mesmo que seja usado HTTP (sem SSL) na porta 80, libere no firewall a porta 80 e a porta 2725, para que o Office consiga fazer o acesso ao servidor de análise.
Copie para a pasta mapeada (C:\inetpub\wwwroot\olap) todos os arquivos do diretório: C:\<local da instalacao do SQL Server>\MSAS10_50.<instancia>\OLAP\bin\isapi.
No meu caso o diretório é:
C:\Program Files\Microsoft SQL Server\MSAS10_50.MSSQLSERVER\OLAP\bin\isapi.
O diretório mapeado fica semelhante ao mostrado abaixo:
Após isso vá no gerenciador do IIS, clique no diretório virtual que você criou e depois clique em Mapeamentos de Manipulador (Handler Mapping) e depois clique em “Adicionar Mapeamento de Script” (Add Map Script).
Dê um nome para o mapeamento (no meu caso usei olap mesmo) e mapeie para a dll chamada msmdpump.dll que você copiou do diretório do SQL Server.
O último detalhe agora é se o ISS não estiver no mesmo servidor do SSAS. Se este for o cenário você deve acertar o arquivo (com o notepad mesmo) msmdpump.ini que está no diretório mapeado para o diretório virtual. O pedaço que você deve ajustar é o <ServerName>. Se for no mesmo servidor, deixe localhost.
<ConfigurationSettings>
<ServerName>localhost</ServerName>
<SessionTimeout>3600</SessionTimeout>
<ConnectionPoolSize>100</ConnectionPoolSize>
</ConfigurationSettings>
Pronto!
Agora você pode usar como servidor para a conexão o seguinte endereço:
http://<servername/ip>/olap/msmdpump.dll.
Lembrando que você deve passar as credenciais, e estas devem estar no domínio do SSAS. O usuário e senha ficaria algo como:
<domínio>\usuario (com a barra mesmo), e a senha normal do usuário.
Este usuário vai ter as permissões normais definidas nas roles da base do SSAS que você estará fazendo o acesso.
É isso, espero que tenham gostado. :-)
Abraços,
Thiago Zavaschi
Faça um DBA feliz! #1
Olá pessoal!
Você como desenvolvedor deve pensar que agradar àquele cara que fica sentado junto ao pessoal de infra é difícil, mas não é não!
Essa série irei passar pequenas dicas que podem facilitar (e muito) a vida do DBA. No final das contas ele pode até te pagar uma cerveja por isso :).
É muito comum encontrar cenários de bases de dados SQL Server unificadas, e diversos (eu falei, diversooos!) sistemas que a utilizam.
É muito comum também existirem certas queries que não estão, digamos, muito otimizadas e que forçam muito o servidor. É papel do DBA identificar, tentar corrigir se possível e avisar aos responsáveis.
O problema é justamente saber a quem avisar… Existe uma solução muito simples pra isso.
Quando o DBA está visualizando o que está acontecendo no banco, se a aplicação informar, aparece o nome da aplicação, caso contrário aparece: .NET sqlClient Data Provider (nome genérico e sem significado de negócio direto).
É possível especificar um parâmetro opcional na connection string chamado Application Name e resolver isso:
Data Source=SERVIDOR;Initial Catalog=BASEDEDADOS;User Id=USER;Password=PASS;Application Name=NomeAplicacao;
Isso resulta numa bela visão para facilidar o tracking do DBA!
Comando executado:
select spid, program_name, * from sys.sysprocesses
where program_name <> ''
É isso pessoal. A ideia desta série é ter posts curtos e diretos! O próximo deve ser relacionado ao SQL dinâmico, não percam!
Abraços e excelente fim de noite!
Verificando espaço em disco e o espaço ocupado por tabelas!
Olá pessoal!
Inspirado no post do Diego Nogare, o qual comentei (com os scripts deste post), resolvi postar aqui também os scripts sobre verificação de espaço usado em disco e por tabelas!
Verificar o tamanho ocupado por tabelas no banco (a.k.a achar maiores tabelas):
Ordenado por quantidade de linhas:
SELECT object_name(id), rowcnt, dpages * 8 AS [tamanho KB] FROM sysindexes
WHERE indid IN (1,0) AND objectproperty(id,'isusertable') = 1
ORDER BY rowcnt DESC
Ordenado por tamanho físico:
SELECT object_name(id), rowcnt, dpages * 8 AS [tamanho KB] FROM sysindexes
WHERE indid IN (1,0) AND objectproperty(id,'isusertable') = 1
ORDER BY [tamanho KB] DESC
E para mostrar o espaço em disco disponível (valor absoluto e percentual) e o espaço total dos discos, é possível utilizar (a fonte deste script é o SQLDBATips):
DECLARE @hr int
DECLARE @fso int
DECLARE @drive char(1)
DECLARE @odrive int
DECLARE @TotalSize varchar(20)
DECLARE @MB bigint ; SET @MB = 1048576
CREATE TABLE #drives (drive char(1) PRIMARY KEY,
FreeSpace int NULL,
TotalSize int NULL)
INSERT #drives(drive,FreeSpace)
EXEC master.dbo.xp_fixeddrives
EXEC @hr=sp_OACreate 'Scripting.FileSystemObject',@fso OUT
IF @hr <> 0 EXEC sp_OAGetErrorInfo @fso
DECLARE dcur CURSOR LOCAL FAST_FORWARD
FOR SELECT drive from #drives
ORDER by drive
OPEN dcur
FETCH NEXT FROM dcur INTO @drive
WHILE @@FETCH_STATUS=0
BEGIN
EXEC @hr = sp_OAMethod @fso,'GetDrive', @odrive OUT, @drive
IF @hr <> 0 EXEC sp_OAGetErrorInfo @fso
EXEC @hr = sp_OAGetProperty @odrive,'TotalSize', @TotalSize OUT
IF @hr <> 0 EXEC sp_OAGetErrorInfo @odrive
UPDATE #drives
SET TotalSize=@TotalSize/@MB
WHERE drive=@drive
FETCH NEXT FROM dcur INTO @drive
END
CLOSE dcur
DEALLOCATE dcur
EXEC @hr=sp_OADestroy @fso
IF @hr <> 0 EXEC sp_OAGetErrorInfo @fso
SELECT drive,
FreeSpace as 'Livre(MB)',
TotalSize as 'Total(MB)',
CAST((FreeSpace/(TotalSize*1.0))*100.0 as int) as 'Livre(%)'
FROM #drives
ORDER BY drive
DROP TABLE #drives
RETURN
GO
A saída do script deverá ser semelhante a:
drive Livre(MB) Total(MB) Livre(%)
----- ----------- ----------- -----------
C 9541 49999 19
D 46002 317966 14
F 37549 99998 37
K 68581 476269 14
É isso pessoal, fazia tempo que não postava algo masi focado a área de DBA (a qual gosto muito também), espero que seja útil!
Abraços,
Thiago Zavaschi