Introdução às Stored Procedure com SQL

Server 2000/2005
Por WAGNER BIANCHI - http://www.devmedia.com.br/space.asp?id=154500

Olá pessoal,

Mais uma vez, vamos abordar um assunto interessante, para o qual, recebi muitos
e-mails quando abordei que falaria sobre neste artigo. Agradeço as pessoas da
faculdade Federal Fluminense e da Federal do Paraná que escreveram pedindo uma
enfática no assunto que irei abordar.

Todos, desenvolvedores, analistas e DBA’s já estão bem cientes que os bancos de

dados relacionais de nosso tempo e desde algum tempo atrás, já contemplam
procedimentos armazenados e estes são realmente de muito proveito em várias
situações do desenvolvimento. Para aqueles que trabalham com implementações
em sistemas web, este é um ótimo recurso para garantir que o seu banco não terá
“filhos órfãos”, já que, por exemplo, um usuário pode desistir da compra no meio
dela. Já pensou nisso?

Neste primeiro artigo, mostrarei alguns exemplos práticos para que fiquemos bem
familiarizados com os conceitos inicias. Saliento também que, a prática no
desenvolvimento destas rotinas lhe trará maior segurança com o passar do tempo.
Todos os procedimentos que serão apresentados terão sua abordagem tanto
no SQL Server 2000 quanto no SQL Server 2005 e somente serão apontados
quando se tratar de alguma diferença relevante.

Um procedimento armazenado (Stored Procedure), é uma coleção de instruções

implementadas com linguagem T-SQL (Transact-Sql, no SQL Server 2000/2005),
que, uma vez armazenadas ou salvas, ficam dentro do servidor de forma pré-
compilada, aguardando que um usuário do banco de dados faça sua execução.
Geralmente, assim como VIEWS fazem com relatórios e dados estatísticos
escalonáveis, os SP’s encapsulam tarefas repetitivas, desde um simples INSERT,
passando por inserções por lote, updates e algumas outras instruções mais
complexas, como, efetuar uma efetivação de saque em uma conta de um
determinado cliente em uma instituição bancária ou efetivar saídas de mercadorias
seguido por baixa em estoque. Eles oferecem suporte a variáveis declaradas pelo
próprio usuário, uso de expressões condicionais, de laço e muitos outros recursos,
os quais veremos alguns mais à frente.

As vantagens do uso de Stored Procedures são claras:

• Modularidade: passamos a ter o procedimento divido das outras partes do software,

bastante alterarmos somente às suas operações para que se tenha as modificações
por toda a aplicação;

• Diminuição de I/O: uma vez que é passado parâmetros para o servidor, chamando o
procedimento armazenado, as operações se desenolam usando processamento do
servidor e no final deste, é retornado ou não os resultados de uma transação, sendo
assim, não há um tráfego imenso e rotineiro de dados pela rede;

• Rapidez na execução: os stored procedures, após salvos no servidor, ficam

somente aguardando, já em uma posição da memória cache, serem chamados para
executarem uma operação, ou seja, como estão pré-compilados, as ações também já
estão pré-carregadas, dependendo somente dos valores dos parâmetros. Após a
primeira execução, elas se tornam ainda mais rápidas;
 • Segurança de dados: podemos também, ocultar a complexidade do banco de dados
para usuários, deixando que sejam acessados somente dados pertinentes ao tipo de
permissão atribuida ao usuário ou mesmo declarando se o Stored Procedure é
proprietário ou público, podendo ser também criptografada com WITH ENCRYPTION.

Ex.: Utilizando WITH ENCRYPTION no SQL Server 2000:

Imagem I – Acessando o conteúdo de um Procedimento Armazenado pelo * Object

Browser no SQL Server 2000.

Ex.: Utilizando WITH ENCRYPTION no SQL Server 2005:

Imagem II - Acessando o conteúdo de um Procedimento Armazenado pelo
* Object Explorer no SQL Server 2005.

Repare nas imagens exibidas acima que, no SQL Server 200, recebemos
uma janela de conexão do objeto Procedure, nos mostrando que este fora criado
de forma criptografada e que o conteúdo somente poderá ser editado por quem a
criou e mesmo assim, este também não aparecerá para o dono. Somente, copiando
à parte é que teremos acesso a este procedimento criptografado, mesmo que seja
você o dono/criador dele. O comando ALTER PROCEDURE poderá ser utilizado
para modificar o conteúdo do procedimento.

Observações:

Imagem III – Brow ser e Explorer, usaremos para executar e visualizar o conteúdo
de procedimentos armazenados.

Existem certos tipos de Stored Procedures para o SQL Server 2000 e para o SQL
Server 2005, são eles:

• System Stored Procedures ou Procedimentos Armazenados do Sistema: nas

duas versões do SGBD, são criados no momento da instalação e ficam armazenados
no banco de dados chamado master, junto com as entidades e outros procedimentos
próprios do sistema. São ultilizados das mais diversas formas. Um exemplo clássico,
que utilizo muito, é o SP_HELPINDEX, para checar os índices de uma determinada
tabela, como mostra a imagem abaixo:
Imagem IV – System Stored Procedure, exemplo da tabela locadora do artigo sobre
associação detabelas.

• Local Stored Procedure ou Procedimentos Armazenados locais: esess

procedimetjos são criados em bancos de dados de usuários individuais, ou seja, no SQL
Server 2000 são proprietárias. Já no SQL Server 2005, tem o nome de Stored Procedures
Temporárias Locais, que iniciam com um sinal de # e somente a conexão que a criou
poderá executá-la. Ainda no SQL Server 2005, existem os Procedimentos Temporários
Globais, que podem ser utilizados de forma global, ou seja, por qualquer usuário desta
conexão e iniciam com ##. Ao ser encerrada esta conexão, os dois procedimentos são
eliminados.

Parte 2:

Para quem começou a acompanhar agora, vamos relembrar alguns conceitos que
nos serão úteis daqui para frente que passaremos a focar maior funcionalidade e
como conseqüência, recursos mais avançados.

Recordando... (Recordar é viver...).

PRINCIPAIS VANTAGENS DOS PROCEDIMENTOS ARMAZENADOS:

As vantagens do uso de Stored Procedures são claras:

· Modularidade: passamos a ter o procedimento divido das outras partes

do software, bastando alterarmos somente às suas operações para que se
obtenha as modificações disponíveis para toda a aplicação;
 · Diminuição de I/O: uma vez que é passado parâmetros para o servidor,
chamando o procedimento armazenado, as operações se desenrolam usando
processamento do servidor e no final deste é retornado ou não os resultados
de uma transação, sendo assim, não há um tráfego imenso e rotineiro de
dados pela rede;

· Rapidez na execução: os stored procedures, após salvos no servidor,

ficam somente aguardando, já em uma posição da memória cache, serem
chamados para executarem uma operação, ou seja, como estão pré-
compilados, as ações também já estão pré-carregadas, dependendo
somente dos valores dos parâmetros. Após a primeira execução, elas se
tornam ainda mais rápidas;

· Segurança de dados: podemos também, ocultar a complexidade do

banco de dados para usuários, deixando que sejam acessados somente
dados pertinentes ao tipo de permissão atribuida ao usuário ou mesmo
declarando se o Stored Procedure é proprietário ou público, podendo ser
também criptografada com WITH ENCRYPTION.

TIPOS DE PROCEDIMENTOS ARMAZENADOS EXISTENTES:

Existem certos tipos de Stored Procedures para o SQL Server 2000 e para o SQL
Server 2005, são eles:

· System Stored Procedures ou Procedimentos

Armazenados do Sistema: nas duas versões do SGBD (Sistema de
Gerenciamento de Bancos de Dados), são criados no momento da instalação
e ficam armazenados no banco de dados chamadoMASTER, junto com as
entidades e outros procedimentos próprios do sistema. São utilizados das
mais diversas formas. Alguns exemplos clássicos, que utilizo muito, é
o SP_HELPINDEX,SP_WHO e outros que você pode conferir no link abaixo:

http://doc.ddart.net/mssql/sql70/sp_00.htm

· Local Stored Procedure ou Procedimentos Armazenados

locais: esses procedimentos são criados em bancos de dados de usuários
individuais, ou seja, no SQL Server 2000 são proprietárias. Já no SQL Server
2005, tem o nome de Stored Procedures Temporárias Locais, que iniciam
com um sinal de # e somente a conexão que a criou poderá executá-la.
Ainda no SQL Server 2005, existem os Procedimentos Temporários Globais,
que podem ser utilizados de forma global, ou seja, por qualquer usuário
desta conexão e iniciam com ##. Ao ser encerrada esta conexão, os dois
procedimentos são eliminados.

· Extended Stored Procedure ou Procedimentos

Armazenados Estendidos: são comuns às duas versões do SGBD
Microsoft. Executam funções externas e do sistema operacional e iniciam
com “xp_”. Esses procedimentos são implementados como Dynamic-link
Librarys (DLL), executadas fora do ambiente do SQL Server.

· User-Defined Stored Procedure ou Procedimento

Armazenado Definido pelo Usuário: estes são criados em bancos
de dados pelo próprio usuário, como o nome já diz. São utilizados para
realizar tarefas repetitivas, facilitando a manutenção e alteração.
Antes que entremos definitivamente nos códigos e implementações, devemos
também passar por alguns conceitos, que trago nesta segunda parte do assunto:
“Como é o processamento inicial de um procedimento armazenado” e “Como é o
processamento subseqüente dos procedimentos armazenados”.

COMO É O PROCESSAMENTO INICIAL DE UM PROCEDIMENTO

ARMAZENADO

Assim como ocorre com todas as consultas executadas em um banco de dados,

quando executamos um procedimento armazenado pela primeira vez, a engine do
SGBD define um plano de execução, elaborado pelo otimizador interno de consultas
e o guarda em cache, denominado cache de procedimentos. O cache de
procedimentos é um conjunto de páginas que contém planos de execução para
todas as instruções/consultas executadas nesta conexão. O tamanho desse cache
varia de acordo com o nível de atividades e está localizado no pool de memória.

CRIAÇÃO

Logo após a criação do procedimento, sua sintaxe é verificada em sua precisão

sintática. Case haja algum erro na sua implementação, um erro é devolvido ao
usuário, pelo contrário, é iniciado o processo de registro do procedimento em
tabelas do sistema.
Primeiramente, a tabela sysobjects recebe o nome do objeto que foi definido pelo
usuário, o status atual deste, o tipo, um UID (Unique Identifier) e vários outros
campos como podemos ver na imagem abaixo.

Imagem 1 – Recuperando os objetos da tabela sysobjects.

As definições, ou seja, o seu código é inserido em outra tabela do sistema

chamada syscoments, juntamente com alguns comentários do sistema outros
campos, como pode ser verificado na imagem abaixo.
Imagem 2 – A tabela syscomments exibe, dentre outras informações, o conteúdo
do procedimento de forma clara e criptografado.

Execução

Após a primeira vez que o procedimento é executado ou recompilado, ele é

analisado em um processo chamado de resolução, que, revisará o seu plano de
execução diante das alterações relevantes ao melhor desempenho ao acesso a
dados.
As alterações que forçaram uma recompilação do procedimento são:

• Alteração estrutural a qual o procedimento faça referência (ALTER

VIEW, ALTER TABLE);
• Novas estatísticas de distribuição geradas; ...
">