Administrao de Banco de Dados

Jos Antnio da Cunha

CEFET-RN


ADMINISTRANDO BANCO DE DADOS

Neste artigo procuro esclarecer a importncia de duas funes
fundamentais da rea de TI: A Administrao de Banco de Dados
(DBA) e a Administrao de Dados (DA).

Muitas vezes confundidas, estas funes precisam ser bem
definidas e ressaltadas pela sua importncia no contexto dos Bancos de
Dados.
Comearemos pelos requisitos bsicos que um Administrador de
Banco de Dados (DBA) precisa ter para exercer com excelncia esta
funo.

Administrar um banco , de maneira simplista, instalar,
configurar, monitorar e solucionar problemas de um SGBD (Sistema
Gerenciador de Banco de Dados). Esmiuando este conceito, um
Administrador de Banco de Dados tem as seguintes responsabilidades:

Projeto lgico do banco de dados: criao do esquema lgico usando a
DDL;

Definio de checagem de segurana e integridade;

Decises de como os dados so representados na base de dados
armazenadas;

Projeto fsico da base de dados;

Definio de procedimentos de recuperao;

Monitorao do desempenho;

Contato com usurios para averiguao de disponibilidade dos dados
por eles requisitados e ajuda na determinao e resoluo de
problemas;

Ajustes apropriados medida que ocorram mudanas de requisitos.
Para cumprir as responsabilidades supracitadas so exigidos
conhecimentos em diversas reas relacionadas direta e indiretamente
com os SGBDs propriamente ditos. Enumeramo-los:

Arquitetura de computadores: o processo de administrao de um
SGBD pode exigir o conhecimento da estrutura fsica de servidores e de
como sintonizar hardware e software para obteno de melhor
desempenho e maior segurana;

Sistemas operacionais: necessidade de conhecer o sistema operacional
utilizado pelo SGBD, bem como os conceitos sobre processos, gerncia
de memria e sistema de arquivos, indispensveis para a resoluo de
problemas e definio de procedimentos de recuperao;

Redes: alm do conhecimento bsico, necessrio conhecer bem as
camadas de rede e aplicao. Conhecer a estrutura da rede nesse nvel
de grande importncia para monitorao do desempenho;

Projeto conceitual e lgico de bancos de dados: apesar de no estar
envolvido diretamente com o negcio, necessrio conhecer e poder
interpretar os modelos de dados que sero criados e armazenados na
base de dados, bem como conhecer as implicaes que estes modelos
podem causar no desempenho de um SGBD.

Arquiteturas de SGBDs: conhecendo os fundamentos bsicos que
guiam as implementaes dos SGBDs atuais, o administrador tem
facilidade no entendimento e questionamento da arquitetura utilizada
pelo SGBD. Muitos conceitos emitidos em treinamentos e manuais
especficos de fabricantes, no so completamente entendidos pela falta
de uma base terica do funcionamento de SGBDs.

Administrao de bancos de dados para suporte deciso ou Data
Warehouses : faz-se necessria a reciclagem tcnica dos DBAs que
passaro a ser responsveis por grandes repositrios de dados para que
os mesmos tenham conhecimento das principais tcnicas e solues
disponveis atualmente para essa nova classe de aplicao. Procuramos
esclarecer estas tcnicas no nosso curso.

sempre bom lembrar que administrar um banco diferente de
projetar lgica e conceitualmente um banco. A administrao deve
prever a utilizao do SGBD ao longo de vrios anos, garantindo a
ausncia de problemas fsicos futuros que impeam a disponibilidade
dos dados.
Como as bases de dados corporativas esto crescendo
intensamente e tornando-se cada vez mais importantes como fontes de
informaes necessrias operacionalizao das empresas e tambm
como fontes de informaes para o processo de tomada de deciso, o
Administrador de Banco de Dados deve ser um profissional especialista,
capacitado para entender e prestar suporte tcnico em cada SGBD
utilizado pela organizao.


Entendendo como funciona a organizao fsica de um database no SQL Server 2000.

Quando criamos um database, O SQL Server 2000 faz uma pr-alocao de espao,
segmentando o database em pginas de 8kb, numeradas seqencialmente. Cada conjunto de
oito pginas contguas formam uma unidade lgica maior denominada extend. Uma tabela
nasce numa extend mista e cresce em extends uniformes, por questo de otimizao de
espao.

Quando uma tabela criada, o SQL Server faz uma consulta nas pginas que
controlam extends mistas para obter um endereo de extend com espao disponvel. Da
mesma maneira, quando essa tabela precisa se expandir ser efetuada uma busca nas
pginas que controlam extends uniformes para obter o endereo de uma extend livre
(estamos falando de pginas GAM e SGAM respectivamente).

GAM Global Allocation Map
SGAM Shared Global Allocation Map

Pginas GAM controlam a alocao de extends uniformes;
Pginas SGAM controlam a alocao de extends mistas.

Essas pginas so criadas no momento da demarcao do database, que acontece na
sua criao ou no momento da expanso.

Num database, a terceira pgina ser sempre ocupada por uma pgina GAM e a quarta
por uma SGAM, responsveis por gerenciar as prximas 64.000 extends. A pgina GAM
utiliza um bit para informar se a prxima extend est livre ou no; como existem 8.000
bytes livres numa pgina, e cada byte controla 8 extends seqncias, chegamos no resultado
de 64.000 extends controladas por uma pgina GAM.

Portanto, o duedo de pginas GAM/SGAM controla at 4GB de dados (64.000 * 64KB)
(64 KB o tamanho de uma extend). Se voc criar um database de 5GB, sero encontradas
2 pginas GAM; a primeira ser a pgina de nmero 3 e a segunda vir aps
aproximadamente 64.000 * 8 = 512.000 pginas (na verdade, esse nmero 511.232, pois
so descontados 97 bytes de cada pgina para controle interno). O mesmo critrio vale para
as pginas SGAM, ocupando as posies de nmero 4 e 511.233. Ver Figura 1.




Figura 1: Alocao de pginas de dados no SQL Server 2000.


Alm de administrar extends com pginas GAM/SGAM, existe um controle
adicional, informando se a pgina est ou no alocada e seu percentual de utilizao. Esse
controle exercido por pginas com o anacrnimo PFS, de Page Free Space. Cada pgina
PFS controla 8.088 pginas contguas num database. A primeira pgina PFS a de nmero
1, logo aps a header do database, representada pela pgina 0. Como mostra a Figura
acima.

Existe ainda um controle utilizado para gerenciar as extend utilizadas por heaps e
ndices, fornecido pelas pginas IAM (Index Allocation Map). Uma pgina IAM controla
512.000 pginas de uma tabela. Diferentemente das pginas GAM, SGAM e PFS que so
demarcadas na criao e/ou alterao de tamanho do database, pginas IAM so alocadas
randomicamente (= on demand) medida que a tabela (ou ndice cresce). As pginas
IAM so utilizadas em conjunto com as pginas PFS para orientar o banco nas incluses.

Assim, quando ocorre um insert numa heap e a pgina atual j se encontra
totalmente preenchida, efetuada uma busca conjunta nas pginas IAM e PFS para
determinar uma pgina j pertencente a essa tabela para acomodar a insero. Se no
encontrar espao nas pginas PFS, ser efetuada uma requisio na pgina GAM para uma
nova extend.

Observao: tabelas com ndices cluster no se orientam com base nas pginas
IAM, pois as inseres no so baseadas na teoria de onde existe espao, mas sim na
chave do ndice cluster.


ndices na Otimizao de Consultas

Criar ndice eficiente no uma tarefa simples; requer conhecimento das
consultas (queries) em execuo e dos diferentes tipos de ndices disponveis.

Estrutura interna de um ndice

ndices so estruturas que possuem algoritmos otimizados para acessar dados.
Assim como nas tabelas, pginas de ndices tambm ocupam espao fsico. O corpo de um
ndice formado pelas colunas da tabela cujos dados se deseja classificar seguido de uma
Pag 0
Header
Do
database
Pag 1

PFS
Pag 2

GAM
Pag 3

SGAM
..... Pag
8088

PFS

..... Pag
511232

GAM
Pag
511233

SGAM
Pag
16176

PFS
.....
referncia conhecida como ponteiro, que serve para localizar a chave na pgina de dados
da tabela.
Nota: o ndice cluster no utiliza ponteiro.

ndices no SQL Server 2000 so construdos sobre estruturas denominadas
rvores balanceadas (=B-Tree), cujo desenho lembra o esqueleto de uma pirmide. A
idia desse algoritmo fornecer um modelo de pesquisa que agilize o processo de busca,
efetuando um nmero reduzido de leituras nas pginas do ndice para que se obtenha a
localizao da chave pesquisada.

Fazendo uma analogia com um livro, quando procuramos por determinada
palavra num livro, localizamos a(s) pgina(s) desejada(s) atravs de uma busca em seu
ndice. Se fossemos ensinar algum como procurar a palavra ADMIN num livro de SQL
Server, provavelmente ensinaramos alguma coisa assim:
1. Localize o ndice remissivo no final do livro;
2. Procure o bloco de palavras que iniciam pela letra A;
3. Efetue uma leitura seqencial nesse bloco at localizar a palavra desejada.

A Figura 2 na pgina seguinte, ilustra um processo de busca envolvendo a
mesma pesquisa anterior numa rvore B-Tree de um ndice no-cluster. O processo tem
incio numa pgina-mestre conhecida como root page, procurando pela maior chave da
pgina cujo valor menor ou igual palavra pesquisada. Em nosso exemplo, a primeira
palavra cujo cdigo alfabtico menor ou igual ADMIN ACESSO, portanto
seguiremos nessa direo at a pgina de nmero 2, localizada num nvel intermedirio
conhecido por non leaf level. A busca finalizada no nvel folha ou leaf level page,
onde encontramos a referncia para a pgina de dados onde se localiza a palavra
ADMIN.
















































Figura 2: Estrutura de ndices no SQL Server 2000.


Tipos de ndices existentes no SQL Server 2000

Existem dois tipos bsicos de ndices:
1. Cluster
2. No-cluster

ndices cluster impem uma organizao na prpria pgina de dados da tabela,
fazendo com que permaneam classificadas de acordo com a composio de sua chave.

Portanto, se voc executar o comando a seguir:

Select * from Northwind.dbo.Orders

Ir notar que os pedidos so ordenados pela coluna OrderID que faz parte do
ndice cluster PK_Orders. Podemos ento afirmar que o leaf level de um ndice cluster

representa a prpria pgina de dados da tabela, descartando a utilizao de ponteiros para
pginas de dados.

J os ndices no-cluster possuem estruturas prpria, mantendo-se vinculados s
pginas de dados pela utilizao de ponteiros.


A tabela SysIndexes responsvel pelo armazenamento dos metadados do
ndice. Nessa tabela localizamos o nome do ndice, uma indicao de seu tipo (cluster ou
no-cluster), o nmero de pginas utilizadas, o nmero de alteraes desde que o ltimo
clculo de estatsticas foi executado etc.

Tabelas sem ndice cluster conhecidas por heaps possuem uma linha em
SysIndexes para IndId=0. Se uma tabela possui ndice cluster, este ser indicado por
IndId=1. Porntanto, se voc quiser listar as tabelas que no possuem ndice cluster em seu
database, basta selecionar as entradas em SysIndexes para IndId=0.

O termo cluster index scan utilizado para especificar varreduras seqenciais nas
pginas de dados de uma tabela que possui ndice cluster. Nesse caso, a pgina
inicial da tabela encontra-se em SysIndexes para IndId=1.
O termo table scan utilizado para especificar varreduras seqenciais nas pginas
de dados heaps. Nesse caso, a pgina inicial da tabela encontra-se em
SystemIndexes.FirstIam para IndId=0.

Pginas de dados de tabelas com ndice cluster so ligadas uma s outras, isto
, no cabealho de cada pgina so encontradas referncias pgina anterior e posterior (=
Next/Previous Page). Para um processo efetuar uma leitura seqencial numa tabela com
ndice cluster conhecida como cluster index scan precisar apenas localizar a pgina
inicial em SysIndexes.Root; as pginas seguintes estaro encadeadas.

J em heaps o processo diferente pelo fato das pginas de dados no possurem
ordenao. Pode-se iniciar um lote de insero numa pgina localizada no meio da tabela,
utilizando espao gerado por uma srie de delees e terminar o processo no fim da
tabela, alocando-se uma nova extend.

Como j vimos, em heaps as pginas no so ligadas uma as outras. Ento, para
varrer as pginas pertencentes a uma heap, o SQL Server utiliza pginas especiais
denominadas pginas IAM que controlam as pginas utilizadas por uma tabela. Portanto,
num processo de leitura de um heap o SQL Server 2000 se norteia pelas pginas IAM.

Criao de um ndice passo a passo

Para criar um ndice na tabela Orders do banco de dados Northwind no
Enterprise Manager, expanda o banco de dados selecionando a opo Tables. Clique com o
boto direito sobre a tabela Orders, selecione Design Table e na barra de
ferramentas clique em manager Indexes/keys para que a tela apresentada
na Figura 3 obtenha o foco principal.
































Figura 3: Janela para configurao do ndice.

As opes disponveis na tela de manuteno de ndices so:

Table Name: nome da tabela onde se deseja criar o ndice.
Type: selecione new para criar um novo ndice ou Delete para excluir um ndice
existente. Os tipos possveis so Index ou Primary Key.
Index Name: nome do ndice.
Column Name... Order: colunas que compem a chave do ndice.
Index Filegroup: indicao do filegroup para criao do ndice. Se voc no possui
discos RAID, uma boa opo para ganho de performance criar tabelas e ndices
em filegroups diferentes, localizados em dispositivos distintos.
Create Unique: Unique quer dizer nico, que no permite duplicidades.
Fill Factor: indica o percentual de preenchimento das pginas do ndice no
momento de sua criao. Um fator de preenchimento de 80% informa que ser

utilizado somente 80% da capacidade da pgina para ocupao das linhas do ndice.
O fill factor atua somente no momento da criao ou reestruturao do ndice, no
sendo mantido durante os processos posteriores de atualizao do ndice.


Vale a pena destacar tambm que:

1. O valor default para fill factor zero (visvel no Query Analyzer sob o comando
sp_configure fill factor).
2. Fill factor uma opo avanada de otimizao, portanto deve ser utilizada somente
naqueles ndices onde se observou excessiva fragmentao. Utilizar essa opo de
uma maneira genrica para todos os ndices do database no boa prtica.

Pad Index:fill factor atua somente no nvel leaf level do ndice. Assinalando essa
opo, o percentual definido em fill factor ser propagado para os nveis
intermedirios da rvore B-Tree.
Create as Clustered: indica que o ndice criado ser do tipo cluster. Lembre-se que
s possvel criar um ndice cluster por tabela.
Do not automatically recompute statistics: as estatsticas de distribuio de dados
pela chave do ndice so essenciais para o otimizador avaliar uma query e, por
default, so atualizadas automaticamente aps um determinado nmero de
modificaes no ndice.


Observao: Considerando-se um processo semanal de reestruturao de ndices, pode-se
dizer que fill factor de determinado ndice est adequado medida que os indicadores do
comando DBCC SHOWCONTIG Scan Density e Avg. Page Density (full) se mantm
prximos de 100%. Quanto mais distante de 100%, maior a necessidade de utilizao do
fillfactor para controle dos custosos page-splits. Portanto, se voc encontrar ndices de scan
density muito inferiores a 80%, experimente estabelecer um pequeno fill factor e reavalie a
fragmentao aps o mesmo perodo. Comece, por exemplo, com um ndice de 95% para
fill factor e v diminuindo at encontrar seu ponto timo.

Exemplo: execute o comando a seguir no query analyser.

DBC SHOWCONTIG (Orders)

Voc obter a seguinte sada, como mostra a Figura 4:






























Figura 4: Relatrio do comando DBCC SHOWCONTIG na tabela Orders.


Sintaxe do comando DBCC, segundo BOOKS ONLINE:

DBCC SHOWCONTIG
[ (
{ 'table_name' | table_id | 'view_name' | view_id }
[ , 'index_name' | index_id ]
)]
[ WITH
{
[ , [ ALL_INDEXES ] ]
[ , [ TABLERESULTS ] ]
[ , [ FAST ] ]
[ , [ ALL_LEVELS ] ]
[ NO_INFOMSGS ]
}
]


Argumentos:

'table_name' | table_id | 'view_name' | view_id
a tabela ou viso para a qual deseja-se checar informaes de fragmentao. Se
no for especificado, todas as tabelas e vises indexadas (indexed views) no

corrente database so checados. Para obter o ID da tabela ou viso, use a funo
OBJECT_ID function.
'index_name' | index_id
o ndice para o qual deseja-se verificar informaes de fragmentao. Se no for
especificado, o processo utilize o ndice base da tabela ou viso especificada. Para
obter o ID do ndice, use a viso (view) de catlogo sys.indexes.
WITH
Especifica opes para tipo de retorno do comando DBCC.
FAST
Especifica que seja feita uma verificao rpida nos ndice.
ALL_INDEXES
Efetua a verificao em todos os ndices de uma tabela ou view.
TABLERESULTS
Mostra o resultado da verificao em forma de tabela.
ALL_LEVELS
Somente pode ser utilizada em conjunto com a opo TABLERESULTS.
NO_INFOMSGS
Suprime todas as informaes de mensagem com nvel de severidade de 0 at 10.



Estatstica Descrio
Pages Scanned Nmero de pginas na tabela ou ndice.
Extents Scanned Nmero de extents na tabela ou ndice.
Extent Switches Nmero de vezes que o comando DBCC
move-se de uma extent para outra enquanto
o comando atravessa as pginas da tabela ou
ndice.
Avg. Pages per Extent Mdia de pginas por extent
Scan Density [Best Count: Actual Count] Quanto mais prximo de 100% melhor. Um
valor menor do que 100%, significa que
existe fragmentao.
Logical Scan Fragmentation Percentage of out-of-order extents in
scanning the leaf pages of an index. This
number is not relevant to heaps. An out-of-
order extent is one for which the extent that
contains the current page for an index is not
physically the next extent after the extent
that contains the previous page for an index.
Avg. Bytes Free per Page Mdia de bytes livres na pgina escaneada.
Quanto maior melhor.
Avg. Page density (full) Average page density, as a percentage. This
value takes into account row size.
Therefore, the value is a more accurate
indication of how full your pages are. The
larger the percentage, the better.




A sintaxe T-SQL para a criao de ndices no query analyser:

CREATE [ UNIQUE ][ CLUSTER | NONCLUSTER ] INDEX index_name
ON { table | view } ( COLUMN [ asc | desc ] [, ...N ])
[ with < index_option > [ ,...N] ]
< index_option > ::=
{ pad_index |
FILL FACTOR = fillfactor |
IGNORE_DUP_KEY |
DROP_EXISTING | STATISTICS_NORECOMPUTE |
SORT_IN_TEMPDB
]

As opes disponveis na tela de manuteno de ndices so:

DROP_EXISTING: Se droparmos o ndice cluster numa tabela que possui tambm
ndice no-cluster, todos os ndices no-cluster sero reconstrudos, pois o ponteiro
desses ndices para a pgina de dados passar a ser RowID. Utilizando a clusula
DROP-EXISTING para que o rebuild nos ndices seja efetuado SOMENTE UMA
VEZ. ( aplicvel somente sobre ndices).
STATISTIC_NORECOMPUTE: desabilita a atualizao automtica das
estatsticas do ndice, informando ao SQL Server 2000 que as estatsticas do ndice
sero atualizadas por processo manual. Estatsticas desatualizadas acarretam na
escolha de planos de execuo ineficientes, portanto sugere-se no utilizar essa
opo.
SORTE_IN_TEMPDB: se voc possui o TempDB localizado num conjunto de
discos separados do filegroup do banco de dados, utilize essa opo para ganho de
performance na reconstruo do ndice.



Dicas para construir e manter ndices eficientes:

Quanto mais compacto o tamanho da chave do ndice, melhor;
Criar um ndice composto ou vrios ndices?
Processo de Scan (Clustered Index Scan ou Table Scan) em tabelas com grande
nmero de linhas representam gargalho de execuo. Fique atento para isso.
Procure criar sempre um ndice cluster em suas tabelas.
Bases OLTP so responsveis por um grande volume de acessos pontuais. Nesses
casos, procure criar PKs clusterizadas e curtas.
Em bases destinadas a consultas, reserve o ndice cluster para colunas que so
acessadas por range. (Notas data)
Se sua base de dados utilizada tanto para operaes on-line como para consultas
diversas, use o bom senso: se for interessante privilegiar os processos on-line, opte
por clusterizar as PKs. se for interessante privilegiar os relatrios, reserve o ndice
cluster para aquelas colunas que so pesquisadas com clusulas between, order by
etc.
No crie ndices em colunas com baixa seletividade. Colunas com alto grau de
duplicidade no so uma boa escolha para ndices no-cluster em funo do alto
custo.
No crie ndices em tabelas com pequeno nmero de linhas.
Mantenha as estatsticas atualizadas. Mantenha as opes Auto-Create/Update
Statistics ligadas.
Crie rotinas de indexao peridicas. Rotinas de indexao so fundamentais para
garantia de performance. No se esquea delas.
Utilize o Profiler como ferramenta de apoio no rastreamento de queries com longo
tempo de execuo. Aproveite a oportunidade para criar ndices mais eficientes ou
mesmo dropar ndices inteis.
Utilize o Index Tunning Wizard como ferramenta de apoio para tuning de ndices.
Ao criar ndices compostos, mantenha a coluna mais seletiva no primeiro nvel da
chave.
D preferncia por ndices baseados em colunas numricas em oposio a colunas
char ou varchar. ndices baseados em colunas numricas so mais eficientes.
No crie ndices em duplicidade. Um erro bastante comum criar ndice com a
mesma estrutura de outros j existentes. Habitue-se a executar um sp_HelpIndex
para confirmao dos ndices existentes.


Observaes:

ndices devem ser criados para agilizar a performance do sistema como um todo,
mas freqentemente nos esquecemos disso. Sub-avaliamos o impacto da criao de
ndices na performance geral do sistema, e aquilo que foi concebido como objetivo
inicial de ganho de performance resulta mais em um ponto de conteno.

Otimizar um processo pode significar eliminar um ndice ineficiente, implementar
novos filtros ou alterar os parmetros da clusula join das queries em execuo.
Devemos sim considerar a criao de ndices como recurso de otimizao, mas
numa anlise conjunta com todos esses fatores.



Otimizao e Tunning

Com o passar do tempo, as tabelas tendem a adquirir fragmentao os dados
que inicialmente ficavam prximos se tornam espaados (caderninho de agenda).


Conceitos sobre armazenamento de dados

No SQL Server 2000, o armazenamento feito em estruturas fsicas conhecidas
como pginas. Pginas constituem a unidade bsica de I/O, possuem tamanho fixo de
8KB e so exclusivas para cada objeto (duas tabelas no podem ocupar a mesma pgina).
Por questo de otimizao, pginas so agrupadas em unidades lgicas denominadas
extents. Uma extent corresponde a 8 pginas (64KB) e normalmente utilizada para
alocao de espao para tabelas e ndices. Observe que extents so alocadas para um
mesmo tipo de pgina; dessa forma, pginas de dados e de ndices so alocadas em extents
distintas.

Na verdade uma pgina no comporta um registro de 8192 bytes (=8KB). Desse
montante, devem ser descontados 96 bytes destinados header da pgina e 36 bytes para
controles de log, resultando em 8060 bytes. Desses 8060 bytes, ainda devem ser
descontados 60 bytes para controles internos de colunas de tamanho varivel (varchar,
nvarchar), chegando ento em 8000 bytes.

Tipo de Pgina Funo
Data Armazenam dados de tipos diferentes text,
ntext e image
Index Chave dos ndices, com ponteiros
direcionados para as pginas de dados.
Text and Image Armazena dados do tipo text, ntext e image.
Page Free Space (PFS) Controla os espaos livres nas pginas.
Global Allocation Map (GAM) Controla a alocao de extends.
Shared Global Allocation Map
(SGAM)
Controla a alocao de extends mistas pelos
objetos.
Index Allocation Map (IAM) Controla as extends utilizadas por heap
tables ou ndices. Todo objeto no momento
de sua criao registrada numa pgina
IAM e em pelo menos uma extend mista.

Tabela 1 Principais tipos de pginas encontradas num database


Observao: Um objeto nasce, cresce at 8 pginas em extents mista, e passa para extents
exclusiva.

Tabelas constituem a base do modelo relacional para o armazenamento de
informaes. So formadas por registros que esto fisicamente alocados em pginas
que por sua vez esto alocadas (logicamente) em extents. O tamanho de um registro
no pode exceder o tamanho de uma pgina

Registros podem ser gravados de maneira ordenada ou aleatria. Para que os
registros sejam gravados fisicamente de forma ordenada (por exemplo, em ordem de
nome na tabela Cliente), necessrio, a construo de um ndice especial,
conhecido por cluster. O ndice cluster a prpria tabela, no existindo portanto
uma estrutura parte para guardar informaes relativas a ordenao.
Em virtude dessa caracterstica particular, tabelas podem conter somente um ndice
cluster. Tabelas sem ndice cluster so conhecidas por heap.

Por padro uma pgina de dados no possui textos ou imagens. Veja a Tabela 1,
existem pginas especiais para esses tipos de dados. O campo destinado a imagem
armazena um ponteiro informando a pgina inicial onde reside o objeto. Esse
mecanismo traz dois benefcios: o primeiro diz respeito otimizao, pois a
separao torna o processo de leitura mais eficiente. O segundo diz respeito ao
tamanho, pois uma estrutura parte permite armazenar imagens at um limite de
2GB (vrias pginas podem ser alocadas para um nico objeto).
O SQL Server permite, atravs da opo text in row, que sejam gravados
imagens ou texto na prpria pgina de dados. Se a maior parte de seus campos
BLOB constantemente acessada e possui tamanho inferior a 8KB, possvel
ganhar performance habilitando essa opo. A linha de comando a seguir ativa a
opo de armazenamento de imagens de at 512 bytes na prpria pgina de dados:


Exec SP_TableOption Cliente, text in row, 512


Pginas de tabelas com ndice cluster so ligadas umas s outras atravs de
informaes contidas no header da pgina (por exemplo, no header da pgina 1567
estaro identificadas as pginas 1566 e 1568). Em heaps, as pginas alocadas so
registradas nas estruturas IAM, sem ordenao prvia. Para varrer uma tabela com
ndice cluster, o SQL Server 2000 acessa a pgina inicial, registrada na tabela de
sistema SYSINDEXEXES. Em seguida, as informaes contidas no header de cada
pgina direcionam ao restante da leitura. Para heaps, roteiro de leitura efetuado
atravs das pginas IAM, num leva-etraz que, para leituras seqenciais, torna-se
menos eficiente.

Causas da fragmentao:
Ocorrncia de page splits termo utilizado para designar uma diviso de
pgina de ndice, cluster ou no cluster para acomodar uma insero pontual.
Deleo de registros causando maior espaamento entre os dados.
A recuperao de dados fragmentados requer maior esforo de I/O, portanto
devemos trabalhar no sentido de minimizar este problema.
































Figura 5: Page Splits gerando uma nova Extent.



ND MB KD JB HD GB ED BB
NC MA KC JA HC GA EC BA
NB LD KB ID HB FD EB AD
NA LC KA IC HA FC EA AC
MD LB JD IB GD FB BD AB
MC LA JC IA GC FA BC AA
ND MB KD JB HD GB ED BB
NC MA KC JA HC GA EC BA
NB LD KB ID HB FD EB AD
NA LC KA IC HA FC EA AC
MD LB JD IB GD FB BD AB
MC LA JC IA GC FA BC AA
ED
EC
EB
ED
EC
EB
ND MB KD JB HD GB BB
NC MA KC JA HC GA BA
NB LD KB ID HB FD EB AD
NA LC KA IC HA FC CR AC
MD LB JD IB GD FB BD AB
MC LA JC IA GC FA BC AA
ND MB KD JB HD GB BB
NC MA KC JA HC GA BA
NB LD KB ID HB FD EB AD
NA LC KA IC HA FC CR AC
MD LB JD IB GD FB BD AB
MC LA JC IA GC FA BC AA
CR
Page Split

O SQL Server 2000 oferece o comando DBCC ShowContig para anlise da
fragmentao em ndices. Sua sintaxe :

DBCC ShowContig (Id da tabela, Id do ndice)

Onde

<Id da tabela): pode ser obtido pelo comando objeto_id<nome da tabela>
<Id do ndice>: pode ser consultado atravs da tabela de sistema sysindexes.

Exemplo:
DBCC SohwContig (Orders, 2)


Execuo do comando DBCC ShowContig na tabela Orders


Figura 6: Relatrio exibido pelo comando DBCC SHOWCONTIG


O resultado desse comando interpretado da seguinte forma:

Pages Scanned: nmero de pginas que compem o ndice analisado.

Extends Scanned: nmero de extends; aproximadamente o resultado da
diviso de Pages Scanned por 8.
Extents Switches: total de trocas de (pginas que deveriam estar numa mesma
extent esto distribudas em vrias extents). Em condies normais deve possuir
um valor prximo de Extents Scanned;

Avg.Pages per Extent: nmero mdio de pginas por extent; deve ser prximo
de 8.
Scanned Density[Best Count:Actual Count]: densidade das pginas quanto
mais prximo de 100%, melhor. Um valor igual a 75% indica 25% de
fragmentao.

Logical Scan Fragmentation: percentual de fragmentao de pginas, utilizado
somente para ndice cluster.

Avg. Bytes Free per Page: nmero mdio de bytes livres por pgina; quanto
mais prximo de zero melhor;

Avg. Page Density(full): densidade (ou preenchimento) mdio das pginas;
quanto mais prximo de 100% melhor.



A luta contra dados fragmentados s pode ser combatida com processos de
manuteno nos ndices, que discutiremos a seguir:

Crie jobs para reindexao peridicas de suas tabelas.

Uma estratgia fundamental para ganho de performance consiste na
reestruturao peridica dos ndices. Veja a seguir trs maneiras de realizar essa tarefa:

Drop/Create Index O inconveniente manter o script atualizado para recriar
todos os ndices de um database;

DBCC dbReindex Encapsula um DROP/Create para todos os ndices da tabela,
simplificando a rotina de reindexao. Se alguma falha acontecer, a estrutura
anterior ser mantida. Possui a desvantagem de estabelecer bloqueios longos;

DBCC IndexDefrag Elimina a fragmentao INTERNA nas pginas dos ndices
(no realoca extents). Possui a vantagem de estabelecer bloqueios curtos, sendo
possvel execut-lo em ambiente de produo.








Listagem 1: Cursor para reindexao de todas as tabelas de um banco de dados.

--Batch para reindexar todas as tabelas de um database

set nocount on

DECLARE tabelas CURSOR fast_forward
FOR select name from sysobjects where type = 'u'
DECLARE @nome varchar(80)
OPEN tabelas
FETCH NEXT FROM tabelas INTO @nome
WHILE (@@fetch_status <> -1)
BEGIN
IF (@@fetch_status <> -2)
BEGIN
select '[][][] Reindexando a tabela: ' +@nome
exec ('dbcc dbreindex ( ''' + @nome + ''')')
END
FETCH NEXT FROM tabelas INTO @nome
END
CLOSE tabelas
DEALLOCATE tabelas


Algumas consideraes sobre a reindexao:

Se a reindexao de todas as tabelas for custosa (devido ao tamanho por exemplo),
voc pode optar por reindexar somente as tabelas que possuem fragmentao
elevada (Scan Density < 60%), por exemplo).

Heaps no se beneficiam de processos de reindexao. Reduzir fragmentao em
heaps, portanto, significa mover dados para uma rea temporria, dropar a tabela,
recri-la e proceder a importao dos dados.


Customizaes na configurao padro

O SQL Server 2000 bastante otimizado em suas configuraes globais.
Existem, contudo, alguns parmetros que podem ser alterados na sua configurao default
para efeito de tunning.

O comando sp_configure, fornece uma viso detalhada das configuraes
passveis de alterao. Veja a Figura 7 a seguir:






Figura 7: Relatrio da execuo da sp_configure


Para que possamos alterar uma configurao, devemos informar o nome do
parmetro seguido do novo valor. O comando reconfigure with OverRide efetiva a
alterao, conforme exemplo abaixo:


Exemplo:

Sp_Configure show advanced options , 1

Reconfigure with OverRide

Sp_configure para confirmar alterao


Algumas opes que podem ser customizadas

Max Worker Threads: pool de threads disponveis pelo SO para os processos
relacionados ao SQL Server. Possui valor padro de 255, que se adapta bem para
grande parte das instalaes. Se o nmero de conexes ativas exceder esse limite,
uma thread passar a atender mais de uma conexo (thread pooling). Fique atento
para a ocorrncia da mensagem ...The working thread limit of 255 has been
reached.... Como sugesto, se o nmero mdio de usurios ativos for superior a
255, altere essa opo e avalie o desempenho do servidor.
Priority Boost: se o servidor no dedicado ao SQL Server, habilite essa
configurao para aumentar a prioridade das threads do SQL Server em relao s
outras aplicaes.

Max Worker Threads: pool de threads disponveis pelo SO para os processos
relacionados ao SQL Server. Possui valor padro de 255, que se adapta bem para
grande parte das instalaes. Se o nmero de conexes ativas exceder esse limite,
uma thread passar a atender mais de uma conexo (thread pooling). Fique atento
para a ocorrncia da mensagem ...The working thread limit of 255 has been
reached.... Como sugesto, se o nmero mdio de usurios ativos for superior a
255, altere essa opo e avalie o desempenho do servidor.

Priority Boost: se o servidor no dedicado ao SQL Server, habilite essa
configurao para aumentar a prioridade das threads do SQL Server em relao s
outras aplicaes.

Observao: Efetuar tunning em um servidor de banco de dados no um processo
simples, devemos atacar e vrias frentes para produzir resultados eficientes. Se, por
exemplo, nos concentrarmos em otimizao de queries e nos esquecermos de desfragmentar
as tabelas, o resultado ser modesto.



SQL Server 2000 Otimizao e Tunning

Otimizao e tunning de um banco de dados no SQL Server definitivamente no
uma cincia exata: existe o que podemos chamar de regras de boa conduta que devem
ser implementadas simples que possvel; No entanto, o simples cumprimento dessas regras
no garantia de boa performance. O banco de dados utilizado, o comportamento da
aplicao, as regras de negcio, a tecnologia de rede e o hardware onde o SQL Server est
instalado so alguns dos fatores externos que devem ser levados em considerao e que
podem ser decisivos para soluo do problema.


Anlise do plano de execuo de uma query no SQL Server 2000

Como exemplo, analisaremos um comando SELECT executado no database
Northwind, (Listagem 2). As tabelas Orders e Orders Details tiveram seus ndices alterados
conforme a Tabela 2. o plano de execuo gerado (Figura 8) , foi obtido diretamente no
Query Analyzer. Para isso, selecione o cone Query Display Estimated Execution Plan,
na barra de ferramenta. Os detalhamentos em amarelo na Figura 9 so obtidos ao
posicionar o cursor sobre o respectivo objeto.









Listagem 2: Select executado no database Northwind



Tabela Nome Campos Tipo
Order details Pk_Order_Details OrderID, ProductID Primary key
Orders details productID productID Nom-clustered
Orders CustomerID CustomerID Nom-clustered
Orders orderDate OrderDate Nom-cluster

Tabela 2: Composio dos ndices em Orders e Order Details.

















Figura 8: Plano de execuo para a consulta da Listagem 1.











Select * from [Northwind].[dbo].[Orders] o INNER JOIN
[Northwind].[dbo].[Order Details] od
ON o.OrderId = od.OrderID
WHERE o.orderid = 10248















Figura 9: A parte amarela, consegui-se parando o cursor em cima do cone no plano
de execuo.


Vamos analisar, atravs de comentrios, o plano de execuo do exemplo:

A leitura do plano de execuo deve ser efetuada da direita para a esquerda, de
cima para baixo. A espessura das linhas que ligam os objetos diretamente
proporcional ao custo da operao (calculado pela relao nmero de linhas x
tamanho da linha). Portanto, fique atento s linhas mais grossas.
Cada objeto presente no plano de execuo representa uma etapa desenvolvida
pelo SQL Server 2000. percorrendo o grfico, (seek) significa que o otimizador
est utilizando ndices para pesquisas pontuais. A pesquisa efetuada com
(Clustered Index scan) significa que foi utilizado um ndice Cluster. J as
pesquisas que utilizam (Index Seek) so realizadas atravs de ndices no
cluster. Pesquisas do tipo SEEK so bastantes eficientes. Fique atento quando
se deparar com o acesso do tipo Table Scan ou Clustered Index Scan, que
indicam varreduras seqenciais por toda a tabela. Acessos do tipo SCAN se
devem a pesquisas efetuadas com argumentos insuficientes na clusula
WHERE, ou ndices no qualificados. Por outro lado, importante observar
que, em alguns casos o uso de Scan prefervel. Por exemplo, para tabelas com
pequeno nmero de registros, a varredura se torna mais econmica do que o
esforo adicional causado pela pesquisa no ndice.
Um ponto interessante que a escolha do ndice apropriado para execuo do
comando SELECT se baseia em estatsticas pr-armazenadas respeito da
distribuio dos dados na tabela. O otimizador ir escolher o mtodo que
apresentar o menor custo de I/O para resolver a query, aps avaliao das
alternativas existentes. As estatsticas de um ndice so armazenadas na forma
de um histograma, podendo ser visualizada sob o comando:


Dbcc Show_Statistics <nome_da_tabela>, <nome_do_indice>


Um detalhe importante que essas estatsticas so calculadas para o primeiro segmento (ou
primeira coluna) dos ndices; portanto, assegure-se de colocar a coluna mais seletiva
sempre como o primeiro segmento de um ndice. Quanto mais seletiva a coluna menor o
custo de I/O.

Textos em vermelho nos cones do plano de execuo demonstram estatsticas
desatualizadas. Se for esse o caso, proceda atualizao clicando com o boto
inverso do mouse sobre o objeto e selecione Manage Statistics.
O objeto BookMark Lookup indica que, para cada registro lido no ndice no
Cluster, necessrio uma leitura adicional na tabela, pelo fato do ndice no
contemplar todas as colunas requisitadas pelo comando select. Uma maneira de
evitar esse passo adicional criar ndices que contemple todas as colunas requeridas
na linha SELECT, recurso conhecido como covered index. A criao desse tipo de
ndice deve ser analisada com critrio em bases OLTP, pois os ndices degradam a
performance em operaes de INSERT, UPDATE e DELETE.
O prximo passo na resoluo da query a escolha do tipo de join. No exemplo o
tipo escolhido pelo otimizador foi Nested Loop, em funo da alta seletividade das
tabelas envolvidas.

Nested Loop: o otimizador elege uma tabela, conhecida por Outer Table, que
servir de base para leitura seqencial de registros. A cada registro lido nessa tabela
efetuada uma busca pelo registro correspondente na outra tabela participante do join,
conhecida por Inner Table. Esse mtodo bastante eficiente quando uma das tabelas
possui quantidade pequena de registros, ou quando o join possui filtros que tornam o
resultado pequeno. A tabela com menor nmero de registros ser definida como Outer
Table. A Inner Table dever possuir um ndice formado pela(s) coluna(s) que unem as
duas tabelas. No exemplo, a tabela Orders representa a Outer Table e a tabela Order
Details assume o papel de Inner Table.

Merge Join: se as duas tabelas possurem ndices sobre as colunas mencionadas no
join e o nmero de registros selecionados em ambas for elevado, esse modelo ser
escolhido. O otimizador recupera uma coluna em cada lista, efetuando a comparao.
Em caso de igualdade, retorna as colunas selecionadas. Caso contrrio, a coluna de
menor valor descartada e o prximo valor da lista ser comparado. O processo se
repete at que todas as linhas tenham sido processadas.

Hash Join: se no existirem ndices adequados para a igualdade definida no join,
esse mtodo ser utilizado. Um algoritmo de hash utilizado para agilizar a
combinao. Unir duas tabelas sem ndices apropriados ou com baixa seletividade um
fator de queda de performance, portanto investigue esse tipo de ocorrncia.

Observao: a escolha do tipo de JOIN executado na query atribuio do
otimizador, que foi desenhado para esse fim. Apesar de possvel, a utilizao de hints
para forar a execuo da query por determinado tipo de join desaconselhvel. Se
fizermos isso, a query ser executada sempre da mesma maneira. Uma query executa
por Nested Loop pode ser executada via Merge Join em outro momento, dependendo do
volume de dados e dos ndices existentes.

Como ilustrao, a query a seguir fora o plano de execuo para Hash Join:

SELECT *
FROM [Northwind].[dbo].[Orders] o INNER JOIN
[Northwind].[dbo].[Order Details] od
ON o.OrderID = od.OrderID
OPTION (HASH JOIN)


A Tabela 2 a seguir mostra mais alguns objetos importantes na avaliao do
plano de execuo.

Icon Physical operator

Assert

Bookmark Lookup

Clustered Index Delete

Clustered Index Insert

Clustered Index Scan

Clustered Index Seek

Clustered Index Update

Collapse

Compute Scalar

Concatenation

Constant Scan

Deleted Scan

Filter (clsColumn)

Hash Match

Hash Match Root

Hash Match Team

Index Delete

Index Insert

Index Scan

Index Seek

Index Spool

Index Update

Inserted Scan

Log Row Scan

Merge Join

Nested Loops

Parallelism

Parameter Table Scan

Remote Delete

Remote Insert

Remote Query

Remote Scan

Remote Update

Row Count Spool

Sequence

Sort

Stream Aggregate

Table Delete

Table Insert

Table Scan

Table Spool

Table Update

Top

Tabela 2: Objetos que importantes na avaliao do plano de execuo.



Assert: utilizado para verificar condies (integridade referencial, check constraint, entre
outras) agindo como uma espcie de filtro para os registros envolvidos na operao.


Compute Scalar: utilizado para retornar sada envolvendo valores calculados (Compute
Columns, funes, etc).


Index Spool: indica que foi necessrio a criao de tabela temporria no database
tempdb para rodar a query. Esse passo muitas vezes pode ser evitado reescrevendo-se o join.


Parallellism: indica que a query est sendo executada em mais de um processador. Em
mquinas multi-processadas, o otimizador poder quebrar queries complexas e execut-las em
paralelo, normalmente ganhando performance.


Sort: presente quando a query utiliza order by ou quando o input precisa ser ordenado
para resoluo do join. No segundo caso, a perda de performance pode ser evitada criando-se
um ndice adequado.


Stream Aggregate: aparece quando utilizamos clusulas que agregam valores, como
avg, distinct, sum, Max, min ou count.


Dicas para otimizao de cdigos Transact-SQL

Limite sua busca restringindo ao mximo o nmero de colunas na clusula
SELECT. Colunas adicionais, alm de consumir mais recursos de I/O e largura de
banda, muitas vezes inibem a utilizao de ndices ou causam buscas desnecessrias
na rea de dados partir do ndice (bookmar lookup).
Filtre sempre o resultado de suas pesquisas, fornecendo parmetros de busca que se
adequem estrutura dos ndices existentes, obedecendo a ordenao de suas
colunas. Por exemplo, para o ndice composto Pk_OrderID_Details, formado pelas
colunas OrderID e ProductID, fundamental que uma pesquisa fornea pelo menos
o nmero de OrderID. Fornecer somente ProductID tornar pouco provvel o uso
do ndice pelo otimizador.
Evite o uso de funes sobre colunas pesquisadas, pois isso inibe a utilizao de
ndices. Exemplo:

Substitua:

WHERE SUBSTRING(ShipName,1,1) = M
Por:

WHERE ShipName LIKE M%


Se no for possvel evitar a funo, considere a criao de ndices sobre colunas
calculadas. Veja o exemplo:

SELECT DATEPART (month, ShippedDate)
FROM [Northwind].[dbo].[Orders]
WHERE DATEPART (month, ShippedDate) = 7


Repare que , se no tiver ndice, o otimizador escolher um Table Scan para
resolver a query. Podemos otimizar a consulta criando um ndice sobre uma coluna
calculada:

ALTER TABLE [Northwind].[dbo].[Orders]
ADD Month_OrderDate AS
DATEPART(month, ShippedDate)


CREATE INDEX IX_Month_OrderDate
ON [Northwind].[dbo].[Orders](Month_OrderDate)


Execute o SELECT:

SELECT Month_OrderDate FROM [Northwind].[dbo].[Orders]
WHERE Month_OrderDate = 7





























Figura 10: Plano de execuo do select anterior.

Observe que o Table Scan foi substitudo por um Index Seek! (veja a Figura 10).
Utilize tabela derivadas em oposio tabelas temporrias. Tabelas derivadas o
resultado da utilizao de um comando SELECT dentro de outro SELECT. Um
exemplo o uso de comandos SELECT em clusulas join.
Lembre-se que ndices existem para comparar igualdades. Evite a utilizao de
operadores do tipo <>, !>, !< e NOT. A utilizao de lgica negativa inibe o
uso de ndices pelo otimizador.
Para fins de performance, considere a utilizao de Indexed Views. A utilizao de
views simplifica a programao, mas no otimiza performance, haja visto que seu
cdigo executado de maneira integral a cada solicitao. Indexed Views
representa a materializao das views, geradas atravs da criao de um ndice
cluster na prpria view.
Se a query utiliza agrupamentos com filtragem de dados na clusula HAVING
considere a opo de filtragem diretamente na clusula WHERE, reduzindo
significativamente o trabalho do GROUP BY, j que um nmero menor de registros
sero processados.
Utilize a clusula like com critrio. Lembre-se que o comando WHERE name LIKE
SQL% utilizar um ndice para a coluna name, se esse ndice existir. J se o ndice
no existir, o comando realizar um Table Scan na tabela.
Evite o mximo o uso de cursor no SQL Server. Experimente reescrever o cdigo
utilizando outra tcnica.
Sempre que possvel, utilize variveis do tipo table em oposio tabelas
temporrias.
Para monitoramento, utilize o Profiler para capturar as queries mais demoradas,
analisando seu plano de execuo.
Existem duas configuraes de servidor que podem ser utilizadas para limitar o
tempo de execuo de uma query: query governor cost limit e query wait.

o Query governor cost limit: baseada numa projeo de tempo de execuo
calculada pelo otimizador. Se o tempo projetado for superior ao limite pr-
definido, a query ser abortada antes de sua execuo, gerando o erro 8649.
o Query Wait: estabelece um limite de tempo para o SQL Server aguardar
pela liberao de recursos de memria para execuo da query. Se o limite
estabelecido nessa configurao for excedido, a query abortar por timeout.


A alterao desse parmetro deve ser efetuado com bastante cautela, pois corre-
se o risco da query abortada estar inserida em uma transao extensa e ter adquirido muitos
locks. Como sugesto, avalie a opo query governor. Implante limites que voc considera
suficientes para seu ambiente (com boa margem de segurana) e v reduzindo
gradativamente, at chegar ao ponto ideal.


Passos para o otimizador resolver uma consulta (query):

1. Identificao dos argumentos de pesquisa (SARGS Search Arguments) utilizados
na clusula WHERE e colunas mencionadas no join;
2. Seleo do ndice apropriado, baseando-se nos SARGS. Os ndices so avaliados
em funo da sua seletividade, utilizando para isso as estatsticas de distribuio. O
ndice que requer um menor nmero de leitura para resolver o SELECT ser
escolhido;
3. Avaliao dos tipos de joins possveis e ordem apropriada de acesso as tabelas. Isso
que dizer que o otimizador definir a tabela-base do join independente da ordem
especificada no comando SELECT. Os comandos a seguir so idnticos:


Select o.OrderId from [Northwind].[dbo].[Order Details] od
INNER JOIN {Northwind].[dbo].[Orders] o
ON (od.OrdrId = o.OrdrId)

Select o.OrderId from [Northwind].[dbo].[Orders] o
INNER JOIN {Northwind].[dbo].[Order Details] od
ON (o.OrdrId = od.OrdrId)

4. Seleo do melhor plano de execuo, baseado nos custos calculados no item 3.


Anlise de bloqueios e deadlocks

Bloqueios so importantes para garantia da consistncia de dados em transaes.
O isolamento fornecido por um bloqueio no SQL Server 2000 permite que uma transao
no efetue leituras ou modifique dados que esto sendo utilizados por outra transao.

Existem vrios tipos de locks, cada um estabelecendo o isolamento necessrio
para comandos de manipulao de dados. O tipo de lock (shared, update, exclusive, schema
lock ou bulk update lock) selecionado automaticamente pelo SQL Server a menos que
voc utilize um hint, o que no aconselhvel.

O SQL Server trabalha com escalonamento de locks, permitindo que um
bloqueio de registro seja promovido para um bloqueio de pgina ou de tabela. O
escalonamento possibilita a economia de recursos (um lock consome 64 bytes de memria),
pois os bloqueios de nvel menor so liberados.

Como ilustrao, imagine uma operao de update envolvendo as 1000 linhas de
uma tabela. O que seria mais eficiente: 1000 locks de registro ou um lock de tabela? A
segunda opo, j que todas as linhas sero atualizadas.

O problema relacionado a bloqueios advm de seu tempo de durao. Bloqueios
curtos so eficientes, bloqueios longos um transtorno. Entre os fatores que aumentam a
durao de bloqueios esto s transaes longas, ausncia, excesso ou ineficincia de
ndices, bases de dados no normalizadas, utilizao indiscriminada de cursores, entre
outros. Nesses ambientes, as mensagens de erro envolvendo query timeout (#1222) ou de
deadlocks (#1205) tendem a ocorrer com maior freqncia.

Query timeout acontece quando, ao executar um comando de manipulao de
dados, aguardamos sua concluso por tempo superior a um limite previamente estabelecido.
Esse limite pode ser definido no objeto de conexo da aplicao front-end ou setado
diretamente no batch ou stored procedure atravs do comando Set Lock_Timeout.

Deadlock acontecem quando dois processos ficam aguardando pela liberao dos
mesmos recursos. O SQL Server 2000 resolve essa situao finalizando a conexo que
consumir menos recursos. Nas Listagems 3 e 4 seguem exemplos para gerar dois tipos de
deadlock: cclico e de converso.



















































Listagem 3: Deadlock cclico.














1) Abra duas sesses no Query
2) Na sesso-1, execute o comando abaixo:

Begin transaction
Update [Northwind].[dbo[.[Order Details] set
Discount=1
Where orderID=10248 and productid11
3) Na sesso-2, execute:

Begin transaction
Update [Northwind].[dbo[.[Orders] set
employeeid=4
Where orderID=10248
4) Voltando a sesso-1, execute:

Update [Northwind].[dbo[.[Orders] set
employeeid=5
Where orderID=10248
Commit
O update acima ficar travado, aguardando a liberao do recurso, bloqueio na sesso-2.
5) Na sesso-2,execute:
Update [Northwind].[dbo[.[Order Details] set
Discount=0
Where orderID=10248 and productid11
Commit

Nesse momento acontece o deadlock:
Server: Msg 1205, Level 13, State 50, Line1
Transaction (Process ID 70) was deadlocked on lock resource with another process and
has been chosen as the deadlock victim. Return the transaction































Listagem 4: Deadlock deconverso.


Uma das maneiras de monitorar as transaes envolvidas em um deadlock
ativar as traces flags 3605 e 1204, que geram informaes no log do SQL Server 2000
respeito do deadlock.

Podemos monitorar tambm um deadlock com o SQL Profiler, habilitando o
evento Lock: DeadLock Chain, que produz resultados semelhantes s traces flags acima
citadas.

Se voc no quiser que um processo aguarde indefinidamente pela liberao de
um lock mantido em outra sesso, utilize a clusula set Lock_Timeout antes de comandos
de manipulao de dados e efetue o tratamento para erros de cdigo #1222.

1)Abra duas sesses no Query
2)Na sesso-1, execute o comando abaixo:

Begin transaction
Select * from [Northwind].[dbo[.[Order] (holdlock)
Where orderID=10248
3) Na sesso-2, execute:

Begin transaction
Select * from [Northwind].[dbo[.[Orders](holdlock)
Where orderID=10248
4) Voltando a sesso-1, execute:

Update [Northwind].[dbo[.[Orders] set
employeeid=4
Where orderID=10248
Commit
O update acima ficar travado, aguardando a liberao do recurso, bloqueio na sesso-2.

5) Na sesso-2,execute:
Update [Northwind].[dbo[.[Orders] set
employeeid=5
Where orderID=10248
Commit

Nesse momento acontece o deadlock:
Server: Msg 1205, Level 13, State 50, Line1
Transaction (Process ID 70) was deadlocked on lock resource with another process and
has been chosen as the deadlock victim. Return the transaction

Minimizar tempos de bloqueios implica no comprimento de algumas regras, a
saber:

1) Mantenha suas transaes enxutas quanto menos cdigo melhor; lembre-se
quanto menor o tempo gasto por um bloqueio menor ser a possibilidade de
ocorrncia de deadlocks e travamentos;
2) Estude a possibilidade de quebrar horizontalmente e/ou verticalmente tabelas
com grandes nmeros de registros. Dados distribudos permitem maior
concorrncia, j que os locks estaro dispersos em vrias tabelas;
3) Procure atualizar astabelas nas transaes seguindo sempre a mesma ordem,
evitando assim a ocorrncia de deadlocks cclicos;
4) Evite a utilizao de SELECT com hint holdlocl seguido de um update. Essa
combinao explosiva causa freqente de deadlocks de converso;
5) Efetue expurgos peridicos em suas bases OLTP; no mantenha dados
histricos em sua base de dados de produo. Operaes em tabelas com grande
nmero de registros tendem a ser mais demoradas;
6) No crie ndices desnecessrios em bases OLTP. Um ndice criado para otimizar
uma query representar overhead nas operaes de atualizao de dados;
7) Utilize stored procedures em oposio a batchs. Por estarem residentes no
servidor e muitas vezes com planos de execuo cacheados, as SPs apresentam
performance superior.
8) Trabalhe com locks otimistas em situaes em que a leitura e modificao de
dados representem processos com considervel separao de tempo.


Observao: Normalmente s pensamos em otimizao quando nos deparamos com
situaes crticas de performance. Otimizao um processo continuo que deve ser
observado em todas as etapas de um projeto: inicia-se na modelagem, garantindo estruturas
de dados normalizadas e ndices bem definidos, continua na escrita dos batchs e stored
procedures e prossegue no dia-a-dia do DBA. Atravs de criteriosas anlise do servidor de
banco de dados, do rastreamento de queries com longo tempo de durao, da checagem de
ocorrncias de deadlocks e da implementao de rotinas de reindexao o administrador
pode garantir que o banco de dados esteja sempre correspondendo com as necessidades de
tempo de resposta da aplicao.


Profiler SQL Server

Os sistemas normalmente no nascem lentos, mas tendem a ficar mais lentos
com o tempo. O aumento do nmero de usurios, a existncia de mais processos
concorrentes, o crescimento do volume de informaes armazenadas, a falta (ou excesso)
de ndices e, por fim,a m qualidade do cdigo T_SQL so atores que ocasionam o
aparecimento de gargalos e, conseqentemente queda de performance.

Antes de pensar que o problema vem de fora e cogitar em aumentar o poder de
fogo do processador, discos ou memria, cabe uma anlise mais detalhada dos processos
ativos no servidor de banco de dados. Muitas vezes todo o problema pode ser resolvido
com a adio de um ndice ou filtro num comando update.

Mas como saber exatamente onde est o problema?

O SQL Server possui um utilitrio chamado Profiler, indicado para rastreamento
dos eventos processados numa base SQL Server 2000. o Profiler uma ferramenta de
diagnstico, ou seja, ela nos fornece material para anlise. Vale destacar que ela no se
prope por si s a efetuar correes ou qualquer espcie de tuning.

Criando uma trace passo-a-passo

O Profiler uma ferramenta para criar traces. Uma trace como uma fotografia
dos comandos executados pelo SQL Server 2000 em um determinado intervalo de tempo.
Para criar uma trace, selecione Profiler no sub-menu do SQL Server (ver Figura 1). Na tela
principal do Profiler, selecione File | New | Trace (ver Figura 2).





















Figura 11 Selecionando o Profiler no Sub-menu do Microsoft SQL Server




























Figura 12 Criando um trace no Profiler

O prximo passo ser fornecer uma conta com privilgios de system
administrator (SysAdmin) para realizar a trace (veja a Figura 3).



















Figura 13 Tela de logon do servidor onde ser realizada a trace.


Considerando que voc tenha os privilgios necessrios e tendo efetuado a
autenticao com sucesso, a tela para configurao Gerais da trace apresentada (ver
Figura 4).






















Figura 14 Configurao Geral da Trace.

As opes disponveis so:

Trace Name: nome da trace;
Trace SQL Server: identificao do servidor onde a trace est sendo executada;
Template Name: nome do modelo da trace. Quando criamos uma trace,
selecionamos determinados tipos de eventos que desejamos analisar. Para que no
precisemos informar sempre os mesmos eventos ao criar uma nova trace, salvamos
modelos chamados templates. Existem alguns templates pr-definidos, o
SQLProfilerStandard um deles. A Tabela 1 fornece uma descrio resumida dos
templates existentes.
Template file Name: caminho do arquivo de template utilizado, cuja extenso
.TDF;
Save to file: grava o resultado da trace num arquivo em disco com extenso .TRC;
Set maximum file size: informa o tamanho mximo do arquivo em disco gerado
pela trace. Ao atingir esse limite a gravao em arquivo suspensa mas o
monitoramento continua ativo na tela do Profiler.
Enable file rollover: se o rollover estiver habilitado e o arquivo atingir o limite
definido em Set maximum file size(MB), o arquivo em disco ser reiniciazado.
Neste caso, perde-se o que foi registrado em arquivo at esse momento.
Server process SQL Server trace data: se voc algum dia se deparar com a linha
de texto em sua trace ... Some events may have been lost..., isto quer dizer que o
servidor est muito ocupado e optou por no enviar alguns comandos para sua trace
para ganhar algum flego de processamento. Habilitando essa opo, voc estar
forando o servidor a enviar todos os comandos processados para a trace, mesmo
causando perda de performance. recomendado no utilizar.

Save to table: grava o resultado da trace numa tabela. mais fcil de depurar, ps
podemos colocar filtros ou ordenar da maneira que acharmos mais interessante.
Set maximum rows (in thousands): limira o nmero de linhas na tabela originada
pela trace.
Enable trace stop time: estabelece prazo limite para trmino da trace.



Nome do Template Para que serve
SQLProfileStandard Trace genrica; rastreia comandos executados com
sucesso no servidor.
SQLProfileTSQL Utilize para visualizar os comandos T-SQL
startados no servidor.
SQLProfileTSQL_Duration Utilize para obter uma trace de comandos
processados no servidor ordenados por tempo de
execuo.
SQLProfileTSQL_Group Lista os comandos startados com sucesso no
servidor, ordenados por ApplicationName,
NTUserName e ClientProcessId
SQLProfileTSQL_Replay Utilizada para gravao de traces para posterior
replay.
SQLProfile_SPs Utilizado para visualizao dos comandos T-SQL
executados internamente nas sps.
SQLProfileTuning Utilizado na gerao de eventos para posterior
anlise pelo Index Tuning Wizard.

Guia events

A guia Events (ver Figura 5), apresenta uma relao de todas as classes de
eventos que podem ser monitorados num servidor de banco de dados SQL Server 2000.
Nesse contexto, classes so agrupamentos de eventos que possuem uma caracterstica em
comum: Temos uma para controlar execuo de procedures, outra para gerenciamento de
locks, etc. o template SQLProfilerStandard, por exemplo, seleciona automaticamente
alguns eventos vistos na Tabela 2.










T1



























Figura 15 Guia Events






Classe Evento Para que serve
Security Audit Audit Logon Auditar abertura de sesses no banco.
Audit Logoff Auditar encerramento de sesses no banco.
Sessions Existent
Connections
Lista todas as conexes ativas no banco no
momento em que a trace iniciada.
Stored
Procedures
RPC:Completed Lista a execuo de sps originadas por conexes
remotas (ADO, ODBC, OLEDB etc).
TSQL SQL:Batch
Completed
Lista as queries executadas fora do contexto de uma
stored procedure.
T2




A prxima etapa ser definir que tipo de informao queremos visualizar na
trace. O template SQLProfileStandard j seleciona uma srie de colunas, mas para deixar a
tela do Profiler mais enxuta, excluiremos as colunas LoginName e a coluna
ClientProcessesId. Clique na coluna e depois em << Remove (veja Figura 6).

















Figura 16 Selecionando colunas que sero visualizadas no Profiler.


Guia Filters

Finalmente a definio da trace na guia Filters (veja Figura 7), utilizada para
refino da trace. A aplicao Profiler para mostrar na tela os comandos processados pelo
servidor SQL Server, responsvel por uma srie de comandos que so tambm
processados pelo engine do banco. Para evitar que esses comandos apaream na trace,
ligamos o filtro ApplicationName Not Like Profiler.




































Figura 17 Criando filtros para trace.


Filtros so utilizados para limitar os eventos rastreados na trace, reduzindo o
nmero de linhas afetadas, facilitando nossa compreenso e melhorando o foco de nossa
anlise. Poderamos, por exemplo, filtrar os comandos filtrados por um determinado spid.
Se desejssemos analisar a execuo de uma stored procedure em particular, poderamos
concentrar nossa anlise somente na execuo dessa sp, utilizando tambm os recursos de
filtros (nesse caso, o filtro ObjectId armazenaria o Id da trace que queremos analisar).

Concludo o processo de definio, clique em RUN para iniciar a trace (ver
Figura 8).




































Figura 18: Tela para monitoramento do Profiler


Um resumo do significado das colunas apresentadas na Figura 8 apresentado a
seguir:

EventClass: os eventos rastreados pelo Profiler so agrupados em classes.
TextData: utilizada para visualizao do dado coletado na trace. Essa coluna
depende do tipo de evento capturado (TCP/IP, evento de conexo).
ApplicationName: nome da aplicao;
LoginName: login do usurio responsvel pela execuo do comando;
CPU: tempo consumido de CPU para execuo do comando (milissegundos);
Reads: nmero de pginas lidas em memria para executar o comando;
Writes: nmero de pginas gravadas pelo comando;
Duration: durao do comando(em milissegundos);
SPID: identificao da sesso no SQL Server;
Start Time: horrio do incio da execuo do comando.

Atravs desta interface possvel:

Parar a trace: Para isto clique no boto

Iniciar a trace: Para isto clique em



Iniciar uma nova trace, efetuando toda a parametrizao novamente: Para isto clique
em
Trocar o Template SQLProfilerStandard: Para isto clique em

Carregar uma trace previamente gravada em arquivo .TRC: Para isto clique no
cone
Carregar uma trace gravada em uma tabela no banco: Para isto clique em
Acessar a tela de configuraes gerais da trace: Para isto utilize o cone de
propriedades
Procurar por uma determinada string na trace que voc acabou de gerar: Para isto
utilize o binculo
Efetuar uma limpeza na tela: Para isto utilize a borracha


Agora um teste prtico. Com o Profiler ativo, abra uma sesso no Query
Analyzer e execute a seqncia de comandos a seguir:














Agora um teste prtico. Com o Profiler ativo, abra uma sesso no Query
Analyzer e execute a seqncia de comandos a seguir:










Use Northwind
Go
Create procedure stp_Mostrar_Pedido (@OrderId int0
As
select O.OrderId, O.CustomerId, O.EmployeeId, d.ProductId, d.UnitPrice, d.Quantity
from Orders O inner join [Order Details] d
on O.OrderId = d.OrderId
Where O.OrderId = @OrderId
Return
go










Dirija-se ao profiler e confirme o resultado (veja a Figura 9 no slide seguinte).



























Figura 19: Resultado da execuo de comandos na console do profiler.


Gravando a Trace
Para gravar a trace, siga at a opo File da barra de menu e escolha Save AS
(ver Figura 10).




Exec stp_Mostrar_Pedido 10249
go






















Figura 20: Salvando a trace

As opes disponveis para salvamento da trace so:

Trace Template: utilize para gerar um template (arquivo com extenso .tdf, de
Template Data File);
Trace File: salva um arquivo em disco com extenso .trc com o resultado da trace;
Trace Table: armazena o resultado da trace em uma tabela.
SQL Script: gera um arquivo texto (extenso .sql) com o lote de comandos T-SQL
necessrios para criar e executar a trace.

Concluso

Quando o assunto tuning, o Profiler uma ferramenta indispensvel. Na
prxima aula continuaremos esse assunto e nos aprofundaremos nos principais eventos que
devem ser analisados, tendo em vista a otimizao de processos. At l!


Profiler (continuao)

Criando uma trace para anlise de performance de um servidor SQL Server








1. Anlise preliminar: identificando stored procedures e batchs com baixa performance.

Demora excessiva para concluso de consultas, deadlocks em demasia e problemas
com timeout nas aplicaes esse o quadro de um servidor com srios problemas de
performance. Nosso objetivo inicial ser efetuar um levantamento para determinar quais
so os processos mais demorados, cronometrando a execuo de batchs e stored
ptrocedures nesse servidor.

Passos para realizar esta tarefa:
1) inicie o Profiler.
2) Escolha New Trace na opo File da barra de ferramentas.
3) Na tela de propriedade da Trace, confirme a seleo do template
SQLProfilerStandard na guia General. (Esse template captura a execuo de
batchs(TSQL\SQL:batch Completed e Stored Procedures\RPC:Completed).
4) Os eventos Security Audit e Sessions no so necessrios para essa anlise,
podendo ser removidos. Veja a Figura 21.




Figura 21: Relao final de eventos que devem ser selecionados.







As colunas e ordem de apresentao dos eventos do template SQLProfilerStandard
sofrero duas alteraes: na guia Data Columns ordenaremos as linhas capturadas segundo
seu tempo de execuo e eliminaremos algumas colunas desnecessrias nesse momento.

5) para ordenar as linhas do Profiler segundo a durao do comando executado,
selecione Duration e clique em Up at que essa coluna fique logo abaixo de Groups.
6) As colunas removidas foram: NTUserName, Loginname, CPU, Reads, Writes e
ClientProcessId. Veja a Figura 22.




Figura 22: Colunas selecionadas para visualizao no Profiler.


At esse momento, a trace ir capturar todos os batchs e sps executados nesse
servidor. Seria interessante ligar um filtro de tempo de modo que s fossem capturados os
processos com tempo de execuo acima de um determinado limite.

7) para conseguir esse efeito, vamos ligar o filtro Duartion na guia Filters, trabalhando
com um limite de 2000 milisegundos. Veja a Figura 23.













Figura 23: Filtrando comandos T-SQL cujo tempo de durao for superior a 2000
milisegundos.


8) agora inicie a trace clicando <RUN>.
9) Para simular uma atividade no SQGBD, abra uma sesso no Query Analyzer, digite
as linhas da Listagem 1 e confirme o resultado na tela do Profiler. Veja a Figura 24.







































Listagem 1



Figura 24 Executando a trace com o filtro Duration ativo.



use Northwind
go

create proc stp_teste
as
select top1 * from orders
select top 1 * from [order details]
waitfor delay '00:00:03'
select top 1 * from customers
go

exec stp_teste
go
select count(*) from [order details]
go
select top 10 * from orders
go


2. Anlise especfica: identificando comandos T-SQL com baixa performance.

A trace gerada anteriormente forneceu a relao de batchs e sps que esto
apresentando tempo de execuo superior a 2 segundos. No caso da stored procedute
stp_teste, temos que identificar qual comando T-SQL est sendo responsvel pela lentido.
Para isto, vamos criar uma trace para analisar somente a sp stp_teste.

1) O ponto de partida identificar o id do objeto que queremos selecionar. No Query
Analyzer, digite:






2) Crie uma trace, selecionando os eventos conforme a Figura 25.




Figura 25: Eventos que devem ser selecionados para visualizar a execuo dos comandos
T-SQL dentro das sps.

SP:Completed ir gerar uma linha contendo a chamada para a procedure.
SP:StmtCompleted ir gerar uma linha para cada comando T-SQL executado dentro da sp


Select object_id (1stp_teste)

1637580872


3) Na guia Data Columns, selecione os mesmo eventos analisados na Figura 26.


Figura 26: Selecionando colunas para analisar execuo de sp.

4) Na guia Filters, siga at ObjectId e informe o id da procedure stp_teste obtida
anteriormente. Veja a Figura 27
.















































Figura 27: Ligando o filtro ObjectId para filtrar os comandos T-SQL executados na
procedure stp_teste.

5) Rode a trace <RUN>
6) Execute a procedure stp_teste. Veja o resultado na tela profiler (Figura 28).



Figura 28: Visualizao dos comandos executados na procedure stp_teste.





3) Rastreando processos envolvidos em Deadlocks

Deadlock uma causa freqente de m performance, pois requer que a conexo
escolhida como vtima e cuja execuo de comandos foi abortada- envie novamente o
comando para execuo. O profiler possui dois eventos que nos ajudam a rastrear
deadlocks:

Lock:Deadlock informa a ocorrncia do erro#1205 associado ao deadlock.
Lock:DeadlockChain ir apontar o spid das conexes envolvidas no deadlock.


4) Evitando CacheMiss

Quando acionamos uma sp, seu plano de execuo fica em memria. Nesse plano
so armazenadas instrues de como a query dever ser executada: que ndice utilizar, o
tipo de join selecionado, etc. antes de criar um plano de execuo novo, o otimizador faz
uma busca na rea de cach destinada a procedures procurando por um plano pr-existente.
Se a busca for bem sucedida, o ser aproveitado e a sp ser executada de acordo com ele.

Existem algumas situaes onde o otimizador obrigado a fazer vrias tentativas
at encontrar o cdigo pr-compilado. Cada uma dessas tentativas mal sucedidas dispara
um evento conhecido por SP:CacheMiss, que pode ser evitado seguindo-se as dicas abaixo:

No utilize o prefixo sp_ para nomear suas sps. Quando o otimizador encontra
uma procedure com o prefixo sp, sua execuo desencadeada no banco de dados
mster. Como a sp no existe nesse banco de dados, seu plano de execuo no
encontrado na primeira tentativa, disparando um evento SP:cacheMiss. O processo
de execuo prossegue procurando a sp no banco de dados local, onde o cdigo
compilado encontrado e a sp executada.
Execute stored procedure qualificando seu dono (owner). Lembre-se que voc pode
possuir objetos com o mesmo nome, mas com owner diferentes. Troque exec
stp_teste por exec dbo.stp_teste.



Principais comandos utilizados na manipulao de traces:

1) Para gerar o script de uma trace: na barra de ferramentas do profiler, selcione
File...Save As SQL Script.
2) Verificando as traces ativas no servidor:

Select * from ::fn_trace_getInfo(default)



3) Pasa parar uma trace:

Sp_trace_setstatus 1,0

<1>: id da trace, levantado no item -2
<<0>: parmetro para stopar a trace.

4) Para iniciar (ou restaurar) uma trace:

St_trace_setstatus 1,1

<1>: id da trace, levantado no item -2
<1>: parmetro para iniciar a trace.

5) Para encerrar uma trace, ecluindo sua definio da memria do servidor:


St_trace_setstatus 1,2

<1>: id da trace, levantado no item -2
<2>: parmetro para encerrar a trace.

PS: necessrio stopar antes.


Nota: Funes internas no SQL Server 2000 que possuem o prefixo fn_ precisam ser
chamadas com a adio de :: (duas vezes o sinal de pontuao dois pontos).


Utilizando filegroups para ganho de performance e gerenciamento de espao

Filegroups so estruturas lgicas que sustentam os arquivos de dados em um
database. Um database padro possui um arquivo de dados e um arquivo de log; o arquivo
de dados est associado a um filegroup chamado PRIMARY. Pode-se criar outros arquivos
de dados assim como outros filegroups, mas porque, como e quando criar outros
filegroups?

Arquitetura de um database

Apesar do nome singular, um database uma estrutura formada por pelo menos
dois arquivos: um para armazenamento de dados (Mster Data File, extenso .MDF) e
outro reservado para o log de transaes (Log Data File, extenso .LDF). Veja a Figura 29.









alm dos arquivos .MDF e .LDF, possvel criar outros arquivos para
armazenamento de dados. Estes arquivos secundrios possuem extenso .NDF, de
Secondary Data Files e podem ser criados no mesmo filegroup do arquivo .MDF
(PRIMARY) ou em outro filegroup. A deciso de utilizar o mesmo filegroup ou criar um
novo depende da finalidade do arquivo secundrio. A seguir esto listados algumas
situaes cuja resoluo baseia-se na implementao de filegroups:
O arquivo de dados principal atingiu um tamanho que extrapola a capacidade da
unidade de fita DLT utilizada no backup. Esse problema pode ser resolvido com a
realocao de tabelas em outro filegroup, distribuindo o backup final em partes
menores que no ultraapssem a capacidade da fita. Nesse caso, deve-se criar outro
filegroup para armazenar o arquivo secundrio.
Voc precisa criar um database com tamanho inicial de 35GB, mas no possui esse
espao em uma nica unidade de disco. A distribuio a seguinte: 20GB na
unidade C e 15GB na unidade D. qual a soluo? Crie um Mster Data File com
15GB em C e um Secondary Data File com 20GB em D. os dois arquivos
constituiro uma unidade nica de gerenciamento de espao. O arquivo secundrio
criado na unidade D ser visto pelo SQL Server como uma extenso natural do
arquivo primrio. Nesses casos, o arquivo secundrio dever ser criado no mesmo
filegroup do arquivo que se deseja expandir (PRIMARY).

Db_Teste
C:\Teste\Teste_data.MDF
C:\Teste\Teste_log.LDF
Figura 29: Estrutura tpica de um database.
Voc pode melhorar a performance de um database criando ndices e tabelas em
filegroups distintos, localizados em unidades e controladores especficos. Se as
pginas de dados das tabelas forem armazenadas em unidades diferentes daquela
utilizada para os ndices (por exemplo C e D), pesquisas que utilizam ndices sero
beneficiadas por leituras executadas em paralelo. Nesse caso, deve-se criar outro
filegroup para armazenar o arquivo secundrio.


A Figura 30 um retrato de um database que utiliza um filegroup secundrio
para armazenamento de ndices.




Criando um database atravs de comandos T-SQL

O comando T-SQL create database pode ser utilizado na criao do database
como uma opo ao uso do Enterprise Manager. Veja o comando a seguir:

CREATE DATABASE [db_Teste] ON
(
NAME = Ndb_Teste_Data,
FILENAME = Nc:\Teste\db_Teste_Data.MDF,
SIZE = 1,
FILEGROWTH = 10%
)
LOG ON
(
NAME = Ndb_Teste_Log,

Db_Teste
C:\Teste\db_Teste_data.MDF
C:\Teste\db_Teste.NDF
C:\Teste\db_Teste_log.LDF
Figura 30: Database que utiliza arquivo secundrio (.NDF) para
armazenamento de ndices
FILENAME = Nc:\Teste\db_Teste_Log.LDF,
SIZE = 1,
FILEGROWTH = 10%
)



No exemplo acima, criamos o database db_Teste_data no filegroup PRIMARY
representado por c:\Teste\db_Teste_data.MDF. o database tambm possui um arquivo de
Log em c:\Teste\db_Teste_Log.LDF, mas ainda no criamos arquivos secundrios.

Criando arquivo secundrio

Criando um arquivo secundrio atravs do T-SQL.

ALTER DATABASE db_Teste_Data
ADD FILE
(...
FILENAME = Nc:\Teste\db_Teste_Data2.NDF,
SIZE = 1,
...)
FILEGROWTH = 10%
) TO FILEGROUP [PRIMARY]


Comandos DBCC Database Consistency Checker

No SQL Server 2000 e 2005, atravs da linguagem T_SQL, temos uma srie de
comandos para manuteno e otimizao de tabelas e de ndices, comandos estes
conhecidos como comandos DBCC. Este grupo de comandos conhecido como
comandos DBCC, porque todos iniciam com o prefixo DBCC. A grande maioria destes
comandos utilizada para verificao da consistncia fsica e lgica de um banco de dados
e de seus elementos tais como tabelas e ndices. Em muitas situaes, o comando, alm de
fazer a verificao, capaz de corrigir os problemas encontrados.

Podemos dividir os comandos DBCC em quatro categorias: manuteno, status,
validao e diversos.





Principais comandos DBCC de Manuteno

Comando DBCC DBREINDEX

Utilizamos este comando para reconstruir um ou mais ndices em uma tabela de um
Banco de Dados.

Sintaxe conforme Books Online:

DBCC DBREINDEX
( [ database.owner.table_name
[, index_name
[, fillfactor ]
]
]
) [ WITH NO_INFOMSGS ]

Algumas observaes a respeito deste comando:
No podemos utilizar este comando em tabelas do sistema (master, msdb, etc.)
Por padro, somente a role de servidor sysadmin e as roles de banco de Dados
db_owner e db_dbaldmin tm permisso para executar este comando.


Vamos a alguns exemplos prticos:

Reconstruir o ndice UPKCL_auidind, da tabela authors do banco de Dados pubs.

Use pubs
DBCC DBREINDEX (authors, UPKCL_auidind, 80)

O terceiro parmetro a definio para Fill Factor, uma medida para o percentual de
espao a ser deixado em branco, nas pginas do banco de Dados, quando da construo
do ndice.

Para reconstruir todos os ndices de uma tabela, basta no especificar um nome para o
ndice; apenas coloque dois apstrofos, conforme indicado no exemplo a seguir, onde
so reconstrudos todos os ndices da tabela titles do banco de dados pubs:

Use pubs
DBCC DBREINDEX (titles, , 80)








Commando DBCC INDEXDEFRAG

Utilizamos este comando para desfragmentar Clustered e Secondary Indexes de uma
tabela.

Sintaxe conforme Books Online:
DBCC INDEXDEFRAG
( { database_name | database_id | 0 }
, { table_name | table_id | 'view_name' | view_id }
, { index_name | index_id }
) [ WITH NO_INFOMSGS ]

Vamos fazer algumas consideraes a respeito deste comando:
No podemos utilizar este comando em tabelas do sistema (master, msdb, etc).
Por padro, somente a role de servidor sysadmin e as roles de banco de Dados
db_owner e db_dbaldmin tm permisso para executar este comando.

Este comando, alm de desfragmentar os ndices, compacta suas pginas, levando
em conta o valor original do parmetro FILL FACTOR, quando da criao do
ndice.

Vamos a um exemplo prtico:

Desfragmentar o ndice UPKCL_auidind, da tabela authors do banco de dados pubs:

Use Pubs
DBCC INDEXDEFRAG (pubs, authors, UPKCL_auidind)

Commando DBCC SHRINKDATABASE

Este comando utilizado para que possamos reduzir o tamanho de um ou mais
arquivos de dados de um Banco de Dados.

Sintaxe conforme Books Online:
DBCC SHRINKDATABASE
( database_name [ , target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)



Algumas observaes a respeito deste comando:

No podemos reduzir o tamanho de um Banco de Dados a menos do que o tamanho
do Banco de Dados model.
Por padro, somente a role de servidor sysadmin e a role de Banco de Dados
db_owner tm permisso para executar este comando.
Este comando no ir reduzir um arquivo de Banco de Dados a um tamanho menor
do que o tamanho de seus dados.

Vamos a alguns exemplos prticos:

Reduzir o tamanho dos arquivos do Banco de Dados Exemplo1, mantendo um espao livre
de 25% em cada arquivo.

Use Exemplo1
GO
DBCC SHRINKDATABASE (Exemplo1, 25)

O segundo parmetro 25 indica o percentual de espao livre que deve ser mantido,
em cada arquivo de dados, aps a execuo do comando. Por exemplo, um arquivo de
dados possui 20 MB, dos quais 10 MB esto ocupados com dados. Aps a execuo do
comando, sero mantidos, evidentemente, os 10 MB de dados, mais 2,5 MB (25%) de
espao livre. Na verdade o SQL Server ir arredondar para 13 MB.


Comando DBCC SHRINKFILE

Utilizamos este comando para reduzir o tamanho de um arquivo de dados (primrio
ou secundrio), ou de um arquivo de log do Banco de dados.

Sintaxe conforme Books Online:
DBCC SHRINKFILE
( { file_name | file_id }
{ [ , target_size ]
| [ , { EMPTYFILE | NOTRUNCATE | TRUNCATEONLY } ]
}
)







Algumas consideraes a respeito deste comando:

No podemos reduzir o tamanho de um Banco de Dados a menos do que o tamanho
do Banco de Dados model.
Por padro, somente a role de servidor sysadmin e a role de Banco de Dados
db_owner tm permisso para executar este comando.
Este comando no ir reduzir um arquivo de Banco de Dados a um tamanho menor
do que o tamanho de seus dados.

Vamos a alguns exemplos prticos:

Reduzir o tamanho do arquivo primrio de dados, do Banco de Dados Exemplo1 a 7 MB.

Use Exemplo1
DBCC SHRINKFILE (Exemplo1-prim, 7)


A opo EMPTYFIL migra todos os dados do arquivo especificado, para outros
arquivos de dados no mesmo Filegroup. Novos dados no podero ser gravados em um
arquivo em que a opo EMPTYFILE foi especificada.; com isso podemos excluir o
arquivo, utilizando o comando ALTER DATABASE.

Use Exemplo1
Go
DBCC SHRINKFILE (exemplo1-sec, EMPTYFILE)
GO
ALTER DATABASE Exemplo1
REMOVE FILE exemplo1-sec


Comando DBCC UPDATEUSAGE

Este comando informa e corrige erros nas informaes e estatsticas sobre o espao
utilizado em disco. Estes erros podem fazer com que o comando sp_spaceused retorne
informaes incorretas.

Sintaxe conforme o Books Online:
DBCC UPDATEUSAGE
( { 'database_name' | 0 }
[ , { 'table_name' | 'view_name' }
[ , { index_id | 'index_name' } ] ]
)
[ WITH [ COUNT_ROWS ] [ , NO_INFOMSGS ]
]

Algumas consideraes a respeio deste comando:

Se no existerem problemas nas informaes e estatsticas de uso de espao em
disco, este comando no retornar nenhuma mensagem. Este comando tenta corrigir
erros nas seguintes colunas da tabela sysindexes: rows, used, reserved e dpages.
Por padro, somente a role de servidor sysadmin e a role de Banco de Dados
db_owner tm permisso para executar este comando.


Vamos a um exemplo:

DBCC UPDATEUSAGE (Northwind)


Principais Comandos DBCC de Status

Comando DBCC SHOWCONTIG

Este comando exibe informaes sobre a fragmentao dos dados e dos ndices de
uma determinada tabela.

Sintaxe conforme Books Online:
DBCC SHOWCONTIG
[ ( { table_name | table_id | view_name | view_id }
[ , index_name | index_id ]
)
]
[ WITH { ALL_INDEXES
| FAST [ , ALL_INDEXES ]
| TABLERESULTS [ , { ALL_INDEXES } ]
[ , { FAST | ALL_LEVELS } ]
}
]
Algumas observaes a respeito deste comando:

DBCC SHOWCONTIG utilizado para determinar o quo fragmentada est uma
tabela. A fragmentao ocorre devido a operaes que alteram dados, como
insero, alterao e excluses. Esta fragmentao pode prejudicar o desempenho
de pesquisas realizadas nos dados da tabela. A queda no desempenho pode ser pior
no caso de consultas que utilizam uma ou mais clusula Join.
Por padro, somente a role de servidor sysadmin e as roles de Banco de Dados
db_owner e db_ddladmin tm permisso para executar este comando.
Com o comando DBCC SHOWCONTIG, pode-se utilizar as seguintes opes:
o WITH FAST: determina que seja feita uma verificao rpida nos ndices;
o WITH TABLERESULTS: exibe o resultado da verificao em forma de
tabela;
o WITH ALL_INDEXES: efetua a verificao em todos os ndices de uma
tabela ou view;
o WITH ALL_LEVELS: somente pode ser utilizada em conjunto com a
opo TABLRESULTS. Retorna informaes mais detalhadas para cada
nvel dos ndices.


Vamos a alguns exemplos:

Utilizar o comando DBCC SHOWCONTIG para retornar informaes sobre todos os
ndices de todas as tabelas, do Banco de Dados Northwind.

Use Northwind
DBCC SHOWCONTIG WITH TABLERESULTS, ALL_INDEXES

Tambm poderamos retornar as informaes sobre a fragmentao em uma nica tabela,
conforme o exemplo a seguir:

Use Northwind
DBCC SHOWCONTIG (Orders)


Commando DBCC USEROPTIONS

Com este comando obtemos informaes sobre as opes definidas para conexo
ativa com o Banco de Dados.

Sintaxe conforme Books Online:

DBCC USEROPTIONS

Exemplo:

DBCC USEROPTIONS


Principais Comandos de Validao

Comando DBCC CHECKDB

Faz a verificao da alocao do espao nas pginas de dados e da integridade
estrutural de todos os objetos de um Banco de Dados. Alm da verificao, este comando
capaz de reparar problemas com a alocao de espao no Banco de Dados. Dependendo do
tamanho do Banco de Dados e do volume de dados, este comando pode demorar um bom
tempo para ser executado.

Sintaxe conforme Books Online:

DBCC CHECKDB
( 'database_name'
[ , NOINDEX
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
} ]
) [ WITH { [ ALL_ERRORMSGS ]
[ , [ NO_INFOMSGS ] ]
[ , [ TABLOCK ] ]
[ , [ ESTIMATEONLY ] ]
[ , [ PHYSICAL_ONLY ] ]
}
]

Algumas observaes a respeito deste comando:

Por padro, somente a role de servidor sysadmin e a role de Banco de Dados
db_owner que tm permisso para executar este comando;
Este comando faz uma verificao da integridade de todos os elementos de um
Banco de Dados.

Vamos a alguns exemplos.

Fazer uma verificao de integridade no banco de Dados Northwind.

Use Northwind
DBCC CHECKDB

Tambm podemos utilizar algumas opes com o comando DBCC CHECKDB. Por
exemplo, a opo NOINDEX define que os no clustered das tabelas criadas pelos usurios
no devem ser verificados.

DBCC CHECKDB (Northwind, NOINDEX)

Comando DBCC CHECKTABLE

Faz a verificao da integridade das pginas de dados, ndices e pginas com
valores de campos do tipo text, ntext e image. Devemos utilizar este comando em tabelas
com suspeita de dados corrompidos.

Sintaxe conforme Books Online:

DBCC CHECKTABLE
( 'table_name' | 'view_name'
[ , NOINDEX
| index_id
| { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD }
]
) [ WITH { [ ALL_ERRORMSGS | NO_INFOMSGS ]
[ , [ TABLOCK ] ]
[ , [ ESTIMATEONLY ] ]
[ , [ PHYSICAL_ONLY ] ]
}
]

Algumas observaes a respeito deste comando:

Por padro, somente a role de servidor sysadmin e a role de Banco de Dados
db_owner que tm permisso para executar este comando;
feita uma verificao da integridade fsica de tabelas.

Vamos a alguns exemplos:

Verificar a integridade da tabela Orders do banco de Dados Northwind.

Use Northwind
DBCC CHECKTABLE (Orders)

Verificar a integridade somente das pginas de dados da tabela Orders do Banco de Dados
Northwind, isto , sem fazer a verificao dos ndices.

Use Northwind
DBCC CHECKTABLE (Orders) WITH PHYSICAL_ONLY


Mais Comandos DBCC


Comando DBCC HELP

Este comando retorna a sintaxe para um determinado comando DBCC.

Sintaxe conforme Books Online:

DBCC HELP ( 'dbcc_statement' | @dbcc_statement_var | '?' )
Por padro, somente a role de servidor sysadmin que tem permisso para executar
este comando.


Considere o exemplo:

DBCC HELP (CHCKDB)

Este comando ir retornar a sintaxe para o comando DBCC CHECKDB.

Agora considere o seguinte exemplo:

DBCC HELP (?)

Este comando retorna uma listagem de todos os comandos DBCC, sem o prefixo DBCC,
para os quais est disponvel ajuda, atravs do comando DBCC HELP.


Nota: para uma referncia completa de todos os comandos DBCC, voc pode acessar o
item DBCC, na referncia da linguagem T-SQL, no Books Online.






























Definindo opes de bancos de dados
Vrias opes de bancos de dados podem ser definidas para cada banco de dados.
Apenas o Administrador de Sistema (SA) ou o proprietrio do banco de dados pode mudar
estas opes. A mudana destas opes s modificar o banco de dados atual; no afetar
outros bancos de dados.

As opes de bancos de dados podem serem modificadas com o procedimento
armazenado de sistema sp_dboption, ou atravs do Enterprise Manager. O procedimento
armazenado sp_dboption s afeta o banco de dados atual, mas para modificar opes
nvel de servidor, use o procedimento armazenado de sistema sp_configure.

Depois de fazer alguma mudana, emitido automaticamente um checkpoint, de
modo que as mudanas so imediatas.

Opes disponveis
A seguir, temos uma lista das opes mais comuns de banco de dados. Para maiores
detalhes em cada uma das opes, veja no Books Online.

As opes marcadas com um asterisco (*) indicam que essa opo pode ser
configurada pelo Enterprise Manager; caso contrrio, uma opo s altervel atravs de
procedimentos armazenados.

*ANSI null default
Controla se o valor padro para todos os tipos de dados NULL. A Microsoft pe o
padro em NOT NULL. Se esta opo estiver em TRUE, o padro ser NULL para o banco
de dados. Quando se entrar com o comando CREATE TABLE, a no ser que o criador
indique explicitamente NOT NULL, a regra se aplicar tambm criao da tabela.

ANSI Nulls
Quando em TRUE, as comparaes de NULL com qualquer valor vo retornar um
NULL. Quando em FALSE, apenas comparaes de valores no-Unicode retornaro TRUE
se e somente se ambos valores forem nulos. O padro para essa opo FALSE.

ANSI Warnings
Quando em TRUE, avisos de erro so exibidos, quando ocorrerem condies tais
como diviso por zero ou valores nulos aparecerem em funes de agregao. Por padro,
FALSE.

*autoclose
Quando em TRUE, o banco de dados fechado automaticamente quando o ltimo
usurio encerra a conexo. Isto muito til para ambientes pequenos, mas deve ser evitado
nos casos em que conexes so constantemente feitas e encerradas. A quantidade de carga
adicional gerada pela abertura e fechamento de um banco de dados podem ter efeitos
negativos em um ambiente de produo.

autoshrink
Quando em TRUE, o SQL Server periodicamente reduzir os arquivos do banco de
dados se necessrio.

*dbo use only
Quando em TRUE, apenas o dbo (proprietrio do banco de dados) tem acesso ao
banco de dados. Use esta opo quando estiver executando reparos em bancos de dados.

published
Utilizado para relicao, quando published estiver em TRUE, indica que a
publicao est habilitada. Colocar essa opo em FALSE desabilita a publicao.

*read only
Se TRUE indica que o banco de dados somente para leitura. FALSE permite
acesso para leitura/escrita.

*recursive triggers
Quando TRUE, permitido o disparo de gatilhos recursivos [recursive triggers].
Quando FALSE (o padro), gatilhos no podem disparar recursivamente. Um gatilho
recursivo aquele que dispara na tabela que o originou, causando uma atualizao em outra
tabela, a qual causa uma atualizao na tabela que originou o gatilho.

*select into / bulk copy
Permite que o banco de dados aceite aes no registradas em log, tais como
SELECT INTO e o utilitrio BCP fazem.

*single user
Permite que apenas um usurio acesse o banco de dados.

subscribed
Quando em TRUE, o banco de dados pode ser assinado para publicao.

*torn page detection
Se TRUE, o SQL Server detectar leituras incompletas em disco, e far com que
sejam marcadas. Quedas de energia ou outros defeitos podem causar essas leituras
incompletas.

Truncate log on Checkpoint (*trunc. Log on chkpt.)
Quando estiver em TRUE, o SQL Server trunca o log de transaes toda vez que
encontrar um checkpoint. Esta opo usada freqentemente para desenvolvimento,
fazendo com que o log de transaes no fique cheio com tanta freqncia. Voc no deve
utilizar esta opo em um sistema "real".

Definindo opes do banco de dados com sp_dboption
Para mudar as opes de um banco de dados com o procedimento armazenado
sp_dboption, faa o seguinte:

Sintaxe:
sp_dboption ['banco_de_dados'] [,'opo'] [,'valor']

Por exemplo:

sp_dboption 'pubs', 'read only', 'true'

Para ver o estado atual das opes do banco de dados pubs, entre com o seguinte
comando:

sp_dboption 'pubs'

Todas as opes que estiverem ativadas so listadas.

Definindo opes do banco de dados pelo Enterprise Manager
Quando se utiliza o Enterprise Manager para configurar as opes do banco de
dados, voc s tem acesso a um subconjunto (cerca de metade) das opes realmente
disponveis.

Para mudar opes do banco de dados com o Enterprise Manager, faa assim:
1. Expanda o grupo do servidor.
2. Expanda o servidor.
3. Expanda os bancos de dados.
4. Clique com o boto direito no banco de dados que voc quer mudar, e ento clique
em Propriedades [Porperties ].
5. Selecione as opes a mudar.
6. Clique em OK quando tiver acabado.

Verificando propriedades do banco de dados
A seguir voc v alguns procedimentos armazenados de sistema, freqentemente
utilizados, que exibem informaes sobre bancos de dados e opes de bancos de dados.
sp_dboption: como visto acima, mostra todas as opes disponveis para o banco
de dados em que se estiver posicionado.
sp_helpdb: informaes sobre todos bancos de dados em um servidor. Fornece
nome do banco de dados, tamanho, proprietrio, ID, data de criao, e opes.
sp_helpdb nome_banco_de_dados: informaes sobre um banco de dados
especfico apenas. Fornece nome do banco de dados, tamanho, proprietrio, ID, data
de criao, e opes. Alm disso, lista os arquivos para dados e log de transaes.
sp_spaceused [nome_objeto]: resumo do espao de armazenamento que um banco
de dados, log de transaes, ou objeto de banco de dados utiliza.

Consideraes para melhor gerenciamento
Para que voc possa trabalhar com mais tranqilidade e eficincia com bancos de
dados, considere os seguintes fatos.
Para obter melhor desempenho e segurana, armazene o banco de dados e o log de
transaes em discos fsicos separados.
Desabilite o cache de escrita nos controladores de disco, a menos que o mecanismo
de cache de escrita seja especificamente projetado para servidores de bancos de
dados.
Faa backup do banco de dados master imediatamente depois de criar ou modificar
bancos de dados. Em geral, uma boa idia fazer backup dos bancos de dados
regularmente.
Garanta que voc tenha espao suficiente para o log de transaes. Se voc ficar
sem espao, voc no ser capaz de modificar ou acessar seu banco de dados. Para
evitar ficar sem espao, faa o seguinte:
Aloque espao suficiente para acomodar o crescimento.
Monitore freqentemente o espao total sendo usado.
Use a opo de crescimento automtico para aumentar o espao em disco
automaticamente.
Configure um alerta para te avisar quando o espao disponvel no log de
transaes esteja abaixo de 25 por cento do espao total do log de
transaes.







Segurana

Conceitos
Criando logins do SQL Server
Criando usurios do banco de dados
Criando grupos de usurios
Definindo permisses
Objetivos:
- Conhecer os recursos do SQL Server para controle de acesso ao banco de dados;
- Aprender a criar logins de usurio e usurios do banco de dados.


Conceitos
Os recursos de segurana do SQL Server permitem determinar:
Quais usurios podem usar o SQL Server.
Quais usurios podem acessar cada banco de dados.
As permisses de acesso para cada objeto de banco de dados e para cada usurio.
As permisses de acesso para cada comando SQL em cada banco de dados, para
cada usurio.
Existem quatro barreiras para que os usurios possam acessar dados em um servidor SQL
Server:
O sistema operacional de rede; o usurio deve efetuar logon na rede.
A autenticao do SQL Server; o usurio deve ter uma conta no SQL Server.
A autenticao de banco de dados; o ID do usurio deve existir em uma tabela de
sistema do banco de dados (mais especificamente, a tabela sysusers)
A autenticao de objetos; o usurio deve ter permisses para acessar qualquer
objeto (tabelas, vises, entre outros).
Autenticao de usurios
Quando um usurio tenta acessar um servidor SQL Server, ele pode ser autenticado
de duas maneiras: pela Autenticao do Windows NT ou pela Autenticao do SQL Server.

No confunda isso com modo de segurana, que um tpico muito semelhante.
A autenticao do Windows NT se aproveita da segurana embutida no Windows NT
Server, a qual inclui caractersticas como senhas criptografadas, senhas que expiram,
tamanho mnimo de senhas, bloqueio de conta, e restrio de acesso com base em nomes de
computador.

O SQL Server pode confiar no Windows NT para autenticar logins, ou pode ele
mesmo autenticar os logins.


Quando o Windows NT autentica o login, o SQL Server processa o login assim:
Quando um usurio se conecta ao SQL Server, o cliente abre uma conexo
confivel com o SQL Server, na qual so passadas as contas de usurio e de grupo
do cliente para o SQL Server.
Uma conexo confivel [trusted connection] uma conexo de rede com o SQL
Server que consegue ser autenticada pelo Windows NT. Para ocorrer uma conexo
confivel, as bibliotecas de rede [net-libraries] Named Pipes ou Multiprotocol
devem estar sendo utilizadas tanto pelo cliente quanto pelo servidor SQL Server.
Caso a biblioteca de rede sendo utilizada pelo cliente ou pelo servidor no seja uma
dessas duas, a conexo de rede no-confivel e a autenticao do Windows NT
no pode ser utilizada.
Se o SQL Server encontra a conta de usurio ou de grupo na lista de contas de login
do SQL Server, na tabela de sistema syslogins, ele aceita a conexo.
O SQL Server no precisa de revalidar uma senha, j que o Windows NT j a
validou.
Nesse caso, a conta de login no SQL Server, do usurio, a conta de usurio ou de
grupo do Windows NT, a que tiver sido definida como a conta de login do SQL
Server.
Se vrios computadores com servidores SQL Server participam em um domnio ou
um grupo de domnios confiveis, basta efetuar logon em um nico domnio para ter
acesso a todos os servidores SQL Server.


Nota: O SQL Server no ir reconhecer grupos nem usurios que foram excludos e depois
recriados no Windows NT. Os grupos devem ser excludos do SQL Server e adicionados
novamente, pois o SQL Server usa o identificador de segurana (SID) do Windows NT
para identificar um grupo ou usurio. E um grupo ou usurio excludo e depois criado
novamente com o mesmo nome no Windows NT, ter um SID diferente.
Quando o SQL Server autentica o login, ocorre o seguinte:
Quando um usurio se conecta ao SQL Server com um nome de usurio e senha de
uma conta do SQL Server, o mesmo verifica que um login existe na tabela de
sistema syslogins e que a senha especificada igual a que se tem gravada.

Se o SQL Server no tem uma conta de login com esse nome de usurio ou a
senha no a que se tem gravada, autenticao falha e a conexo recusada.

Modos de segurana
Um modo de segurana se refere a como o DBA (administrador do banco de dados)
configura o SQL Server para autenticar usurios. Um servidor pode usar um de dois modos
de segurana: Windows NT e mista [mixed]. A diferena entre esses modos de segurana
como a segurana do SQL Server se integra com o Windows NT:

Modo de autenticao mista do SQL Server [SQL Server Mixed Authentication Security
Mode]: Nesse nidi de segurana, um usurio pode conectar-se ao SQL Server usando a
Autenticao do Windows NT, ou a Autenticao do SQL Server. Ao tentar conectar-se
com o SQL Server, verifica-se se voc est usando ou no uma conexo confivel. Ocorre
ento o seguinte:
Se voc estiver usando uma conexo confivel, o SQL Server tentar autenticar o
seu login do Windows NT, verificando se o seu nome de usurio tem permisso
para conectar-se ao servidor SQL Server. Caso seu nome de usurio no tenha
permisso para conectar-se ao SQL Server, lhe ser pedido um nome de login e
senha.
Caso voc no esteja usando uma conexo confivel, lhe ser logo pedido um login
e senha.
Seu login e senha so verificados na tabela de sistema syslogins. Se o nome de login
for vlido e a senha correta, voc poder conectar-se ao servidor SQL Server.

Quando o SQL Server lhe pede um login e senha, ele usa seu prprio cadastro de
usurios, independente do banco de dados de contas do Windows NT. Os logins de usurio
devem ser cadastrados no SQL Server.

Modo de autenticao de segurana do Windows NT [Windows NT Server Authtentication
Security Mode]: Se se opta por usar o modo de segurana do Windows NT, s o
mecanismo de autenticao do Windows NT utilizado para autenticar usurios para o
SQL Server. O nome de usurio que foi usado para se conectar rede NT o mesmo nome
usado para o SQL Server. Esse nome de usurio e a senha no precisam ser informados
novamente. Se o usurio for autorizado (ou seja, tiver um registro na tabela de sistema
syslogins) a conectar-se ao SQL Server, ento ele poder conectar-se. Nesse modo de
segurana, s possvel se conectar ao SQL Server atravs de uma conexo confivel. Se
esta opo for escolhida, deve-se ter certeza de que todos os clientes estejam rodando em
sistemas Windows, e que possam conectar-se ao SQL Server usando uma conexo
confivel.

Vantagens de cada um dos modos de segurana
Modo de segurana do
Windows NT
Modo de segurana mista
Recursos avanados de segurana
Clientes no-Windows e usando browser podem usar esse
modo para conectar-se.
Adicionar grupos como uma
conta.
Camada adicional de segurana sobre o Windows NT
Acesso rpido.

Definindo o modo de segurana
Para definir o modo de segurana, voc deve fazer o seguinte:
No Enterprise Manager, selecione o servidor cujo modo de segurana voc quer
definir.
Clique com o boto direito e selecione Properties.
Na tela que aparecer, selecione a guia Security.







Em Authentication, caso voc selecione "SQL Server and Windows NT", o modo
de segurana mista (mixed mode) estar sendo definido.
Caso voc selecione "Windows NT only", o modo de segurana do Windows NT
estar sendo definido.
Em qualquer dos casos, voc deve parar e reiniciar o servio MSSQL Server para
que a mudana tenha efeito. Para isso, voc pode usar, entre outras ferramentas, o
Service Manager.

Logins
Um login do SQL Server (ou login ID) um nome que identifica um usurio para o
SQL Server. Cada login tem uma senha, que deve ser informada no caso da segurana
mista (ver abaixo).

O SQL Server cria automaticamente um login chamado 'sa' (administrador do
sistema), que no deve ser excludo. O 'sa' tem permisso para fazer praticamente tudo no
banco de dados: criar bancos de dados, tabelas, criar outros logins etc. O sa pode conceder
permisses para outros usurios poderem fazer algumas tarefas.

Tambm criado automaticamente o login BUILTIN\Administrators. Esse login a
conta padro de login para todos os administradores do Windows NT. Esse login tem todos
os direitos no SQL Server e em todos os bancos de dados.

Nomes de usurio no banco de dados
Se voc possui um login, no quer dizer que tenha acesso a todos os bancos de
dados. preciso ter tambm um nome de usurio de banco de dados [database user ID],
que relacionado com o login e permite acesso a um banco de dados especfico. O nome de
usurio pode ser especfico do login.

O usurio que cria um banco de dados o dono do banco de dados [database
owner]. Dentro do banco de dados, o dono conhecido pelo nome especial 'dbo'. Outros
usurios podem ter nomes diferentes, geralmente de acordo com o seu login. O dono do
banco de dados pode conceder permisses para outros usurios de criar e excluir objetos
dentro do banco de dados.

O usurio que cria um objeto (tabela, viso, procedimento etc.) no banco de dados
o dono deste objeto. O dono tem inicialmente todas as permisses no objeto criado, mas ele
pode conceder essas permisses a outros usurios se desejar.

Um login pode ter um alias [apelido] dentro de um banco de dados, que o nome
de outro usurio. Nesse caso, dentro daquele banco de dados, ele funciona como se fosse
aquele usurio e tem as mesmas permisses dele. Vrios usurios (logins) diferentes podem
ter o mesmo alias. Esse um recurso que existe no SQL Server 7.0, apenas para
compatibilidade com verses anteriores, j que atravs de papis [roles] e da atribuio de
permisses aos papis, o que era feito usando aliases, pode ser feito de maneira muito mais
eficaz.

O usurio guest [convidado] um nome especial que existe em todo banco de dados
e permite a qualquer login usar o banco de dados, mesmo que no tenha um nome de
usurio relacionado.

Papis [Roles]
Na sua essncia, um papel [role] um grupo de usurios que tm necessidades
semelhantes de acesso ao SQL Server. Mas, os papis so um pouco mais complexos do
que isso. Por exemplo, h uma poro de tipos diferentes de papis do SQL Server,
incluindo os seguintes:
Papis predefinidos de servidor [Predefined server roles]
Papis predefinidos de bancos de dados [Predefined database roles]
O papel pblico [Public role]
Papis personalizados de bancos de dados [Custom database roles]

Papis de aplicao so um tipo especial de papis que so atribudos a uma aplicao
especfica que foi projetada para acessar os dados do SQL Server. Por exemplo, se um
usurio precisa de acessar um tipo especfico de dados, ao invs de atribuir permisso
explcita ao usurio para acessar os dados, o acesso aos dados dado ao usurio utilizando
a aplicao qual foi atribudo um papel de aplicao. Isso significa que um usurio apenas
ter acesso aos dados usando essa aplicao especfica. Papis de aplicao so atribudos a
aplicaes, no a usurios.

Papis predefinidos de servidor [Predefined Server Roles]
Em verses anteriores do SQL Server era difcil delegar reas administrativas a
outras pessoas. Por exemplo, voc poderia querer se designar como o DBA senior, com a
habilidade de executar qualquer tarefa no SQL Server, que precisasse ser executada. Alm
disso, voc poderia querer delegar algumas das tarefas administrativas para outros, e ao
mesmo tempo restringir exatamente o que eles poderiam fazer. Embora isso fosse possvel
em verses anteriores do SQL Server, era difcil de implementar. O SQL Server 7.0
solucionou esse problema incluindo o que so chamados de papis predefinidos de servidor
(tambm conhecidos como papis fixos de servidor).

O SQL Server inclui um total de sete diferentes papis predefinidos de servidor,
cada um com um conjunto de permisses administrativas diferentes. Isso te permite definir
vrios ajudantes administrativos, com diferentes nveis de capacidade, para ajud-lo a
administrar o SQL Server. Tudo que voc precisa fazer adicionar o login dos mesmos ao
papel desejado. Todos os papis de servidor so predefinidos pelo SQL Server. Voc no
pode criar seus prprios papis de servidor.

Os papis predefinidos de servidor so definidos ao nvel do servidor SQL Server, no
ao nvel de banco de dados. Isso significa que qualquer um que pertena a um desse papis
predefinidos de servidor tem permisses especficas para gerenciar os servidore SQL
Server e todos os bancos de dados gerenciados pelo SQL Server. As tarefas administrativas
que cada login pode executar dependem apenas de qual papel predefinido de servidor a que
ele pertena. Os papis predefinidos de servidor so:
Administradores de sistema [System Administrators] (sysadmin): Este o mais
poderoso de todos os papis. Qualquer um que pertena a esse papel pode realizar
qualquer tarefa no SQL Server, inclusive sobrepor-se a qualquer dos outros papis
predefinidos de servidor. Esse papel o equivalente conta SA em verses
anteriores do SQL Server (a conta SA, por padro faz parte desse grupo).
Criadores de bancos de dados [Database Creators] (dbcreator): Eles tm a
habilidade de criar e alterar bancos de dados individuais.
Administradores de discos [Disk Administrators] (diskadmin): Tm a capacidade de
gerenciar arquivos de disco.
Administradores de processos [Process Administrators] (processadmin): Tm a
capacidade de gerenciar os vrios processos sendo executados no SQL Server.
Administradores de segurana [Security Administrators] (securityadmin): Eles tm
a capacidade de gerenciar logins para um servidor.
Administradores de servidor [Sever Administrators] (serveradmin): Tm a
capacidade de realizar configuraes a nvel de servidor.
Administradores de configurao [Setup Administrators] (setupadmin): Tm a
capacidade de instalar a replicao no SQL Server, e gerenciar procedimentos
armazenados.


Geralmente, voc no precisar de todos esses papis quando for delegar tarefas
administrativas do SQL Server para ajudantes. Em muitos casos, voc provavelmente s
atribuir seus ajudantes a um ou dois papis, dando-lhes as permisses especficas que eles
precisam para executar as tarefas que voc delegou a eles. Os usurios podem pertencer a
mais de um papel ao mesmo tempo.


Papis predefinidos de bancos de dados [Predefined Database Roles]
Sob vrios aspectos, os papis predefinidos de bancos de dados so semelhantes aos
papis predefinidos de servidor. Papis predefinidos de bancos de dados atribuem tipos
especficos de permisses a para cada um dos nove papis predefinidos. A principal
diferena entre papis predefinidos de servidor e papis predefinidos de bancos de dados
que os papis predefinidos de bancos de dados so especficos para cada banco de dados e
no se estendem a vrios bancos de dados. Como os papis predefinidos de servidor, os
papis predefinidos de bancos de dados podem ser usados por voc para ajud-lo a
distribuir as tarefas administrativas do SQL Server para outros. Os papis predefinidos de
bancos de dados so:
Proprietrio do banco de dados [Database Owner] (db_owner): Eles tm permisses
de propriedades em um banco de dados e podem executar qualquer tarefa de
configurao ou manuteno em um banco de dados particular. Eles tambm podem
executar todas as atividades dos outros papis de bancos de dados, e sobrepor-se a
qualquer dos outros papis. Em verses anteriores do SQL Server, esse papel
muito semelhante ao ID de usurio de banco de dados DBO. (a conta DBO faz parte
desse papel em todos os bancos de dados).
Administrador de acesso do banco de dados [Database Access Administrator]
(db_accessadmin): Tm a capacidade de gerenciar IDs de usurio de banco de dados
para um banco de dados.
Leitor de dados do banco de dados [Database Data Reader] (db_datareader): Tm a
capacidade de ver quaisquer dados de todas as tabelas em um banco de dados.
Escritor de dados do banco de dados [Database Data Writer] (db_datawriter): Tm a
habilidade de inserir, modificar ou excluir quaisquer dados de todas as tabelas em
um banco de dados.
Administrador da linguagem de definio de dados [Database Data Definition
Language Administrator] (db_ddladmin): Podem criar, modificar, ou excluir
quaisquer objetos de um banco de dados (tabelas, vises, procedimentos
armazenados...).
Operador de backup do banco de dados [Database Backup Operator]
(db_dumpoperator): Podem realizar backups do banco de dados.
Negao de leitura no banco de dados Database Deny Data Reader
(db_denydatareader): Um papel especial que permite a seus membros mudar o
esquema do banco de dados, mas sem poder ver os dados no banco de dados.
Negao de escrita no banco de dados [Database Deny Data Writer]
(db_denydatawriter): Um papel especial que evita que seus membros alterem
qualquer dado em um banco de dados.

Como o DBA, voc provavelmente no usar a maioria desses papis predefinidos de
bancos de dados. provvel que voc precise de apenas alguns de modo a delegar algumas
de suas tarefas administrativas para seus ajudantes. E como com os papis predefinidos d
servidor, usurios podem pertencer a mais de um papel ao mesmo tempo.


O papel pblico [Public Role]
O papel pblico semelhante ao grupo pblico que era usado em verses anteriores
do SQL Sever. Quando criado, todo banco de dados tem o papel pblico por padro, assim
como todo banco de dados tem papis predefinidos de banco de dados. O que nico nesse
papel que todos IDs de usurio em um banco de dados automaticamente pertencem a este
papel. Sob vrios aspectos, ele semelhante ao grupo Todos [Everyone] do Windows NT
Server. Voc no pode adicionar ou remover usurios deste papel, ou modific-lo de
qualquer maneira. Tudo que pode ser feito atribuir permisses a ele. Quaisquer
permisses atribudas ao papel pblico so automaticamente atribudas a todos IDs de
usurio no banco de dados. O papel pblico especialmente til se voc quiser atribuir as
mesmas permisses para todos os usurios de banco de dados em um banco de dados, ao
mesmo tempo.

Papis personalizados de banco de dados [Custom Database Roles]
Como uma regra geral, voc ir querer se aproveitar do mximo de papis
predefinidos possvel. Mas voc pode encontrar situaes onde nenhum dos grupos
predefinidos vai de encontro s suas necessidades. Se esse for o caso, o SQL Server permite
que voc crie seus prprios papis de banco de dados.

Se voc estiver utilizando a autenticao do Windows NT e usa grupos globais do
NT Server para gerenciar usurios, voc perceber que voc no precisa realmente de criar
papis personalizados de banco de dados, j que voc obtm o mesmo efeito com o uso de
grupos globais ao invs de agrupar usurios semelhantes. Mas se voc no for um
administrador do NT Server e no tiver permisso para criar os grupos globais que voc
precisa, ou se voc estiver utilizando a autenticao do SQL Server, voc pode no ter outra
escolha, a no ser criar os papis personalizados de bancos de dados para ajud-lo a
gerenciar melhor seus usurios.




Quando for criar papis personalizados de banco de dados, tenha o seguinte em mente:
Papis personalizados de banco de dados, como ocorre com qualquer papel do SQL
Server, so utilizados para agrupar usurios semelhantes que precisam do mesmo
conjunto de permisses para acessar o SQL Server.
Papis personalizados de bancos de dados so criados dentro de um banco de dados
e no podem se estender a vrios bancos de dados.
Usurios podem pertencer a mais de um papel, seja personalizado ou predefinido.
Papis personalizados podem incluir usurios do NT Server, grupos globais do NT
Server, IDs de usurios de bancos de dados do SQL Server, e outros papis do SQL
Server.

Nota: Se voc tiver permisso para a criao de grupos globais e utilizar a autenticao do
Windows NT, voc deve sempre usar grupos globais ao invs de papis personalizados de
banco de dados. O uso de grupos globais ao invs de papis personalizados de banco de
dados geralmente reduz o tempo necessrio para gerenciar as contas de usurio do SQL
Server e do NT Server, pois grupos globais funcionam com ambos. Papis personalizados
de banco de dados funcionam apenas no SQL Server. Alm disso, grupos globais podem se
estender a vrios bancos de dados, enquanto papis so especficos para cada banco de
dados, o que os torna menos flexveis que grupos globais.


Criando e configurando papis de banco de dados
Veremos agora como criar um papel personalizado de banco de dados. Para isso, n o
Enterprise Manager, expanda o banco de dados para o qual voc quer criar o papel. Clique
em Roles com o boto direito e selecione New Database Role. Aparece a caixa de dilogo
de criao de papis de banco de dados.


Na caixa "Name" digite o nome do papel de banco de dados que voc quer criar.
Depois, voc deve informar se voc est criando um papel padro [Standard Role] ou um
papel de aplicao [Application Role]. Se voc escolher criar um papel padro, voc tem a
opo de adicionar um ou mais IDs de usurios de banco de dados ao papel agora (clicando
em Add...). Ou ento, voc pode pular este passo agora e adicionar IDs de usurios de
banco de dados posteriormente, usando as tcnicas mostradas em Gerenciando usurios . Se
voc escolher papel de aplicao, voc tambm dever informar uma senha.
Depois de terminar de informar o que foi pedido, clique em Ok para criar o novo papel de
banco de dados. Isso fechar a caixa de dilogo acima e ento o novo papel ser mostrado
no Enterprise Manager.

Nota: Lembre-se que papis de banco de dados so criados para cada banco de dados. Eles
no so compartilhados entre bancos de dados.

Excluindo um papel de banco de dados
Como parte da sua responsabilidade cotidiana de manter o SQL Server, voc achar
necessrio s vezes remover IDs de usurio de bancos de dados e, com menor freqncia,
remover papis de banco de dados que no sejam mais necessrios. A remoo de IDs de
usurio de banco de dados ser vista em Como excluir um ID de um usurio de banco de
dados).

Os nicos papis de banco de dados que podem ser removidos so aqueles que
foram criados por voc ou por outro DBA. No possvel remover papis predefinidos de
banco de dados. Se um papel de banco de dados tem um ou mais IDs de usurio de banco
de dados associado a ele, voc deve remov-los do papel antes de tentar excluir o papel. Se
voc tentar excluir um papel sem antes remover os IDs de usurios a ele associados, voc
ver uma mensagem de erro.

Para excluir um papel de banco de dados, faa o seguinte:
7. No Enterprise Manager, expanda o banco de dados em que est definido o papel que
voc quer excluir.
8. Clique em Roles e, no lado direito da tela, selecione o papel a ser excludo. D um
duplo clique no mesmo, e verifique se em baixo de User, h algum usurio listado.
9. Caso haja algum usurio, remova-o selecionando-o e clicando no boto Remove.
10. Feito isso, clique em Ok, selecione o papel a ser excludo, clique no mesmo com o
boto direito e selecione Delete.
11. Lhe ser perguntado se voc de fato quer excluir o papel. Confirme, clicando em
Yes.

Caso voc saiba de antemo que no h usurios associados a esse papel, v direto para o
passo 4.

Configurando um papel de servidor
Como j foi visto, papis de servidor so usados para atribuir aos logins vrios
nveis de privilgios administrativos no SQL Server. Voc pode atribuir um login a um
papel de servidor quando voc cria um login (como visto em Gerenciando usurios), ou
voc pode fazer como ser descrito aqui.

Os papis de servidor vm embutidos no SQL Server. Novos papis de servidor no
podem ser criados nem os existentes podem ser deletados. Sua nica opo ao configurar
um papel de servidor adicionar ou remover logins do papel de servidor em questo.




Para adicionar ou remover um login de um papel de servidor, faa o seguinte:
No Enterprise Manager, selecione o servidor SQL Server cujos papis voc quer
configurar. Expanda-o e abra a pasta Security.
Clique em Server Roles. No lado direito da tela aparecem os papis de servidor.
Selecione o papel ao qual voc quer adicionar algum login.
Clique no mesmo com o boto direito e selecione Properties. Aparece a janela
abaixo:

Para adicionar um login ao papel de servidor, clique no boto Add. Aparece a caixa
de dilogo "Adicionar Membros" [Add Mebers], com todos os logins definidos para
o servidor.
Escolha um ou mais logins para adicionar a esse papel de servidor. Cada vez que
voc selecionar um login, ele ficar marcado, e assim ficar at que voc o clique de
novo. Depois de selecionados todos os logins que voc quer adicionados ao papel
de servidor, clique em Ok. Ento voc volta para a caixa de dilogo de propriedades
do papel de servidor (mostrada acima).
Caso voc queira remover algum login que faz parte de um papel de servidor,
selecione-o, na caixa de dilogo de propriedades do papel de servidor, e clique no
boto Remove.
Quando voc tiver adicionado e/ou removido todos os logins desejados a esse papel
de servidor, clique em Ok para concluir.


Voc pode adicionar logins aos papis de servidor sempre que achar necessrio. Mas
lembre-se que o ato de delegar privilgios administrativos a usurios s vezes pode ser
arriscado, e voc no ir querer dar privilgios demais para usurios. Apenas d aos logins
os privilgios absolutamente mnimos que eles precisam para completar as tarefas que voc
os atribuiu.

Visualizando informaes de segurana
Visualizando informaes de logins do SQL Server
No Enterprise Manager, expanda o servidor cujas contas voc quer obter
informaes, clique na pasta Security, e ento em logins. Aparece uma tela semelhante
mostrada abaixo:

Observe na parte direita da tela estas informaes:
A coluna "Name" mostra cada login existente. Se algum login tiver um nome de
domnio antes do nome do login, como acima em "MARTINS\Sqlexecutivo",
significa que a conta usa a autenticao do Windows NT. Os que no so
precedidos por um nome de domnio usam a autenticao do SQL Server, como "a"
e "sa" na figura acima.
A coluna "Type" d mais informaes sobre o login. Se o tipo "NT User", a conta
foi o NT Server e adicionada como um login do SQL Server. Se o tipo "NT
Group", isso significa que qualquer usurio que faa parte desse grupo do Windows
NT pode acessar o SQL Server utilizando sua conta de grupo como login. Se o tipo
"Standard", esse login foi criado usando com o Enterprise Manager.
A coluna "Default Database" mostra qual banco de dados cada usurio usa como
seu banco de dados padro. o banco de dados no qual eles so automaticamente
logados quando eles acessam o SQL Server pela primeira vez.
A coluna "User" mostra o nome de usurio que este usurio recebeu no banco de
dados padro (o que ele automaticamente logado da primeira vez que efetua logon
no SQL Server.
A coluna "Default Language" mostra a lngua especfica para o login. O padro
ingls [English].
Para ver informaes especficas sobre qualquer um dos logins, clique no mesmo com o
boto direito, e selecione Properties. Aparece a tela abaixo:


Aqui voc pode ver e configurar quase todas opes de login. Essa tela tem trs guias.

Na guia General, voc pode alterar a senha para esse login [Password], e definir seu
banco de dados e linguagem padro ([Database] e [Language]).

Na guia "Server Roles" mostra a quais papis de servidor o login pertence. A guia
"Database Access" mostra a quais bancos de dados o login tem acesso (ou seja, tem um
login definido na tabela syslogins do banco de dados), alm de mostrar a quais papis de
banco de dados o usurio pertence, em cada banco de dados.

Clique em Cancel para sair da jabela de propriedades do login.


Visualizando informaes de IDs de usurio do banco de dados
Alm de ver as informaes de cada um dos logins definidos para o SQL Server,
tambm possvel ver as informaes dos IDs de usurio definidos para cada banco de
dados.

Para isso, no Enterprise Manager, selecione o banco de dados cujas informaes de
IDs de usurio voc quer ver, expanda-o e clique em Users.




Note que no lado direito da tela aparecem algumas informaes sobre os IDs definidos
para o banco de dados:
A coluna Name mostra o ID de usurio que foi adicionado a este banco de dados,
indicando quem tem a capacidade de acessar este banco de dados.
A coluna "Login Name" mostra qual login est associado com os IDs de usurio
definidos para esse banco de dados.
A coluna "Database Acces" indica o tipo de acesso que o ID de usurio tem a esse
banco de dados.

Selecione, do lado direito da tela, o login cujas informaes voc deseja ver, clique no
mesmo com o boto direito e selecione Properties.

Essa tela mostra todos os papis de banco de dados definidos para este banco de dados
(todos que aparecem listados) e tambm a quais deles este usurio especfico pertence (os
que tm a caixa de verificao ao seu lado marcada).

Para sair desta janela, clique em Cancel.

Visualizando informaes de papis de bancos de dados.
Embora voc possa ver informaes sobre papis de bancos de dados com a tcnica
descrita acima, tambm pode ver-se atravs da perspectiva dos papis de bancos de dados,
ao invs do usurio de banco de dados.

Para isso, no Enterprise Manager, expanda o banco de dados de cujos papis voc
quer obter informaes, clique em Roles.

Na coluna "Name"voc v uma lista de todos os papis para esse banco de dados
particular. Na coluna "Role Type" v-se as palavras "Standard" ou "Application". Standard
significa que um papel normal de banco de dados, ebquanto Application significa que
esse papel um papel de aplicao de banco de dados.

Caso voc queira obter mais informaes sobre qualquer dos papis, clique no
mesmo com o boto direito e selecione Properties.


Essa caixa de dilogo lista os usurios do banco de dados que fazem parte deste
papel em particular.

Para sair dessa caixa de dilogo, clique em Cancel.

bem provvel que voc ache mais fcil ver estas informaes atravs das
informaes de login, como descrito anteriormente.

Visualizando informaes de papis de servidor
Muitas vezes, voc ir querer ver os vrios papis de servidor de seu SQL Server e
determinar quais logins pertencem a quais papis de servidor.


No Enterprise Manager, selecione o servidor cujos papis voc quer gerenciar, e
expanda-o. Expanda a pasta Security e selecione Server Roles.


O nome completo do papel de servidor mostrado na coluna "Full Name", e o seu
nome curto em "Name". A coluna "Description" descreve o que o papel de servidor pode
fazer.

Para descobrir quais logins pertencem a cada um dos papis de servidor, clique com
o boto direito no papel de servidor, e selecione Porperties. Aparece a caixa de dilogo de
"Propriedades do papel de servidor".



Essa caixa de dilogo tem duas guias: a guia "General", que te diz quais logins
foram atribudos a esse papel particular. A guia "Permissions" te mostra as vrias
permisses que esse papel recebeu.

Clique em Cancel para sair dessa janela.

Nota: Esse o nico local onde se pode ver informaes sobre papis de servidor.


Permisses
At agora, j vimos como criar e gerenciar logins que so usados para controlar o
acesso ao SQL Server. Vimos tambm como criar e gerenciar IDs de usurios de bancos de
dados, os quais so usados para controlar o acesso a bancos de dados individualmente. Mas,
mesmo que um usurio tenha um login e um ID de usurio vlido, ele no pode acessar
qualquer dado em um banco de dados sem que lhe tenham sido dadas permisses explcitas
para acessar os objetos armazenados no banco de dados.

Permisses so usadas no SQL Server para especificar quais usurios podem ter
acesso a quais objetos de bancos de dados, e o que eles podem fazer com tais objetos. Se
um usurio no receber explicitamente a permisso para acessar um objeto, ele no ter
acesso ao mesmo. Permisses podem ser atribudas a usurios (contas do NT Server ou do
SQL Server), grupos (grupos globais do NT Server), e papis (papis predefinidos de
servidor, de banco de dados e papis personalizados de bancos de dados). mais fcil
atribuir permisses a grupos e papis do que a usurios individuais (a quantidade de
trabalho braal exigida menor).



O SQL Server apresenta trs nveis de permisses:
Permisses para comandos SQL: habilitam usurios a executar comandos SQL
especficos que so usados para criar objetos de bancos de dados, fazer backup de
bancos de dados e logs de transao.
Permisses de objetos: determinam o que um usurio pode fazer a um objeto
preexistente.
Permisses implcitas: so permisses que s podem ser executadas por membros
de papis predefinidos de servidor e de banco de dados, ou pelos proprietrios do
banco de dados.

Atribuem-se permisses aos usurios baseado no que eles precisam de fazer com os
dados armazenados no SQL Server. Alguns usurios podem precisar apenas de visualizar
dados, outros podem precisar de consultar dados e gerar relatrios, outros podem precisar
de alterar dados, etc. Uma das principais responsabilidades do DBA determinar quais
usurios precisam de acessar quais objetos, e quais permisses eles precisam.

Permisses atribudas em um banco de dados so independentes de permisses
atribudas a outro banco de dados. Se um usurio precisar de acessar tabelas em dois bancos
de dados, o usurio deve ter IDs de usurio nos dois bancos de dados, e as permisses
necessrias atribudas em cada banco de dados, para acesso aos objetos que ele precisa
acessar.

Permisses para comandos SQL
Permisses para comandos SQL so dadas a usurios que precisam de criar um banco
de dados ou objetos de bancos de dados, ou que precisam fazer backup de bancos de dados
e seus logs de transaes. Quando voc atribui permisses para comandos SQL voc na
verdade est dando quele usurio especfico a capacidade de executar comandos SQL
especficos. Esses comandos so os seguintes:
CREATE DATABASE: capacita o usurio a criar bancos de dados em um servidor
SQL Server especfico.
CREATE DEFAULT: o usurio pode criar um valor padro que automaticamente
inserido em uma coluna de alguma tabela sempre que a coluna for deixada em
branco quando um novo valor acrescentado a ela.
CREATE PROCEDURE: permite a criao de procedimentos armazenados.
CREATE RULE: permite a criao de uma regra que utilizada para validar dados
que so informados em uma coluna sempre que uma nova linha adicionada
tabela.
CREATE TABLE: permite a criao de uma nova tabela dentro de um banco de
dados
CREATE VIEW: permite a criao de tabelas virtuais, que so usadas para mostrar
um subconjunto de uma tabela, ou para juntar duas ou mais tabelas em uma nica
tabela virtual.
DUMP DATABASE: permite fazer backup de um banco de dados.
DUMP TRANSACTION: permite fazer backup do log de transaes de um banco
de dados.

As tarefas descritas acima podem ser realizadas diretamente atravs de comandos SQL,
ou usando o Enterprise Manager. Voc pode atribuir a um usurio uma nica permisso por
vez, todas elas, ou um conjunto das permisses de comando disponveis.

Na realidade, raramente sero usadas as permisses para comandos SQL, pois o SQL
Server j inclui papis que cumprem as mesmas funes que a atribuio dessas
permisses. Por exemplo, o papel predefinido de servidor Sysadmin consegue reaIizar
qualquer tarefa que possa ter sido atribuda a um usurio atravs de permisses para
comandos SQL. Assim como o papel predefinido de banco de dados db_backupoperator
pode fazer os backups de um banco de dados da mesma maneira que quem recebeu a
permisso DUMP DATABASE. O mais prtico atribuir os usurios a papis de servidor
ou de banco de dados que lhe permitam fazer as tarefas que forem necessrias.

Permisses de objetos
O tipo mais comum de permisso atribudo a usurios, grupos e papis a permisso de
objetos. Essas permisses determinam quem pode acessar um objeto preexistente e o que
esse usurio pode fazer com tal objeto. Quando voc atribui a um usurio uma permisso de
objeto, voc na verdade est dando a tal usurio a capacidade de executar certos comandos
SQL sobre objetos em um banco de dados. Essas permisses so as seguintes:
DELETE: permite excluir uma tabela ou viso em um banco de dados.
EXECUTE: premite a execuo de um procedimento armazenado.
INSERT: permite adicionar-se uma nova linha em uma tabela, ou em uma tabela
atravs de uma viso.
REFERENCES: (DRI) permite ligar duas tabelas usando uma coluna comum.
SELECT: permite pesquisar e visualizar dados de uma viso, tabela ou coluna.
UPDATE: permite modificar dados em uma tabela, coluna de uma tabela, ou em
uma tabela atravs de uma viso.

As tarefas relacionadas a objetos citadas acima podem ser executadas com o Enterprise
Manager, ou pelo uso de comandos SQL, ou indiretamente atravs do uso de qualquer
aplicao "front-end" de cliente que use comandos SQL para acessar dados do SQL Server
em um servidor. Independente de como um usurio acessa objetos em um banco de dados,
cada usurio deve receber explicitamente permisses, em cada objeto, para realizar o
acesso.

Permisses implcitas
Uma permisso implcita uma permisso que um usurio obtm apenas pelo fato
de pertencer a um papel predefinido de banco de dados ou de servidor, ou por ser o
proprietrio de um objeto de banco de dados. Permisses implcitas no podem ser
atribudas a usurios. Ao invs disso, um usurio que precise de uma permisso implcita
deve ser adicionado a um papel predefinido que j tenha tal permisso. Permisses
implcitas podem assim ser atribudas a usurios, papis personalizados ou grupos, com a
simples atribuio dos mesmos a um papel predefinido de banco de dados ou de servidor.
As permisses implcitas tambm podem ser atribudas a usurios, grupos ou papis
personalizados definindo quaisquer destes como o proprietrio de um objeto de banco de
dados especfico.

Os usurios, grupos ou papis personalizados podem ser atribudos a qualquer um
dos Papis predefinidos de Servidor ou Papis predefinidos de Banco de Dados,
recebendo as permisses que tal papel tenha. (relembre quais so os Papis predefinidos de
Servidor e Papis predefinidos de Banco de Dados)

Alm de receberem permisses atravs da atribuio aos papis acima, tambm
podemos fazer usurios tornarem-se proprietrios de algum objeto. Como funciona isso?
Quando um usurio com a permisso de comando adequada cria um novo objeto no banco
de dados, tal como uma tabela, ele se torna o proprietrio do objeto de banco de dados
[Database object owner] (DBOO) daquele objeto. Proprietrios de objetos de banco de
addos tm permisses implcitas em todos os objetos que lhes pertenam, o que os d a
capacidade de executar qualquer atividade naquele objeto, tal como SELECT, INSERT,
UPDATE, DELETE, entre outros. Eles tm controle completo dos objetos que criam.
Como d para perceber, permitir que qualquer um seja um DBOO no uma boa idia.
Normalmente, as nicas pessoas que devem criar objetos de bancos de dados so DBAs ou
desenvolvedores SQL, no usurios comuns.

Precedncia de permisses
Cinco nveis de permisses podem ser atribudas a um usurio, conforme segue:
Permisses individuais
Permisses de grupos globais do NT Server
Permisses de papis predefinidos de servidor
Permisses de papis predefinidos de bancos de dados
Permisses de papis personalizados de bancos de dados.

As permisses podem ser dos tipos: implcita, de comandos ou de objetos.

O que ocorre se um usurio receber permisses diferentes atravs de vrias permisses
individuais, vrios grupos ou papis de que o mesmo faa parte?

A priori, as permisses somam-se, ou seja: as permisses que um usurio tenha
como membro de um grupo somam-se s permisses que ele tiver como usurio individual
e assim por diante. Mas h uma exceo! A permisso "negar acesso" [deny access]
sobrepe-se a qualquer outra permisso para o objeto em questo. Quer dizer que se um
usurio tiver obtido permisso para visualizar dados de uma tabela, atravs da permisso de
comando SELECT para a tabela, e o mesmo usurio fizer parte de um grupo global que tem
a permisso de "acesso negado" tabela em questo, sua permisso efetiva ser a de
"acesso negado", ou seja, no lhe ser permitido acessar tal banco de dados.

Apesar de termos exemplificado aqui citando uma tabela, essa regra vlida para
qualquer objeto de banco de dados.

Visualizando informaes de permisses
Antes que voc aprenda a conceder e revogar permisses para usurios, grupos ou
papis, importante que voc saiba como visualizar permisses tanto de objetos como de
comandos. Isso no apenas te ajudar a trabalhar com permisses, mas tambm te mostrar
como executar uma tarefa que voc estar realizando regularmente como um DBA. Vamos
ver como visualizar as permisses atuais de objeto para todos os usurios, grupos, e papis
em um nico banco de dados utilizando o Enterprise Manager. Lembre-se que permisses
so gerenciadas para cada banco de dados, e que voc deve realizar estes passos em cad
banco de dados no qual voc queira ver as permisses.

Visualizando permisses para comandos SQL
No Enterprise Manager, usando uma conta com privilgios de sysadmin, expanda o
banco de dados cujas permisses de comando voc quer visualizar. Clique no mesmo com
o boto direito e em Properties. Aparece a caixa de dilogo de Propriedades do banco de
dados:

Agora, clique na guia Permissions. mostrada a tela de permisses para comandos
SQL

Na primeira coluna desta tela, embaixo do ttulo User/Role, esto listados toos os
IDs de usurios de bancos de dados para esse banco de dados. Lembre-se que essa coluna
pode exibir quaisquer grupos, papis ou usurios. Nas outras colunas esto as vrias
permisses para comandos SQL que podem ser atribudas. Note que esta tela no exibe
todas as permisses de uma vez; voc deve percorr-la para a direita para poder v-las
todas. Depois de ver todas as permisses que podem ser atribudas, saia desta tela clicando
em Cancel. Isso te leva de volta tela do Enterprise Manager.

Visualizando permisses de objetos
A visualizao de permisses de objetos m pouco mais difcil do que a
visualizao de permisses para comandos SQL. Voc pode v-las da perspectiva de
usurios, grupos, ou papis, ou ento da perspectiva dos prprios objetos. Analisaremos
aqui as duas maneiras.

Sob a perspectiva do usurio, grupo ou papel, as permisses so visualizadas desta
forma:
12. No Enterprise Manager, expanda o banco de dados cujas permisses de objetos voc
quer visualizar.
13. O prximo passo depende se voc quer ver permisses de objetos para grupos e
usurios, ou para papis personalizados.
Caso voc queira ver as permisses de objetos para grupos e usurios,
selecione Users no banco de dados em questo; todos os usurios e grupos
aparecem do lado direito da tela.
Para ver informaes de permisses de objetos atribudas a papis
personalizados, selecione Roles no banco de dados em questo; todos os
papis, predefinidos e personalizados so mostrados no lado direito da tela.
14. Agora, no lado direito da tela, clique com o boto direito em um usurio, grupo ou
papel personalizado, cujas permisses de objetos voc quer visualizar,e ento
selecione Properties. Aparece ento a janela de propriedades do usurio ou do papel
(dependendo do que voc selecionou no passo 2).

15. Clique no boto Permissions para ver as permisses a nvel de objeto que esse
usurio (ou papel) tem.

Veja que h dois botes no topo da tela. Quando o primeiro [List all objects] est
selecionado, todos os objetos pertencentes ao banco de dados so exibidos na tela. Se a
segunda opo [List only objects with permissions for this user] for selecionada, apenas
aqueles objetos para os quais o usurio tm permisso so listados.

Na primeira coluna h um cone que representa o objeto de banco de dados. A segunda
coluna, lhe mostra o nome do objeto. A coluna Owner mostra quem o proprietrio do
objeto. As outras colunas mostram as permisses de objetos disponveis. Se alguma coluna
estiver marcada (com sua caixa de verificao ativada), isso indica que esse usurio possui
aquela permisso para o objeto em questo.

Perceba que nem todos os objetos tm todas as permisses de objeto disponveis. Por
exemplo, procedimentos armazenados tm apenas a permisso de objeto Execute.
16. Para terminar de visualizar as permisses de objeto, saia da tela clicando em
Cancel. Clique de novo em Cancel e voc estar de volta ao Enterprise Manager.


Sob a perspectiva dos objetos individuais de banco de dados, visualizam-se assim
as permisses:
1. No Enterprise Manager, expanda o banco de dados cujas permisses de objeto voc
quer verificar. Aparecem todos os tipos de objetos de bancos de dados.
2. Agora voc deve decidir quais permisses de objetos voc quer visualizar. Voc
pode escolher: tabelas [tables], vises [views], procedimentos armazenados [stored
procedures], regras [rules], defaults [defaults], e tipos de dados definidos pelo
usurio [user defined data types]. Clique no tipo de objeto ^cujas permisses voc
quer visualizar. Aparecem no lado direito da tela todos os objetos desse tipo.
3. Clique com o boto direito em um dos objetos, e em Properties. Aparece a caixa de
dilogo de propriedades do objeto que voc selecionou (no caso uma tabela)

4. Para exibir as permisses para esse objeto, clique no boto Permissions. Aparece a
tela de permisses do objeto, como abaixo:

Note as duas opes na parte superior da tela. Por padro, a primeira [List all users /
user-defined DB roles / public] est selecionada. Assim, todos usurios, grupos e papis
para esse banco de dados so exibidos na tela. Se a segunda opo [List only users / user-
defined DB roles / public permissions on this object], apenas os usurios, grupos ou papis
que tenham permisses definidas para esse objeto sero exibidos.

A primeira coluna mostra um cone. Uma nica cabea indica um usurio ou um grupo.
Duas cabeas indicam um papel. Todos os usurios, grupos ou papis para esse banco de
dados esto embaixo de "User/DB Role". As colunas restantes indicam as permisses de
objeto disponveis para este objeto. Se a caixa de verificao estiver selecionada (ativa),
indica que um usurio, grupo ou papel obteve a permisso de objeto associada. Veja que
nem todos os objetos tm todas as permisses de objeto.
5. Depois de terminar de visualizar as permisses de objeto, voc pode sair clicando
em Cancel duas vezes, primeiro para a tela de permisses, e depois para a caixa de
dilogo de propriedades. Ento voc volta para a tela principal do Enterprise
Manager.

Concedendo e revogando permisses para comandos SQL pelo Enterprise
Manager
A concesso e revogao de permisses usa as mesmas telas que acabamos de ver.

Mas agora, atriburemos e revogaremos permisses de grupos, usurios, e papis.

Lembre-se que nenhum usurio tem qualquer permisso para acessar qualquer
objeto de dados at que voc explicitamente atribua a ele tais permisses. Quando voc
concede uma permisso de comandos para um usurio, voc est lhe dando a permisso de
executar uma tarefa especfica, tal como criar objetos de banco de dados ou fazer backup de
um banco de dados ou de um log de transaes. Esse usurio permanece com a permisso
que voc lhe deu at que e;a seja explicitamente removida. Depois que uma permisso for
revogada, o usurio no pode mais realizar a mesma tarefa, at que lhe tenha sido
concedida a mesma permisso de comando novamente.

Para conceder ou revogar uma permisso utilizando o Enterprise Manager, os passos
so os seguintes:


1. No Enterprise Manager, clique com o boto direito no banco de dados cujas
permisses voc quer alterar, e em Properties. Aparece a caixa de dilogo abaixo:

2. Essa a mesma tela vista anteriormente (em visualizando permisses de bancos de
dados). Na primeira coluna desta tela, abaixo de User/Role esto listados todos os
IDs de usurio de banco de dados para este banco de dados. Lembre-se que esta
coluna pode listar qualquer usuri, grupo ou papel. Nas outras colunas esto as
vrias permisses para comandos SQL que podem ser atribudas. Note que na tela
no cabem todas as permisses existentes; para v-las, voc tem que rolar
horizontalmente para a direita.
3. Para atribuir qualquer das sete permisses para comandos SQL para qualquer
usurio, papel ou grupo exibidos na primeira coluna, clique na coluna da permisso
que voc quer atribuir, na linha do usurio que deve receber tal permisso. A
permisso no concedida at que voc clique em Apply ou Ok.


4. Para revogar uma permisso de comando que tenha sido atribuda anteriormente,
clique na caixa de verificao que representa a permisso de comando que voc
quer revogar do usurio, grupo, ou papel. Quando voc clicar na caixa de
verificao, ela muda para um X vermelho (como mostrado abaixo), indicando que
a permisso ser revogada. A permisso s de fato revogada quando voc clica em
Ok ou Apply.

5. Depois de revogar e conceder todas as permisses para comandos SQL que voc
queira, saia dessa tela clicando em Ok. Ento voc volta para o Enterprise Manager.

Concedendo e revogando permisses de objetos pelo Enterprise Manager
Quando mostramos como visualizar permisses de objetos para usurios, grupos ou
papis, vimos que h dois modos de visualiz-las. Pode-se ver as permisses de objeto sob
a perspectiva do usurio, grupo ou papel, ou a pela perspectiva do objeto de banco de dados
em si. Isso tambm se verifica para a concesso e revogao de permisses de objeto. Aqui,
demonstraremos como conceder/revogar permisses de objetos pela perspectiva do usurio,
grupo ou papel, pois essa a maneira mais prtica e conveniente.

No se esquea de que um usurio no tem permisso para acessar qualquer objeto
de banco de dados at que tal permisso lhe tenha sido atribuda Quando voc concede uma
permisso de objeto a um usurio, voc est lhe dando a permisso de executar uma tarefa
em um objeto preexistente, tal como SELECT, INSERT, UPDATE, ou DELETE sobre o
objeto. Esse usurio mantm a permisso de objeto at que a mesma tenha sido
explicitamente revogada.

Caso voc queira remover/conceder permisses pela perspectiva do objeto de banco de
dados, voc pode, usando praticamente os mesmos procedimentos que sero descritos a
seguir.
1. Expanda o banco de dados cujas permisses de objeto voc quer alterar. Se voc for
conceder/revogar permisses para usurios ou grupos, clique em Users. Caso voc
queira alterar permisses para papis, clique em Roles.
2. Clique com o boto direito no usurio, grupo ou papel cujas permisses voc quer
alterar, e em Properties. Aparecer uma caixa de dilogo com propriedades do
usurio ou grupo, ou do papel.
3. Clique em Permissions. Aparece a tela de permisses para o usurio, grupo ou
papel que voc houver selecionado.

A primeira coluna tem um cone que representa o tipo do objeto de banco de dados,
seguido do nome do objeto de banco de dados. A coluna Owner mostra quem o
proprietrio do objeto. As outras colunas mostram as permisses de objeto
existentes. Uma marcao em alguma das caixas de verificao indica que o usurio
em questo tem permisso para esse objeto.
4. Para conceder alguma das seis permisses de objetos para o usurio, grupo ou papel
em questo, marque a caixa de verificao apropriada na coluna referente ao objeto.
A caixa de verificao ficar marcada. A permisso s de fato concedida quando
voc clica em Ok ou Apply.
5. Para revogar uma permisso que j tenha sido atribuda, clique na caixa de
verificao que representa a permisso de objeto que voc quer remover de um
usurio, grupo ou papel. Ao clicar na mesma, ela muda para um X vermelho,
indicando que a permisso ser revogada. A permisso s de fato revogada ao se
clicar em Ok ou Apply.
6. Depois de teminar de definir as permisses de objetos, voc pode sair da tela
clicando em Ok. Voc deve ento clicar em Ok de novo para retornar ao Enterprise
Manager.

Concedendo e revogando permisses para comandos SQL, usando
comandos SQL
Permisses tambm podem ser concedidas ou revogadas atravs de comandos SQL.

Para isso, usa-se os comandos GRANT e REVOKE.

GRANT concede permisses, enquanto REVOKE as revoga. A sintaxe do GRANT :

GRANT {ALL | comando [,..n]}
TO conta_segurana [,..n]

E a do REVOKE :
REVOKE {ALL | comando[,...n]}
FROM conta_segurana [,...n]
Onde:
comando o comando SQL para o qual a permisso est sendo concedida/removida. Os
comandos podem ser:
CREATE DATABASE
CREATE DEFAULT
CREATE PROCEDURE
CREATE RULE
CREATE TABLE
CREATE VIEW
BACKUP DATABASE
BACKUP LOG
ALL indica que todas as permisses da(s) conta(s) de segurana em questo sero
concedidas/revogadas.
conta_segurana a conta de segurana no banco de dados atual para a qual as permisses
esto sendo adicionadas ou removidas. Pode ser um:
Usurio do SQL Server ou do NT
Grupo do NT
Papel do SQL Server
n indica que pode ser informado mais de um nome de conta de segurana para se
conceder/revogar permisses, assim como pode-se informar mais de um comando para tr
permisso concedida/revogada. Basta separ-los por vrgula.

Caso quisssemos por exemplo, permitir que um usurio pudesse criar uma tabela,
digitaramos

GRANT create table TO usuario

E para revogar essa permisso:

REVOKE create table FROM usuario

Para revogar todas as permisses de um usurio, digitaramos este comando:

REVOKE ALL FROM usuario