quarta-feira, 25 de agosto de 2010

Dica: Criptografando os comandos de Stored Procedures e Views

Ao compilar uma aplicação construída em uma linguagem de programação usual, obtém-se um ou mais arquivos binários executáveis. Nesses arquivos, o código-fonte não é acessível, o que aumenta a proteção da lógica utilizada para escrever o programa.

O SQL Server permite fazer algo semelhante com as stored procedures e views armazenadas em seus bancos de dados. Em termos práticos, é possível criptografar os comandos SQL contidos em uma procedure ou view de forma que o comando sp_helptext não seja capaz de exibir o script do objeto em questão.

O uso da cláusula WITH ENCRYPTION permite que esta tarefa seja realizada.

Para exemplificar, utilizaremos a tabela Vendas.Clientes, definida abaixo:

CREATE TABLE Vendas.Clientes
(
  id                     INTEGER INDENTITY(1,1) PRIMARY KEY,
  nome               VARCHAR(50),
  email               VARCHAR(50),
  rendaMensal   MONEY
)

Criptografando uma Stored Procedure
Para criptografar uma Stored Procedure, deve-se incluir a opção WITH ENCRYPTION, ao criá-la , conforme o exemplo abaixo:

CREATE PROCEDURE Vendas.proc_rendaCliente
    @id int
WITH ENCRYPTION
AS
   SELECT nome, rendaMensal FROM Vendas.Cliente
   WHERE id = @id
GO

Ao executar a procedure do sistema sp_helptext passando como parâmetro o nome da procedure criada, o SQL Server mostra uma mensagem informando que a procedure não pode ser exibida porque foi criptografada. Veja o resultado abaixo:


Criptografando uma Stored Procedure
A criptografia dos comandos de uma View é muito semelhante à de uma Stored Procedure. Para criptografar uma View, deve-se incluir a opção WITH ENCRYPTION, ao criá-la , conforme o exemplo abaixo:

CREATE VIEW Vendas.vw_rendaClientes
WITH ENCRYPTION
AS
    SELECT nome, rendaMensal FROM Vendas.Cliente
GO

Ao executar a procedure do sistema sp_helptext passando como parâmetro o nome da view criada, o SQL Server mostra uma mensagem informando que o código da view não pode ser exibido porque  ela foi criptografada. Veja o resultado abaixo:

Conclusão
Criptografar os comandos de Stored Procedures e Views pode ser uma alternativa para aumentar a segurança de uma banco de dados, ocultando a lógica de processos implementados no banco e ocultando regras de negócio de uma solução.

Uma vez criptografado, não é possível recuperar o código que gerou o objeto. Portanto, é muito importante ter uma cópia do código-fonte em algum lugar seguro para fins de backup e manutenções futuras.

Referência
CREATE PROCEDURE (Transact-SQL) (MSDN)

sábado, 21 de agosto de 2010

Identificando página de dados danificadas no SQL Server

Por mais garantidos que sejam o hardware e software de armazenamento de dados.Não há como garantir a ausência de falhas.

O SQL Server fornece uma ferramenta importante para indentificar pequenos erros, que afetam páginas isoladas da base de dados.

O próprio SQL Server analisa as páginas de dados, avaliando sua integridade. A tabela suspect_pages contém as páginas que apresentaram algum tipo de defeito durante a verificação.

Assim, uma maneira simples de identificar as páginas danificadas em um servidor SQL Server é utilizar o seguinte comando:
use msdb
go
select * from suspect_pages

quinta-feira, 19 de agosto de 2010

Desabilitando restrições ao inserir muitos registros

O uso de restrições (CONSTRAINTS) nas tabelas de um banco de dados é extremamente recomendável para garantir a integridade dos dados armazenados.

Entretanto, quando os registros são inseridos ou alterados em tabelas que possuam contraints, o SQL Server precisará validar todas as constraints para cada cada alteração realizada, o que diminui a performance destas operações.

Em situações comuns de uso do banco de dados, esse impacto não é percebido, principalmente se o banco de dados foi implementado seguindo as boas práticas. Por outro lado, em uma carga de dados, ou em qualquer situação onde seja necessário realizar muitas inserções ou alterações de registros, essa verificação adicional pode impactar severamente na perfomance destas operações.

Para contornar esta situação, é possível desabilitar a verificação de constraints, desde que se tenha a garantia de que os dados a serem inseridos/atualizados estão em conformidade com as restrições do banco.

A cláusula NOCHECK do comando ALTER TABLE desabilita estas verificações.

Sintaxe
ALTER TABLE NomeDaTabela
       NOCHECK CONSTRAINT NomeDaConstraint
Exemplo
ALTER TABLE Cliente
       NOCHECK CONSTRAINT fk_cliente_x_empresa
Referência
ALTER TABLE (Transact-SQL)

sexta-feira, 13 de agosto de 2010

Tech-Ed 2010 - 13 a 15 de Setembro




As inscrições para o Tech-Ed 2010 já começaram!

O Tech-Ed é o maior evento técnico brasileiro voltado para profissionais de TI e desenvolvedores que utilizam a tecnologia Microsoft.

Acesse o site http://www.teched.com.br para maiores informações.

As palestras estão disponíveis através do endereço http://www.teched.com.br/2010/Palestras.aspx. Veja as palestras da trilha "Plataforma de Banco de Dados" filtrando pelo código DBP.

quinta-feira, 12 de agosto de 2010

Dica: Executando várias vezes um mesmo batch

Em certas ocasiões, é necessário executar várias vezes uma mesma sequência de comandos no SQL Server (batch). Essa tarefa pode ser muito trabalhosa quando o número de repetições atinge grandes valores.

Se os comandos forem sempre os mesmos e não houver mudança de parâmetros, pode-se utilizar o comando GO seguido pelo número de vezes que o comando será executado, respeitando a sintaxe abaixo:

GO <número_de_execuções>

O comando GO não é um comando do SQL Server, mas sim uma instrução interpretada pelas interfaces de gerenciamento do SQL Server (SQL Server Management Studio, sqlcmd e osql).

Esse comando pode ser especialmente útil para popular bases de teste.

Exemplo
No exemplo abaixo, criamos uma tabela com um campo inteiro e inserimos 15 registros com valores aleatórios:

CREATE TABLE #tblExemplo (number DECIMAL)
GO

INSERT INTO #tblExemplo VALUES(RAND() * 100)
GO 15

SELECT * FROM #tblExemplo

DROP TABLE #tblExemplo

GO

Pode-se observar o resultado do script na imagem abaixo:



Referências
GO (Transact-SQL)

terça-feira, 10 de agosto de 2010

Trabalhando com Database Snapshots

O que é um Database Snapshot?
Snapshot é uma "fotografia" da base de dados em um estado consistente em um determinado momento.
Este recurso, disponível nas versões do SQL Server 2005 e 2008, permite a criação rápida de um ambiente somente-leitura para relatórios, testes, proteção contra erros de usuário, etc.

Como funciona?
Ao criar um snapshot, cria-se um novo banco vazio (Snapshot DB) que será preenchido com os dados originais conforme estes são alterados após a criação do Snapshot.

Quando um Snapshot é configurado para uma base de dados (base de dados fonte), o SQL Server executa um processo chamado copy-on-write. Neste processo, ao alterar uma página de dados na base de dados fonte, uma cópia da página original é armazenada na base de dados Snapshot. Essa operação é válida somente para a primeira alteração na página de dados, mantendo, assim, a cópia original na base Snapshot.

Ao ler os dados da base Snapshot, o SQL Sever retorna os dados da base de dados fonte, porém as páginas alteradas são substituídas pelas páginas armazenadas no banco de dados Snapshot, resultando em uma "visão" do momento em que o Snapshot foi criado.

Criando um Snapshot
Para criar um Snapshot, utiliza-se o comando CREATE TABLE com algumas modificações:

CREATE DATABASE SnapshotDatabaseName
ON
(name = sourcefilename1 , FILENAME =  snapshotfilepath1),
(name = sourcefilename2 , FILENAME =  snapshotfilepath2)
AS
SNAPSHOT OF SourceDatabaseName

Restaurando um Snapshot
Pode-se também restaurar uma base de dados, para o estado em que o Snapshot foi criado. Para isso, utiliza-se o comando:

RESTORE DATABASE databaseName FROM
DATABASE_SNAPSHOT = SnapshotDatabaseName

Considerações
Este não pode ser utilizado como backup, uma vez que a base Snapshot só armazena as página de dados alteradas na base original desde a criação do Snapshot.

Referências
How Database Snapshots Work (MSDN)

segunda-feira, 9 de agosto de 2010

Conflitos de COLLATION em operações de comparação

Em bancos de dados SQL Server, as Collations são utilizadas para definir a maneira como os dados do tipo string (nchar, nvarchar, e ntext) são armazenados.
Em resumo, uma collation define:
  • A codificação (Character Set) utilizada para armazenar os caracteres não-Unicode.
  • O algoritmo de ordenação utilizado para ordenar o retorno das consultas
O SQL Server permite que seja configurada uma collation default para o servidor,atribuindo-a a todos os campos cuja collation não é explicitamente definida durante a criação.

Além disso, as collations podem ser definidas em diferentes granularidades. É possível definir collations para bancos de dados, tabelas, campos de tabelas e variáveis do SQL Server.

Entretanto, o uso de diversas collations em uma mesma base de dados pode causar problemas ao desenvolvedor, pois algumas collations não são compatíveis entre si. Um problema comum ao escrever consultas envolvendo comparação de campos de texto com collations diferentes é o confilto nessa operação de igualdade.

"Cannot resolve collation conflict for equal to operation"

Uma solução para este problema é indicar ao processador de consultas qual collation deverá ser utilizada para realizar a comparação entre os dois valores. Para isso, deve-se utilizar o comando COLLATE. Além disso, pode-se passar como argumento a palavra-chave DATABASE_DEFAULT, que retorna a collation definida para o banco de dados em uso. Veja o exemplo abaixo:


SELECT userName FROM Usuarios
INNER JOIN Clientes ON
Clientes.userName COLLATE DATABASE_DEFAULT
= Usuarios.userName  COLLATE DATABASE_DEFAULT

No exemplo, foi feita a junção entre as tabelas "Usuarios" e "Clientes", utilizando-se o campo userName, presente em ambas as tabelas. Supõe-se que este campo possua collations diferentes e conflitantes nestas tabelas. O comando COLLATE resolve o conflito na operação de igualdade do JOIN, utilizando a collation padrão do banco.

Referências:
Comando COLLATE (MSDN)