SQLSat #253 Brasília, DF

Chegou o momento ideal para este anúncio!

Como já é de conhecimento de muitos, em 28 de Setembro de 2013 acontecerá em Brasília o SQLSaturday #253. Com o apoio do PASS eu estou ajudando a organizar este evento, e tenho certeza que será tão fantástico quanto os outros SQLSats do Brasil e do mundo.

O evento e gratuito e durante todo o sábado vamos ter diversas sessões divididas em 3 trilhas: desenvolvimento, administração e business intelligence.

Todos os detalhes estão no site do evento: http://sqlsaturday.com/253/eventhome.aspx



Luciano [Luti] Caixeta MoreiraMicrosoft MVP - SQL ServerPASS Regional Mentor - Brasil



Você já ouviu falar de DEADLOCK?


Olá pessoal tudo certo? Espero que sim!

 Vocês provavelmente já ouviram falar sobre deadlocks no SQL Server certo? Pois bem, no post de hoje irei explicar um pouco sobre eles, o que são, como simular um deadlock e como capturar a ocorrência dos mesmos na sua instância do SQL Server. 

O que é um deadlock? 

 Um deadlock ocorre em seu caso mais simples, quando duas sessões estão tentando adquirir um lock em um mesmo recurso, imagine que uma sessão detém um lock no recurso X e deseja adquirir um lock num recurso Y. Outra sessão possui um lock no recurso Y e deseja adquirir um lock no recurso X, neste cenário, nenhuma das sessões pode progredir e temos um deadlock, o SQL Server elimina uma das transações envolvidas através do DEADLOCK MONITOR, um dos componentes do engenho. O DEADLOCK MONITOR irá escolher como vítima a transação que custara menos para o processo de rollback considerando o que ela já executou até aquele momento. 

Simulando um deadlock 

 Crie uma base de dados com um nome de sua preferência, no meu caso a base se chama magusample: 

create database magusample
use magusample 

 Crie duas tabelas conforme abaixo nesta nova base: 

create table teste1 (col1 int)
insert into teste1 select 1

create table teste2 (col1 int)
insert into teste2 select 1 

 Na mesma sessão que foi usada para a criação da base execute o comando abaixo: 

begin tran
update teste1 set col1 = 1
--1 row updated 

 Em outra sessão, execute os comandos abaixo: 

begin tran
update teste2 set col1 = 1
update teste1 set col1 = 1
--Nada ira ser retornado 

 Volte na sessão usada para criar a base, limpe os códigos e rode a query abaixo: 

update teste2 set col1 = 1 

 Aguarde alguns segundos e o deadlock irá ocorrer: 

Msg 1205, Level 13, State 45, Line 1
Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. 

Capturando informações sobre os deadlocks 

 Existem algumas formas de se capturar a ocorrência de deadlocks, uma delas seria utilizando trace flags específicos, o 1204 e o 1222 (Preferível de ser utilizado no SQL 2005 e nas versões posteriores), os mesmos irão logar no errorloga ocorrência dos deadlocks, cada um possui um nível de detalhamento do deadlock diferente, sugiro que você leia no artigo abaixo as diferenças entre eles: 


 Habilite o trace flag 1222 e simule o deadlock, você irá ver algo no errorlog parecido com o abaixo:

2013-08-13 11:09:54.230 spid18s      deadlock-list
2013-08-13 11:09:54.230 spid18s       deadlock victim=processa43e40
2013-08-13 11:09:54.230 spid18s        process-list
2013-08-13 11:09:54.230 spid18s         process id=processa43e40 taskpriority=0 logused=132 waitresource=RID: 17:1:200:0 waittime=777 ownerId=41178487 transactionname=user_transaction lasttranstarted=2013-08-13T11:09:45.700 XDES=0x5b9fbd8 lockMode=U schedulerid=4 kpid=12904 status=suspended s
2013-08-13 11:09:54.230 spid18s          executionStack
2013-08-13 11:09:54.230 spid18s           frame procname=adhoc line=1 stmtstart=16 sqlhandle=0x02000000f3bf4403840529446d8b4da8aeef25afee8e475c
2013-08-13 11:09:54.230 spid18s      UPDATE [teste2] set [col1] = @1    
2013-08-13 11:09:54.230 spid18s           frame procname=adhoc line=1 sqlhandle=0x02000000cb7b680d28d85f5bbdde3af4bc46eb163aff3b64
2013-08-13 11:09:54.230 spid18s      update teste2 set col1 = 1    
2013-08-13 11:09:54.230 spid18s          inputbuf
2013-08-13 11:09:54.230 spid18s      update teste2 set col1 = 1   
2013-08-13 11:09:54.230 spid18s         process id=processa29e40 taskpriority=0 logused=132 waitresource=RID: 17:1:192:0 waittime=3782 ownerId=41178505 transactionname=user_transaction lasttranstarted=2013-08-13T11:09:50.447 XDES=0x47ea9590 lockMode=U schedulerid=3 kpid=10688 status=suspended
2013-08-13 11:09:54.230 spid18s          executionStack
2013-08-13 11:09:54.230 spid18s           frame procname=adhoc line=3 stmtstart=16 sqlhandle=0x0200000039359225ab348dbc90898cfe36eb7f50891673e4
2013-08-13 11:09:54.230 spid18s      UPDATE [teste1] set [col1] = @1    
2013-08-13 11:09:54.230 spid18s           frame procname=adhoc line=3 stmtstart=80 sqlhandle=0x0200000031a2c819ff1c9ae4228f2731bb58cd43dab671db
2013-08-13 11:09:54.230 spid18s      update teste1 set col1 = 1    
2013-08-13 11:09:54.230 spid18s          inputbuf
2013-08-13 11:09:54.230 spid18s      begin tran
2013-08-13 11:09:54.230 spid18s      update teste2 set col1 = 1
2013-08-13 11:09:54.230 spid18s      update teste1 set col1 = 1   
2013-08-13 11:09:54.230 spid18s        resource-list
2013-08-13 11:09:54.230 spid18s         ridlock fileid=1 pageid=200 dbid=17 objectname=magusample.dbo.teste2 id=lock77a7dc0 mode=X associatedObjectId=72057594038845440
2013-08-13 11:09:54.230 spid18s          owner-list
2013-08-13 11:09:54.230 spid18s           owner id=processa29e40 mode=X
2013-08-13 11:09:54.230 spid18s          waiter-list
2013-08-13 11:09:54.230 spid18s           waiter id=processa43e40 mode=U requestType=wait
2013-08-13 11:09:54.230 spid18s         ridlock fileid=1 pageid=192 dbid=17 objectname=magusample.dbo.teste1 id=lock7e20e9c0 mode=X associatedObjectId=72057594038779904
2013-08-13 11:09:54.230 spid18s          owner-list
2013-08-13 11:09:54.230 spid18s           owner id=processa43e40 mode=X
2013-08-13 11:09:54.230 spid18s          waiter-list
2013-08-13 11:09:54.230 spid18s           waiter id=processa29e40 mode=U requestType=wait 

 O artigo abaixo pode te ajudar a entender as informações fornecidas na log por este trace flag: 


 A segunda forma de lidar com deadlocks seria utilizando o SQL Server Profiler, deixe iniciado um trace que colete os eventos iguais aos da imagem abaixo e simule um deadlock:

  
 Quando o deadlock ocorrer você verá uma imagem parecida com a abaixo:

 
 A terceira forma seria via Extended Events, o artigo abaixo possui um passo a passo de como se configurar este tipo de monitoração: 


 Independentemente do método usado para coletar informações sobre ocorrências de deadlocks, existe sempre a chance de que o último comando levantado em cada sessão envolvida não seja aquele que gerou os locks que estão sendo pedidos ou que estão concedidos. Nestes cenários, a coleta de um trace pode ser necessária para mostrar exatamente como as sessões se envolveram no deadlock.

 Um observação final, alguns deadlocks podem ser bastante complexos para destrinchar, às vezes nem mesmo as informações coletadas e um trace são suficientes. Nestes cenários, uma dica é conseguir figurar alguma mudança em índices que possa mudar o caminho de acesso aos dados. Para ter uma ideia melhor destas colocações, existem posts muito bons do Duncan sobre o assunto: 




 Espero que tenham gostado do post, um abraço!
http://www.virtualpass.com.br/

XXXIX ENCONTRO DA COMUNIDADE SQLPORT

Realiza-se no dia 20 de Agosto, Terça-Feira, o XXXIX Encontro da comunidade SQLPort, que tem como objectivo a partilha de experiências e conhecimento entre os profissionais e entusiastas de SQL Server em Portugal. 
O evento vai ser realizado no auditório da Microsoft Portugal, pelas 18:30, sendo a entrada livre para todos os inscritos. 
Este evento terá múltiplas apresentações do tipo Lightning Talk, com duração de 5 ou de 10 minutos cada uma, e que terá entre outros os seguintes apresentadores: 
Vitor Pombeiro, Murilo Miranda, Paulo Matos, Bruno Basto e Niko Neugebauer. 

Agenda
 18:30 - Abertura e recepção. 
 19:00 - Lightning Talks 
 20:15 - Coffee break 
 20:30 - Lightning Talks 
 21:40 - Sorteio de prémios 
 21:50 - Fim do evento 
 22:00 - Jantar livre

Data Evento: 20 Aug 2013 - 18:30 
Local do Evento: Microsoft Portugal 

SQL Injection para Totós #1

Um dos ataques informáticos mais eficazes realizados por hackers em todo o mundo é a SQL Injection. Este ataque é muito eficaz porque normalmente é realizado com recurso aos canais legítimos de uma aplicação e como tal é de difícil de deteção. Adicionalmente esta técnica permite um acesso direto à origem dos dados ou seja à Base de Dados.

Na sua essência este ataque consiste em injetar instruções de SQL nos comandos que são executados pela interpretador da Base de Dados e assim obter comportamentos, ou resultados, diferentes daqueles implementados pelo programador. Vamos começar pelo exemplo mais comum:

Imaginemos uma pagina Web de autenticação:



Quando o utilizador introduz os dados e pressiona o botão autenticar o seguinte comando é executado ao nível da BD:



Ora caso seja introduzido o utilizador: Admin e a password: Pa$$w0rd o seguinte comando será executado:



Até aqui tudo bem. O problema acontece quando se começa a jogar com os delimitadores textuais do SQL Server (ou de qualquer outro SGBD). Se por exemplo alguém introduzir na caixa de texto da password o seguinte texto:  ' or ''=' irá dar origem à execução do seguinte comando:



Ora este trata-se de um comando SQL válido que basicamente devolve todos os registos que: possuem o valor admin no campo username e a password é uma string vazia ou (e o importante é ser OU) todos os registos em que a uma cadeia vazia é igual a uma cadeia vazia (ou seja todos os registos).

Um das formas de evitar este tipo de ataques é fazer o escape dos carateres, isto é, aplicar a meta informação necessária por forma a que a informação textual seja interpretada corretamente. Este remédio tem inúmeras lacunas porque basta haver um valor que não seja sanitizado para que toda a BD fique vulnerável. Não basta proteger as páginas de logins pois todos os acesso à BD poderão ser alvo de ataque e provocar o disclosure dos dados das tabelas de utilizadores.

Uma das formas de testarmos as nossas aplicações é utilizar uma ferramenta automatizada que testa (ou tenta ultrapassar) os controlos implementados:

Esta ferramenta permite testar as vulnerabilidades a nível aplicacional no que a esta vulnerabilidade diz respeito (quem sabe um web cast futuro com demonstração da utilização desta ferramenta).

Num próximo post iremos tentar perceber quais as alternativas que temos ao nosso dispor para blindar as nossas aplicações a este tipo de ataque.

SQL Saturday #245 – Rio de Janeiro

Este evento já aconteceu, clique aqui para ver como foi. No último sábado de Agosto, 31/08, teremos um dos melhores eventos de SQL Server ,no Rio de Janeiro. Pra quem

Leia mais...

Clustered Columnstore Indexes – part 17 (“Resources 2012 vs 2014”)

Continuation from the previous 16 parts, starting from http://www.nikoport.com/2013/07/05/clustered-columnstore-indexes-part-1-intro/ Lets compare to check if there were any improvements between the handling of the memory for Columnstore Indexes between SQL Server 2012 & upcoming SQL Server 2014. I will be keep … Continue reading

(TSQL) Função Tira Letras

– ============================================= – Author: Karlos Morais – ============================================= IF exists (SELECT * FROM sysobjects WHERE id = object_id(N’FuFnTiraLetras’) and xtype in (N’FN’, N’IF’, N’TF’)) DROP FUNCTION FuFnTiraLetras GO CREATE FUNCTION FuFnTiraLetras ( @Texto varchar(max) ) RETURNS varchar(max) AS BEGIN DECLARE @Resultado varchar(max) SELECT @Resultado = Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(Replace(@Texto, ‘z’, ”), ‘x’, ”), ‘w’, ”), ‘y’, ”), ‘v’, […]

Clustered Columnstore Indexes – part 16 (“Index Builds”)

Continuation from the previous 15 parts, starting from http://www.nikoport.com/2013/07/05/clustered-columnstore-indexes-part-1-intro/ This post will be dedicated to the process of building Clustered Columnstore Indexes. I will be keep on playing with the Contoso BI database. I have already mentioned in one of … Continue reading

[SQLServerDF] Encontro XVIII – Novidades do SQL Server 2014

Post rápido para continuar com nossas apresentações do SQLServerDF! E dessa vez dou lugar no palco para nosso amigo Luan Moreno.

Local: Auditório da Microsoft - Edifício Corporate Financial Center, Sala 302 – Brasília, CEP 70712-900
Data e horário: 14/08/2013, 17:30h ~ 19:30h
Tema: Novidades do SQL Server 2014
Descrição: Nessa sessão iremos ver novos e interessantes recursos do SQL Server 2014 CTP1. Iremos ver desde a explicação de cada um deles, detalhe de como é utilizado, cenários de aplicação e melhores práticas. Iremos aproveitar para entender o que é o ˜Hekaton˜, novo recurso In-Memory para ambientes OLTP, assim como Buffer Pool Extension, a reformulação do Column Store Index, facilidade de integração com o Windows Azure dentro outros pequenos detalhes.
Palestrante: Luan Moreno M. Maciel
Mini-bio:
Luan Moreno M. Maciel (@LuanSQL) trabalha na B2T (Business to Technology) como Arquiteto de Dados em SQL Server onde atua com administração, desenvolvimento, melhores práticas, gerenciamento, alta disponibilidade e consultoria.

Possui as certificações  CCSQLA, MTAC, MCP, MTA, MCTS, MCITP, MCSA, MCSE Data Platform, MCT. Contribui ativamente com a comunidade nos Fóruns, TechNet Wiki e no seu Blog - http://luanmorenodba.wordpress.com/

Quer participar? Então mande para o grupo SQLServerDF um e-mail confirmando sua presença, pois a capacidade do auditório é limitada, portanto atendemos por ordem de recebimento de e-mails!

Abraços,
http://www.twitter.com/luticm

Vida nova, velhos problemas. Precedência de tipos


Viva, acabaram.se as férias (para mim). Nesta primeira semana dou logo de caras com um problema sobre o qual já falei n vezes em sessões.
Estou a verificar código construído para uma aplicação com a nítida sensação que há qualquer coisa que não está bem. Dou de caras com uma linha do tipo

selectcount(*) from dbo.dimreseller where businesstype like N'val%'

copiado  de algum sitio com certeza...
 A base de dados em causa eu sei que não tem unicode. Qual o significado de uma string precedida por um N como em  N'val%' ? Estamos a dizer ao SQL para enterder essa string como unicode! E então ?

Então acontece algo muito interessante (e que tipicamente não é novidade para os developers), que é a característica de que não só osoperadores têm precedência – a multiplicação é executada antes de soma … - como também o tipo de dados tem precedência quando entre eles:

1.     user-defined data types (highest)
2.     sql_variant
3.     xml
4.     datetimeoffset
5.     datetime2
6.     datetime
7.     smalldatetime
8.     date
9.     time
10.  float
11.  real
12.  decimal
13.  money
14.  smallmoney
15.  bigint
16.  int
17.  smallint
18.  tinyint
19.  bit
20.  ntext
21.  text
22.  image
23.  timestamp
24.  uniqueidentifier
25.  nvarchar (including nvarchar(max) )
26.  nchar
27.  varchar (including varchar(max) )
28.  char
29.  varbinary (including varbinary(max) )
30.  binary (lowest)

isto quer simplesmente dizer que quando por exemplo somamos um int (posição 16 na lista) com um decimal (posição 12) o valor retornado é do tipo decimal.

A questão do query que eu estava a analisar e que se repete no exemplo em cima é que a coluna businesstype é do tipo varchar e a string com a qual a estamos a comparar é do tipo nvarchar(ou nchar). Se olharmos para a lista vemos que quando confrontados, estes dois tipo são tratados como nvarchar pois este tipo tem maior precedência: isto quer dizer que antes de fazer a comparação o SQL vai converter todos os dados da coluna para nvarchar!




como podemos ver no 2º caso é feita uma conversão


que impossibilita a utilização do seek e que faz com que a segunda query seja bastante mais pesada (58% vs 42%)

Neste caso o melhor é ir passando a informação e verificando se estas distrações não estão a acontecer no código.

Os tipos de dados não são para ser deixados ao acaso!

Go to Top