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.
'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:
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:
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.
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.
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.
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.
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.
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.
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.
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:
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: