Pular para o conteúdo principal

Treinamento para consultas com SQL Server - Parte 9 - Medidas de Segurança Iniciais

O trabalho com bancos de dados muitas vezes será feito em ambiente de produção, embora se recomende que isso seja evitado ao máximo.

Com isto aumenta significativamente o risco de se executar alguma consulta de atualização dos dados que cause problemas. Um DELETE ou UPDATE sem WHERE, por exemplo, já é o suficiente para tirar o sono do desenvolvedor durante muito tempo.

Alguns bancos de dados mais antigos e portanto, há mais tempo no mercado, como o ORACLE, exigem em todas as suas ferramentas de DML que o COMMIT seja sempre explícito, ou seja, para as modificações tanto dos dados como da estrutura de tabelas serem persistidas a instrução deve conter esta instrução, caso contrário, os resultados estarão pendentes até fechar a sessão e no momento em que isso é feito, um ROLLBACK é executado automaticamente.

O SQL Server ainda não possui este recurso. Toda e qualquer consulta executada está no modo AUTO COMMIT. Assim, para evitar problemas causados por este tipo de configuração, este documento apresenta duas alternativas que visam prevenir problemas futuros. São elas:

  1. Executar consultas de DML dentro de um bloco BEGIN TRAN ... COMMIT | ROLLBACK
  2. Desabilitar o auto commit da ferramenta SSMS
Consulta com BEGIN TRAN | COMMIT/ROLLBACK

Basta simplesmente colocar as instruções envolvidas entre BEGIN TRAN e COMMIT ou ROLLBACK:

BEGIN TRAN
 <INSTRUÇÕES DML>
COMMIT; -- ou ROLLBACK

Vamos usar o exemplo da tabela DOCUMENTOS.FOLDERS

A consulta demonstrada a seguir insere quatro registros na tabela, imprime os resultados, faz o ROLLBACK da operação e um novo SELECT.

begin tran
 insert into documents.Folders (FolderId, ParentFolderId, Name)
 values (100, NULL, 'TREINAMENTO'),
        (101, 100, 'APOSTILAS'),
     (102, 100, 'BACKUPS'),
     (103, 100, 'AVALIAÇÕES');

 select *
 from documents.Folders
 where FolderId > 99;
rollback

select *
from documents.Folders
where FolderId > 99;

Esta consulta traz os resultados que podem ser conferidos na próxima figura, primeiro, como resultado da instrução SELECT dentro do bloco BEGN TRAN ... ROLLBACK, são exibidos os registros que foram inseridos. Fora do bloco, um novo SELECT é enviado e desta vez, nenhum registro é exibido.

Desabilitando o auto commit do SSMS

Executar as consultas dentro do bloco BEGIN TRAN ... COMMIT | ROLLBACK é apenas uma medida paliativa. Em um cenário adequado de configurações de acesso e permissões, o banco de dados deve ter um usuário específico para realizar operações DML, DDL e um apenas para executar consultas.

Este cenário é raro de encontrar. Assim, para evitar problemas, uma alternativa é desligar o AUTO COMMIT do SSMS (até o dia em que isso venha, como se espera, desligado por padrão). Para fazer isso no SSMS (em qualquer versão) acesse o menu Ferramentas > Opções. Na janela que se abre, expanda os itens Execução da Consulta > SQL Server > ANSI. Marque o campo SET IMPLICIT_TRANSACTIONS como representado na figura abaixo e reinicie o SSMS.

Ao executar qualquer consulta (inclusive de SELEÇÃO, infelizmente) será informado que existem transações pendentes quando for fechar a janela da consulta ou a aplicação e será solicitado uma confirmação para o COMMIT:


Postagens mais visitadas deste blog

Como gerar scripts para exportar dados no SQL Server 2008

Uma das tarefas mais comuns no trabalho com desenvolvimento de software que consome dados em bancos como o SQL Server 2008 é a necessidade de em algum momento precisarmos exportar os dados de um banco para outro. Quer seja para realizar testes ou fazer simulações existem várias maneiras de se fazer isto. Neste post eu quero demonstrar um recurso do SQL Server Management Studio (SSMS) que permite realizar esta tarefa rapidamente.Para os que estão acostumados a usar esta ferramenta, já devem saber que é possível gerar scripts para o schema e também transferir os dados entre dois bancos distintos. Isto pode ser feito se o SSMS puder conectar-se com as duas bases, de origem e destino. No exemplo que vou dar, o objetivo é gerar o script apenas para uma tabela do banco de dados de exemplo da Microsoft – Northwind.1. Iniciando o assistenteO assistente deve ser iniciado clicando com o botão direito do mouse sobre o banco onde se encontra a tabela a qual iremos gerar o script. Deve se clicar n…

Pivot dinâmico com SQL Server

Passo a passo para usar pivoteamento dinâmicoOs bancos de dados bem configurados e definidos armazenam os dados de forma a otimizar o acesso, evitando duplicidade e garantindo a integridade. Porém, em muitas situações isto pode dificultar a apresentação de forma adequada sendo necessário preparar os dados usando vários recursos entre os quais, fazer o pivoteamento.Se você não precisou ainda usar ou não sabe o que é consiste em transformar cada linha de uma determinada coluna em colunas de uma nova consulta.Assim, considere uma tabela que armazene as notas bimestrais de um boletim. Uma possível estrutura para esta tabela seria algo assim:ColunaTipo de dado/TamanhoDisciplinanvarchar(50)BimestreIntNotanumeric(5,2)Uma consulta select nesta tabela com alguns dados traria um resultado parecido com o abaixo:Porém pode ser que para apresentar estes dados em um relatório seja necessário transformar cada bimestre em uma coluna e agrupar as notas nestas colunas para que fique dessa forma:Isto po…

Desabilitando o auto commit no SSMS (SQL Server Management Studio)

(Ou, como prevenir desastres e manter o emprego a salvo…)Neste post vai uma pequena mas tremendamente útil dica para desabilitar o auto commit da aplicação SQL Server Management Studio (SSMS) que é usada por dez entre dez usuários do banco de dados SQL Server para fazer consultas, alterações e executar scripts no banco de dados. (Preferências à parte, realmente muita gente usa),A primeira e mais importante notícia é que, diferentemente da ferramenta do Oracle, este editor de scripts do SQL Server vem com o recurso de auto commit ativado por padrão, assim, qualquer instrução DML (alteração dos dados com update, insert e delete) ou DDL (alteração no banco como create, drop, alter, etc.) será imediatamente enviada ao banco e persistida.Isto pode ser altamente crítico pois se estiver executando as instruções em um banco de dados de produção não haverá muitas formas de desfazer se é que haverá.Inicialmente, pode se evitar muitos acidades executando estas instruções dentro de um bloco BEGIN…