ADMINISTRAÇÃO DO SQL SERVER

Transcrição

1 ADMINISTRAÇÃO DO SQL SERVER 2012

2 O QUE ESPERAR A intenção deste livro é que ele seja bem tranquilo de ser lido e ser pesquisado. Não escrevi algo extremamente formal, mas algo que seja como um dos meus vídeos, vou explicando com as minhas palavras, sempre usando referências de livros e links da Microsoft. Recomendo a leitura deste livro juntamente com a prática em um ambiente Windows Server 2012 Datacenter com o SQL Server Enterprise Edition. Tenha o livro de um lado e a máquina do outro. No capítulo 1 vamos falar sobre os princípios do SQL Server, do que ele é feito, como ele foi feito e os bancos de dados de sistema e de usuário. Já no capítulo 2 vamos abordar algumas novidades do SQL Server 2012, como Contained Database, instalação em Server Core e AlwaysOn. Já no último capítulo, vamos falar um pouco sobre garantia de persistência de dados, locks, deadlocks e algumas técnicas e ferramentas de resolução de problemas. Todas essas informações podem ser encontradas online, nos nossos vídeos (FIAP X e Espiral do Conhecimento), nos livros publicados pela Microsoft Press e nos sites Technet e MSDN.

3 1 ARQUITETURA DO SQL SERVER Entender sobre a arquitetura de um sistema computacional como o SQL Server é importantíssimo sobre diversos aspectos. Não vou fazer uma lista de vantagens, mas no momento em que você enfrentar algum erro, problema ou mal comportamento, será muito mais fácil criar hipóteses sobre onde está o erro, procurar por evidências e resolver estes problemas. Por este motivo começamos o capítulo conversando sobre arquitetura do SQL Server. Apesar deste capítulo estar somente começando, eu sugiro que você leia (caso fique interessado) os livros The Guru s Guide to SQL Server Achitecture and Internals e o Professional SQL Server 2012 Internals and Troubleshooting. 1.1 SQL SERVER? O SQL Server hoje é um nome utilizado para uma suíte de aplicações inclusas no pacote Microsoft SQL Server. As principais são: SQL Server Database Engine SQL Server Analysis Services SQL Server Reporting Services SQL Server Data Quality Services SQL Server Integration Services SQL Server Master Data Services É, eu sei, é bastante coisa! Neste livro vamos conversar apenas sobre o SQL Server Database Engine.

4 O SQL Server Database Engine é um Sistema de Gerenciamento de Banco de Dados, ou seja, ele faz o meio de campo entre o usuário e os dados armazenados no servidor. É muito comum ouvir que o SQL Server é um banco de dados. Se formos levar ao pé da letra, este conceito não está certo, pois como veremos na seção 1.4, um banco de dados é a representação de arquivos do Sistema Operacional. Mas pode ficar tranquilo e chamar o SQL Server de banco de dados que você não vai sofrer bullying. 1.2 VERSÕES DO SQL SERVER O SQL Server é um produto que há muito tempo atrás foi comprado da Sybase, pois a Microsoft não tinha nenhum produto que se aproximava à complexidade de um banco de dados que a Microsoft precisava. Dessa maneira, o SQL Server 6.0 e o 6.5 foram lançados com a mesma arquitetura daquela comprada pela Sybase. A partir da versão 7.0 houve uma grande mudança de estrutura de gerenciamento de memória, processamento de transações, entre outras que ainda permanecem nas mais recentes versões do produto. Abaixo está listada as versões com numerações internas e o seu nome público. Versão Nome Público 6.0 SQL Server SQL Server SQL Server SQL Server SQL Server 2005

5 10.0 SQL Server SQL Server 2008 R SQL Server SQL Server 2014 Lembre desta tabela. Ela será importante ao identificar a localização da instância do SQL Server, entre outras operações de administração do servidor. CODEBASE Após a aquisição do código base para o SQL Server 6.0 da Sybase, a Microsoft decidiu fazer grandes reestruturações na arquitetura do SQL Server para a versão 7.0. Muitas destas se perpetuaram para as versões 2000, 2005, 2008 e O gerenciamento de memória por exemplo permaneceu com os mesmos princípios desde a versão 7.0 até a versão 2008 R2. Então, todas as vezes que você se deparar com um artigo do SQL Server que descreve o funcionamento interno do banco de dados da Microsoft, não o feche. Talvez ele não esteja ultrapassado. Ali você poderá encontrar informações bem úteis em relação ao funcionamento geral do SQL Server. Um dos livros utilizados para a narração deste é o Guru s Guide to SQL Server Architeture and Internals, que tem como base o SQL Server INSTÂNCIAS Toda instalação do SQL Server caracteriza uma instância do SQL Server. Podemos ter na máquina diversas instâncias do SQL Server, e cada instância, diversos bancos de dados. O SQL Server suporta

6 até 50 instâncias instaladas na máquina, e elas podem ser de dois tipos: Instância Padrão. Apenas uma instância padrão pode existir na máquina. Para se conectar a ela, o usuário/aplicação deve fazer referência apenas ao nome da máquina. Instância Nomeada. É permitido até 50 instalações de instâncias nomeadas em um servidor. Para se conectar a esta máquina, o usuário/aplicação deve fazer referência ao nome da máquina e o nome da instância. Exemplo: nome-do-servidor\nome-da-instancia 1.4 ARQUIVOS DO SQL SERVER O SQL Server trabalha com três arquivos tipos de arquivos para definir um banco de dados. Estes três tipos de arquivos possuem funções bem discretas e distintas. MDF: Este é o arquivo principal do SQL Server, é o ponto de partida de um banco de dados. Sua extensão é um acrônimo de Master Data File. LDF: O Log Data File é um arquivo transacional que armazena as operações realizadas no SQL Server. Antes de qualquer alteração ser realizada no banco de dados, ela primeiro é escrita no arquivo LDF. Este arquivo é necessário enquanto o banco de dados estiver online, e opcional quando ele estiver offline. NDF: Muito utilizado para obter ganho de desempenho no SQL Server, o Secondary Data File é opcional e poder ser criado para auxiliar o MDF a armazenar dados como tabelas e stored procedures.

7 Todos os arquivos do SQL Server possuem extensão opcional, ou seja, não é preciso que o arquivo termine em.mdf,.ldf ou.ndf para que o SQL Server o reconheça. 1.5 SQL SERVER COMO UM SERVIDOR CONEXÃO COM O SGBD Ao se conectar com o banco de dados, você deve ter em mente alguns dados básicos, como: Nome ou IP do banco de dados Porta a ser conectada Usuário a ser utilizado Se a instância é default ou nomeada Em alguns casos assim como neste curso a conexão ao banco de dados será feita diretamente na máquina onde o SQL Server Database Engine está instalado. Dessa maneira, você não precisará colocar nenhuma informação, apenas clicar em Connect.

8 A tela acima apresenta as seguintes informações: Tipo de servidor: SQL Server Database Engine Nome do servidor: FIAP X Instância: Default, padrão. Autenticação: Windows Authentication com o usuário logado. LOCALIZAÇÃO DOS ARQUIVOS DO SQL SERVER Como podemos instalar mais de uma instância do SQL Server por servidor, devemos identificar quais arquivos são de qual instância e quais arquivos são compartilhados entre instâncias. Vamos começar abrindo a pasta C:\Program Files\Microsoft SQL Server

9 Como vimos na seção 1.2 as builds (versões) do SQL Server são crescentes. Podemos ver acima destacado as versões 80, 90, 100 e 110. Estes são todos os arquivos compartilhados entre as instâncias instaladas na máquina. Ali estão arquivos que proveem compatibilidade reversa, arquivos do Management Studio, entre outras ferramentas de gerenciamento. A pasta MSSQL11.SQLEXPRESS indica que há uma instância do SQL Server instalada na máquina. O próprio nome da pasta já nos diz muito: MSSQL: Instância do SQL Server Database Engine 11: SQL Server 2012 SQLEXPRESS: Instância nomeada, neste caso com o nome SQLEXPRESS. No momento da instalação, é possível escolher qualquer nome para a instância, não necessariamente SQLEXPRESS. Ela pode representar tanto uma instância de uma área (VENDAS) como uma nomenclatura interna (INST03). Cada instância ter a sua pasta reservada dentro do SQL Server faz com que múltiplas possibilidades possam ser criadas. Você poderá por exemplo ter duas instâncias da mesma versão do SQL Server instaladas com Service Packs diferentes. Desta maneira você pode testar o funcionamento de cada uma, ou realizar testes para aplicar atualizações em ambiente de produção. Ao abrir a pasta da instância do SQL Server, você verá as seguintes subpastas:

10 Backup: Criada para ser um possível local de armazenamento de backups dos banco de dados localizados nesta instância do SQL Server. Binn: Localização dos arquivos executáveis e DLLs utilizadas para o funcionamento do SGBD. Data: Localização dos arquivos de banco de dados (MDF, NDF e LDF). Install: Localização de arquivos de suporte para serem executados quando uma função específica do SQL Server é provisionada ou para ser executado assim que o serviço de SQL Server foi criado. Jobs: Lista de jobs agendados através do serviço SQL Agent.

11 Log: Armazena informações de log de erro e trace de captura. Este log de erro é nomeado pelo SQL Server de ERRORLOG. repldata: Dados de suporte à replicação quando ela estiver ativada no servidor. Template Data: Dados utilizados para criação dos bancos de dados de sistema (master, msdb, etc.). Veja mais informações sobre bancos de dados de sistema na seção BANCOS DE DADOS DE SISTEMA E USUÁRIOS O SQL Server possui dois tipos de bancos de dados, os de sistema e os de usuário. Essencialmente eles possuem as mesmas características. O que os diferenciam é a necessidade dos bancos de dados de sistema estarem online para que o serviço de SQL Server possa ser executado. Caso algum banco de dados de sistema falhar, o serviço de SQL Server não entrará online; agora caso algum banco de dados de usuário falhar, o SQL Server entrará online e reportará as devidas informações em seu log de erros. Entender a funcionalidade de cada um dos bancos de dados de sistema ajudará o DBA a responder de forma rápida a problemas observados na máquina e ajudará a coletar os dados necessários para identificação de um problema eminente. MASTER Este é o banco de dados principal do SQL Server. Ele armazena todas as informações relativas à instância, como localização dos outros bancos de dados de sistema e usuário, informações sobre logon, linked servers e configurações do serviço de SQL Server.

12 MSDB Ouviu falar de msdb, você tem que fazer o link com o serviço SQL Agent. Este serviço é responsável por agendar tarefas e alertas no SQL Server. Dentro do msdb são armazenadas informações relativas a estes jobs e alertas como configurações, agendamento e resultados de execução. MODEL Esta base de sistema é utilizada como modelo para criação de quaisquer outras bases de dados dentro do SQL Server. Toda e qualquer alteração realizada nela refletirá nas bases de dados que forem criadas dentro do SQL Server. Ela é muito útil para os DBAs que desejam alterar configurações padrão de todas as bases do SQL Server que forem criadas futuramente. TEMPDB Como o próprio nome diz, a base temporária é um espaço onde os programadores de T-SQL podem utilizar para realizar diversos tipos de conversão e manipulação de dados. Este banco de dados pode significar um gargalho significante no desempenho geral do SQL Server. Um dos pontos a ser analisado no momento em que um problema de desempenho for percebido é, com certeza, a tempdb. Toda vez que o serviço de SQL Server é iniciado, este banco de dados é removido e recriado. Consequentemente, como a gente acabou de ver, qualquer alteração realizada no banco de dados model refletirá neste banco de dados no momento em que for recriado. RESOURCE DATABASE

13 Banco de dados de apenas leitura, ele não é mostrado no SSMS (SQL Server Management Studio). Este banco de dados armazena fisicamente os objetos de sistema que são apresentados no schema sys de todas as bases de dados. É um recurso valioso no momento em que uma atualização (exemplo: Service Pack) é realizada no SQL Server. BANCO DE DADOS DE USUÁRIO Os bancos de dados de usuário são criados sob demanda pelo DBA para armazenar dados e informações relativas a uma aplicação. Ao ser criado, o SQL Server copia os dados do banco de dados model e cola com o nome requisitado pelo DBA. Todas as informações são então transferidas para o novo banco de dados.

14 2 NOVIDADES NO SQL SERVER CONTAINED DATABASE O conceito de Contained Database gira em torno da ideia de que todos os recursos que o banco de dados necessita para poder trabalhar estão armazenados dentro dele mesmo, como um container. Para ilustrar, há muitos recursos no SQL Server que dependem de informações do servidor, como logins, Extended Stored Procedures, entre outros exemplos. Isso pode se torna um problema quando você deseja mover o seu banco de dados para outro servidor. Com banco de dados SQL Server no Windows Azure, é natural que a Microsoft crie uma forma de movimentação de dados para a sua nuvem. A partir disso vemos o Partially Contained Database nascer no SQL Server Partially porque o SQL Server não garante que todos os recursos daquela base estejam contidas nela mesma. Há duas formas de identificar quais recursos extravasam a contenção de base, são eles: A view sys.dm_db_uncontained_entities lista quais recursos não estão contidos no banco de dados. Já o evento database_uncontained_usage é disparado toda vez que uma entidade não contida é identificada em tempo de execução. Para alterar a propriedade de um banco de dados de usuário para partially contained, duas modificações devem ser feitas. A primeira diz respeito à habilitar o servidor para esta funcionalidade e a segunda é para configurar os bancos de dados que você deseja que entrem em modo contido.

15 CONFIGURANDO O SERVIDOR Abra o SSMS (SQL Server Management Studio) e crie uma nova Query para ser executada no servidor conectado e execute o comando abaixo: sp_configure O SQL Server mostrará 5 colunas, que dizem respeito a: name: Nome da configuração minimum: Valor mínimo da configuração maximum: Valor máximo da configuração config_value: Valor configurado run_value: Valor em execução Algumas configurações necessitam que o serviço de SQL Server seja reiniciado ou que o comando RECONFIGURE seja executado. Entender a diferença entre config_value e run_value é crucial para um DBA. Veja o valor configurado e o valor de execução da opção contained database authentication. Vamos alterar este valor para 1. Execute então: sp_configure 'contained database authentication', 1 Veja novamente o valor das colunas config_value e run_value executando: sp_configure

16 Para fazer a configuração valer, digite: reconfigure E por fim veja a configuração executando: sp_configure CONFIGURANDO O BANCO DE DADOS Com o SSMS aberto, clique com o botão direito no banco de dados desejado > Properties > no painel da esquerda selecione Options.

17 Em Containment Type, altere o valor para Partial e clique em OK. Verifique se há algum recurso não contido no banco de dados executando: select * from sys. dm_db_uncontained_entities 2.2 DATABASE RECOVERY ADVISOR Para falar sobre Database Recovery Advisor, vamos utilizar o post escrito por Vatsalya Agrawal, que introduz a funcionalidade de Database Recovery Advisor em seu blog: Backup/Restore é um ponto essencial dentro das tarefas de gerenciamento de banco de dados. Ter um bom plano de backup ajuda os DBAs a restaurarem o ambiente a partir de qualquer falha de uma forma muito eficiente. Para recuperar de uma falha, os DBAs devem restaurar um conjunto de backups em uma sequência lógica correta. Como o SQL Server fornece diversos de tipos de backup (onde cada um deles tem um conjunto diferentes de propriedades), criar uma sequência de recuperação correta para um determinado ponto específico no tempo pode ser algo bem complicado. Adicione isso à complexidade de vários cenários em garfo (você verá essa situação no exemplo abaixo) e o fato de haver vários planos de recuperação corretos com custos diferentes de execução e a tarefa de criar uma sequência de recuperação ideal fica muito complicado. Para resolver este problema, o time de SSMS projetou uma ferramenta chamada Recovery Advisor (Assessor de Recuperação). Recovery Advisor ajuda os DBAs na criação de uma sequência correta e ideal para restauração de um ambiente.

18 Para mexer com o Recovery Advisor, vamos primeiro criar um banco de dados e tirar alguns backups dele. O script a seguir cria um banco de dados e, em seguida, tira um Backup Full, depois um Backup Diferencial e um Backup do Transaction Log. Em seguida faz o restore para o backup diferencial e faz outro Backup do Transaction Log. USE master; IF EXISTS(select * from sys.databases where name ='cenario_em_garfo') DROP DATABASE cenario_em_garfo; create database cenario_em_garfo; use cenario_em_garfo; create table t (c int); - - backup full BACKUP DATABASE [cenario_em_garfo] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\cenario_em_garfo. bak' WITH NOFORMAT, NOINIT, NAME = N'cenario_em_garfo- Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 insert into t values (1); WAITFOR DELAY '00:01:00' - - backup diferencial BACKUP DATABASE [cenario_em_garfo] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\cenario_em_garfo. bak' WITH DIFFERENTIAL, NOFORMAT, NOINIT, NAME = N'cenario_em_garfo- Differential Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 insert into t values (2); WAITFOR DELAY '00:01:00'; - - backup do log (L1)

19 BACKUP LOG [cenario_em_garfo] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\cenario_em_garfo. bak' WITH NOFORMAT, NOINIT, NAME = N'backup_fork- Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = Recupera para o backup diferencial USE [master]; ALTER DATABASE [cenario_em_garfo] SET SINGLE_USER WITH ROLLBACK IMMEDIATE; RESTORE DATABASE [cenario_em_garfo] FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\cenario_em_garfo. bak' WITH FILE = 1, NORECOVERY, NOUNLOAD, REPLACE, STATS = 5 RESTORE DATABASE [cenario_em_garfo] FROM DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\cenario_em_garfo. bak' WITH FILE = 2, NOUNLOAD, STATS = 5 ALTER DATABASE [cenario_em_garfo] SET MULTI_USER; use cenario_em_garfo; insert into t values (3); WAITFOR DELAY '00:01:00'; - - realiza o segundo backup do log (L2) BACKUP LOG [cenario_em_garfo] TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\cenario_em_garfo. bak' WITH NOFORMAT, NOINIT, NAME = N'cenario_em_garfo- Transaction Log Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10 Agora temos 4 backups (1 Full, 1 Diferencial e 2 do Log de Transação), formando um cenário em garfo no nosso banco de dados chamado cenario_em_garfo :

20 Para abrir o Recovery Advisor, clique com o botão direito no banco de dados cenario_em_garfo > Restore > Database. Por padrão, o Recovery Advisor tenta restaurar o banco de dados ao último backup tirado. Neste caso, é o segundo backup de log feito. Observe o plano de restauração que foi criado: restaurar o backup full, depois o diferencial e por último o backup de log. Veja a posição do log de backup: 4, também conhecido como segundo backup de log, o L2 da imagem acima. Até agora, tudo certo. Mas se nós não quisermos voltar ao último backup realizado nesse banco de dados? Se quisermos voltar o backup a um ponto específico no tempo? É exatamente pra isso que a opção Timeline serve. Vamos supor que queiramos restaurar o banco de dados segundos depois do backup diferencial. Clique no botão Timeline localizado no canto direito.

21 Conforme a imagem acima, selecione a opção Specific date and time e altere o intervalo para Hour. Neste momento você consegue ver com clareza como voltar para o backup diferencial, para o último instante ou como voltar pra um ponto específico no tempo. Para observarmos como o plano de recuperação é alterado, selecione um intervalo de tempo poucos segundos depois do backup diferencial ter sido realizado e clique em OK. Veja agora o plano de recuperação: primeiro recuperar o backup full, depois o backup diferencial e por último o log L1. Resumindo, o Recovery Advisor é uma ótima ferramenta para criar planos de recuperação em um ponto específico no tempo. Faz com que a tarefa de recuperação de banco de dados seja menos dolorosa. 2.3 SERVER CORE Começando com o SQL Server 2012, a instalação do Sistema de Gerenciamento de Banco de Dados da Microsoft pode ser instalado

22 na versão Server Core do Windows Server. As versões suportadas são Windows Server 2008 R2 SP1, e superiores. A instalação Server Core é uma opção de instalação do Sistema Operacional para servidores da Microsoft que dá o menor ambiente de execução para funcionalidades específicas. Esta opção auxilia a reduzir as necessidades de gerenciamento e manutenção e reduz a superfície de ataque do servidor. O grande impeditivo do SQL server não poder ser instalado no Windows Server 2008 quando a opção de instalação Server Core foi disponibilizada é pelo motivo que o.net Framework não estava pronto para ser executado nesta nova plataforma. Para uma documentação completa sobre instalação do SQL Server 2012 em um ambiente Windows Server Core, veja esta documentação publicada no Technet. 2.4 ALWAYSON Alta disponibilidade e capacidade de recuperação de desastres sempre foram e sempre serão grandes preocupações na vida de um DBA. Alta disponibilidade significa garantir que o serviço estará disponível para que os usuários e as aplicações que utilizam o banco de dados realizem seu trabalho, reduzindo ao máximo o tempo de downtime, ou seja, o tempo em que o serviço está indisponível. Capacidade de recuperação de desastres é uma tarefa reativa que o DBA executa no momento em que algum problema acontece com o banco de dados que o deixa indisponível, inacessível para os usuários e para as aplicações que dependem.

23 O que a Microsoft pensou então? Vamos fazer uma solução que englobe os dois! Daí nasceu o AlwaysOn, uma solução de Alta Disponibilidade e Recuperação de Desastres (High Availability & Disaster Recovery - HA/DR). Vamos considerar um ambiente de três servidores: Os três servidores acima listados participam de um Failover Clustering e possuem o serviço de SQL Server instalado. Para que a solução de AlwaysOn seja implementada, é criado um Availability Group neste caso com o nome MyTestAg, que representa um ou mais bancos de dados que serão abençoados pela solução de HADR. Demonstrado na esquerda, está o servidor onde o serviço de SQL Server está online, a réplica primária, onde os usuários e aplicações se conectam para realizar transações no banco de dados.

24 Os computadores Node 02 e Node 03 estão trabalhando como réplicas secundárias, em modo Leitura, Read-Only (RO). Estas máquinas recebem as atualizações realizadas no Node 01, aplicam em seu banco de dados e garantem que os dados estejam persistidos. Desta maneira, se o servidor Node 01 falhar, qualquer uma das outras duas máquinas tem a capacidade de trazer o banco de dados para online e ser o responsável por responder as requisições dos usuários e aplicações que se conectam a ele. O AlwaysOn possui propriedades de persistência de dados interessantíssimas, como commit síncrono e commit assíncrono. Recomendo que vocês leiam bastante sobre esta funcionalidade que resolve dois problemas dos DBAs de SQL Server: Alta Disponibilidade e Recuperação de Desastres.

25 3 TÉCNICAS DE RESOLUÇÃO DE PROBLEMAS 3.1 METODOLOGIA DE RESOLUÇÃO DE PROBLEMAS Um Administrador de Windows Server 2012 irá se deparar com problemas, erros ou situações inesperadas em seu ambiente e em sua organização. Tendo isso em mente, é muito útil ter um framework para auxiliar a seguir os passos corretos em direção à resolução dos problemas. Deo Melgaço hoje responsável pela divisão de suporte do Microsoft Office na América Latina junto com outros engenheiros da Microsoft construíram algo chamado de Problem Resolution Framework, que consiste de quatro fases. Eu vou descrever brevemente sobre cada um destes quadrantes, que recebem inputs específicos, incluem uma série de ações e provêm saídas.

26 DEFINIÇÃO Aqui é onde o fluxo sempre começa. Acredite: um problema bem definido é a metade do caminho para resolvê-lo. Nesse momento é onde você vai reduzir o problema de uma maneira que ele não pode ser dividido em mais de um. Exemplos de boas definições de problema: Usuário X não consegue enviar para usuário Y Quando o Disk Manager é aberto, o servidor apresenta a tela azul com a mensagem STOP Error 0x : IRQL_NOT_DISPATCH_LEVEL O Servidor SRV demora 20 minutos para iniciar. Ter a definição do problema em mãos faz com que você alinhe seu objetivo para resolver aquele problema específico, procurando informações, pistas para chegar à resolução deste problema. Depois de ter definido o problema, defina um objetivo: Usuário X não consegue enviar para usuário Y. Uma vez que o usuário conseguir enviar um para o usuário Y, consideramos este problema resolvido. Quando o Disk Manager é aberto, o servidor apresenta a tela azul com a mensagem STOP Error 0x : IRQL_NOT_DISPATCH_LEVEL. Este problema será considerado resolvido quando conseguirmos abrir o Disk Manager sem apresentar tela azul. O Servidor SRV demora 20 minutos para inicializar. Este problema estará resolvido quando o servidor SRV tomar menos de 10 minutos para inicializar.

27 Uma vez com a definição do problema e objetivo do trabalho em mãos, podemos passar para a fase de COLETA Aqui é onde a coleta de dados acontece. Ser capaz de formular hipóteses é crucial para resolver o problema, coletando as informações corretas que vão guiar para a resolução do problema. Por isso que o estudo constante sobre a tecnologia que você trabalha é extremamente importante. Entender a arquitetura do sistema, como ele trabalha e o que esperar de determinadas ações é essencial para que hipóteses possam ser formadas. Uma vez que as hipóteses do que está causando o problema foram criadas, o plano de coleta pode ser formulado e executado. Dependendo do tipo de acesso que você possui ao servidor, este plano precisa ser enviado para um terceiro e ser analisado em sua máquina de trabalho. Ao final desta fase, você deve ter em mãos dados consistentes, confiáveis, legíveis e validados. Caso contrário, esta fase não pode ser encerrada. Dados corretos em mãos? Vamos então para a ANÁLISE Depois de ter obtido dados validados e capazes de serem lidos, você deve procurar por evidências que testem as hipóteses levantadas na fase anterior. A saída desta fase será uma e apenas uma hipótese do porque o problema está acontecendo. Entender como a tecnologia que você está trabalhando é, novamente, importantíssimo nesta fase. Conhecer sobre a arquitetura do sistema, saber quais ferramentas utilizar, entender como utilizar as ferramentas disponíveis para análise de dados e o que esperar como resultado de cada uma é crucial neste momento.

28 Tais resultados vão suportar e comprovar as hipóteses anteriormente levantadas. CORREÇÃO No fim da fase anterior você será capaz de definir um plano de ação para ser aplicado ao sistema com defeito. Este plano de ação sustentado por evidências contém os passos para resolver o problema definido na primeira fase e usualmente contém o Como fazer ou o passo-a-passo que deve ser seguido para que o problema possa ser contornado. Muitas vezes este plano de ação é arquivado em forma de , em uma ferramenta de registro de chamados, uma base de dados de conhecimento interna da organização ou enviado como solicitação de alteração de sistema, algo conhecido como Gerência de Mudanças, que registra toda e qualquer alteração realizada no ambiente. O resultado esperado é que o problema que teve seu escopo definido no início deste fluxo seja resolvido. Haverá vezes que isto não ocorrerá, então é o momento de voltar à fase de Definição e entender o que aconteceu de errado. Voltar à fase de Definição não representa necessariamente voltar à estaca zero, mas sim iniciar um trabalho mais minucioso em relação a este ambiente. 3.2 CONCORRÊNCIA DE QUERIES Para entender sobre concorrência de queries, é preciso entender como o SQL Server funciona. Para toda transação que é realizada em um banco de dados, é esperado um certo nível de certeza. Exemplo: Se você depositou 50 reais em uma conta corrente, você espera ver o saldo anterior, mais os 50 reais depositados, não 45, 55, ou qualquer outro valor (por mais benéfico que seja para você).

29 Desta forma, foi estabelecido propriedades de um banco de dados que resumem-se no acrônimo ACID. A DE ATÔMICO Atômico significa indivisível neste caso, uma coleção de eventos sendo tratado como uma unidade. Ou a série de eventos que você deseja realizar é completada com sucesso ou falha como um todo. Exemplo: Você leva reais para ser depositado e 3 contas no valor de 300 reais cada para serem pagas. Se o depósito falhar e as contas forem pagas, você estará com 900 reais no negativo. Se uma das contas falharem, você entrará no SPC/SERASA. Atomicidade vai garantir que todas as tarefas concluam com sucesso ou que todas falhem. C DE CONSISTENTE Consistente significa que tudo está de acordo. Neste caso, a quantidade depositada é a quantidade creditada. Se 50 reais forem transferidos da conta A para a conta B, 50 reais devem ser creditados na conta B e 50 reais debitados da conta A. I DE ISOLADO Quando um SGBD insere um valor em uma tabela, nada deverá alterar estes valores ao mesmo tempo. Do mesmo jeito, se o banco de dados precisa voltar a um estado anterior, nada deve afetar a realização deste evento. Todas as transações são isoladas umas das outras. D DE DURÁVEL Se houver uma falha no banco de dados, como queda brusca de energia depois que sua transação for realizada, é preciso garantir que a transação foi persistida no banco de dados. Esta propriedade

30 ACID é atingida com a utilização do arquivo de Transactional Log, o Log Transacional. 3.3 CONCORRÊNCIA E LOCKS NECESSIDADE DE CONCORRÊNCIA Para entendermos sobre locks, é importante entendermos a importância de concorrência dentro de um banco de dados. Concorrência em um banco de dados garante que múltiplas operações ocorram ao mesmo tempo e o resultado final estejam de acordo garantindo as propriedades ACID vistas no item acima. Concorrência também é também uma importante propriedade de um banco de dados, caso contrário seria possível que apenas um usuário estivesse conectado ao banco de dados de cada vez, causando uma grande fila para atualizações, aplicações travariam e em consequência, usuários irritados. LOCKS O mecanismo para habilitar o SQL Server manter concorrência entre seus usuários é um lock, um travamento. Ao travar um pedaço de dado, o SQL Server previne o acesso a ele. Há diversos tipos de locks (conhecidos como lock modes), e uma variedade de tipos de acesso e compatibilidades entre eles. Um lock é necessário para praticamente qualquer tipo de acesso a dados, inclusive na leitura de dados. Por exemplo: um shared lock utilizado na leitura de dados garante que os dados lidos daquela tabela não serão removidos por outra transação até que a transação atual seja concluída. MONITORANDO LOCKS