Bom dia pessoal.
Na próxima semana eu estou vou fazer mais uma apresentação virtual para todos aqueles que gostam de SQL Server e SSIS. E o melhor, não sou só eu quem vai falar, na verdade outros 23 feras de SQL Server também estarão falando sobre SQL Server 2008 (e R2).
O evento é uma organização do PASS (Professional Association for SQL Server - http://www.sqlpass.org/) na América Latina. Os detalhes do evento e toda as sessões você pode conferir aqui: http://www.sqlpass-latam.org/24horas.aspx.
Minha apresentação
Título: Padrões de pacotes no SSIS
Descrição: Não falamos muito de padrões de projetos e padrões de arquitetura? Por que não falar sobre padrões de pacotes no SSIS? Nessa sessão eu quero falar um pouco sobre a possibilidade de se reutilizar estruturas comuns para pacotes no SSIS e propor alguns padrões que eu tenho encontrado enquanto estou trabalhando com o Integration Services. Claro que não sou um Fowler ou Gamma, muito longe disso, mas se conseguir com a sessão incentivar alguma coisa em torno do assunto, será muito interessante.
Gostou da proposta? Então pare uma horinha e participe da sessão!
NOTA: As sessões estão marcadas para um horário e nosso fuso está três horas a frente deles, então quando a sessão que se inicia 7:00h para Brasília será 10:00h. Com isso minha sessão será 15:00h amanhã.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
quarta-feira, 13 de outubro de 2010
quinta-feira, 7 de outubro de 2010
Oportunidade Nimbus: Desenvolvedor de soluções na plataforma Microsoft .NET
A Sr. Nimbus é uma empresa de pequeno porte especializada em consultoria e treinamento na plataforma de desenvolvimento Microsoft. Um de nossos objetivos é auxiliar nossos clientes a atingirem o seu potencial máximo no uso das ferramentas desta plataforma. Para isto, temos que ter uma equipe bem preparada e experiente. E um de nossos desejos é conseguir este tipo de profissional através de nossas “categorias de base”: realizar a preparação e orientação de profissionais promissores, mas ainda sem grande contato com o mercado.
Nosso processo de trabalho emprega as seguintes disciplinas:
Se você se interessou, mande seu currículo para gilberto.uchoa@srnimbus.com.br.
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Nosso processo de trabalho emprega as seguintes disciplinas:
- Framework para gerenciamento de projetos: SCRUM (http://www.scrum.org/scrumguides/);
- Automação do ciclo de desenvolvimento de software: Microsoft Team Foundation Server 2010 (http://msdn.microsoft.com/en-us/library/fda2bad5.aspx);
- Desenvolvimento de aplicação para o Windows Azure (http://www.microsoft.com/windowsazure/)
- Desenvolvimento ASP.NET;
- TDD – Test-Driven Development (http://www.agiledata.org/essays/tdd.html);
- Microsoft Visual Studio 2010 como ambiente de desenvolvimento.
Estamos com uma vaga aberta na área de desenvolvimento de soluções. Os pré-requisitos da vaga são:
- Experiência em desenvolvimento C#.
- Experiência em desenvolvimento ASP.NET.
Nosso objetivo para este profissional é a formação de um consultor especializado nas principais tecnologias das plataformas de desenvolmimento Microsoft: .NET Framework, Windows Azure e SharePoint. A formação envolverá cursos, self-study, shadowing de nossos consultores sêniores nos seus atendimentos, além de, é claro, muita “mão-na-massa”.
Se você se interessou, mande seu currículo para gilberto.uchoa@srnimbus.com.br.
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
sexta-feira, 1 de outubro de 2010
SQL Server 2008 R2 install - Could Not Find Database Engine Startup Handle
Hoje eu resolvi montar uma nova VM e comecei pela instalação do SQL Server 2008 R2 em uma máquina virtual. Estou rodando o VirtualPC 2007 SP1 no Win 7 x64 e a máquina virtual está rodando o Windows Server 2008.
Seguindo normalmente a instalação que já fiz 48934932 vezes, tudo ia bem até que “Could Not Find Database Engine Startup Handle”. As ferramentas eram instaladas, mas a engine relacional nada. Fiz alguns testei, mudei algumas coisas e nada! Sempre que tentava instalar o SQL Server ele parava no mesmo ponto.
Pesquisando um pouco encontrei este artigo que me foi útil: http://www.msbicentral.com/Resources/Articles/tabid/88/articleType/ArticleView/articleId/80/FLASH-SQL-Server-2008-R2-Error-Could-Not-Find-Database-Engine-Startup-Handle.aspx.
Para não queimar uma mídia peguei o ISO, fiz um extract com o WinRar e copiei os arquivos para dentro da VM. Reiniciei a instalação e tudo funcionou perfeitamente.
Espero que possa ajudar.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Seguindo normalmente a instalação que já fiz 48934932 vezes, tudo ia bem até que “Could Not Find Database Engine Startup Handle”. As ferramentas eram instaladas, mas a engine relacional nada. Fiz alguns testei, mudei algumas coisas e nada! Sempre que tentava instalar o SQL Server ele parava no mesmo ponto.
Pesquisando um pouco encontrei este artigo que me foi útil: http://www.msbicentral.com/Resources/Articles/tabid/88/articleType/ArticleView/articleId/80/FLASH-SQL-Server-2008-R2-Error-Could-Not-Find-Database-Engine-Startup-Handle.aspx.
Para não queimar uma mídia peguei o ISO, fiz um extract com o WinRar e copiei os arquivos para dentro da VM. Reiniciei a instalação e tudo funcionou perfeitamente.
Espero que possa ajudar.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
sexta-feira, 24 de setembro de 2010
Internet Explorer 9 e a zica com o firewall
Não gosto de postar sobre coisas sem solução, mas gostaria de ouvir se mais alguém teve um problema semelhante ao meu. Pesquisei e nada encontrei.
Ontem eu instalei o IE9 e comecei a brincar com o bichinho, de cara descobri que existe um problema de compatibilidade com o Dynamic CRM 4.0 e precisei usar um sandbox do IE8 (www.spoon.net) para resolver meu problema (e não, modo de compatibilidade não é suficiente!), inclusive em um rollup do CRM temos algumas coisas voltadas para o IE9 (http://blogs.msdn.com/b/crm/archive/2010/09/23/update-rollup-13-for-microsoft-dynamics-crm-4-0.aspx).
Até aí tudo bem, mas hoje cedo encontrei um problema em que eu não conseguia acessar nenhuma máquina por TS ou acessar um SQL Server remoto. Se tentasse de outra estação tudo funcionava corretamente, mas nada da minha máquina. Claramente um problema aqui, verificamos a rota de uma requisição e chegamos até um log do firewall Aker, que mostrava:
Eita, flags TCP do pacote são inválidos?! Pesquisei e nada achei, até que descobri outro caso semelhante com um amigo e ele havia resolvido o problema removendo o IE9. Cético, removi o IE9 e... tudo funcionou! Que droga.
Não sei detalhes sobre o motivo do acontecido, mas pesquisei e nada encontrei. Seria algo do IE9? Do firewall Aker? Se você souber de algo ou um workaround, favor me avisar.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Ontem eu instalei o IE9 e comecei a brincar com o bichinho, de cara descobri que existe um problema de compatibilidade com o Dynamic CRM 4.0 e precisei usar um sandbox do IE8 (www.spoon.net) para resolver meu problema (e não, modo de compatibilidade não é suficiente!), inclusive em um rollup do CRM temos algumas coisas voltadas para o IE9 (http://blogs.msdn.com/b/crm/archive/2010/09/23/update-rollup-13-for-microsoft-dynamics-crm-4-0.aspx).
Até aí tudo bem, mas hoje cedo encontrei um problema em que eu não conseguia acessar nenhuma máquina por TS ou acessar um SQL Server remoto. Se tentasse de outra estação tudo funcionava corretamente, mas nada da minha máquina. Claramente um problema aqui, verificamos a rota de uma requisição e chegamos até um log do firewall Aker, que mostrava:
Eita, flags TCP do pacote são inválidos?! Pesquisei e nada achei, até que descobri outro caso semelhante com um amigo e ele havia resolvido o problema removendo o IE9. Cético, removi o IE9 e... tudo funcionou! Que droga.
Não sei detalhes sobre o motivo do acontecido, mas pesquisei e nada encontrei. Seria algo do IE9? Do firewall Aker? Se você souber de algo ou um workaround, favor me avisar.
[]s
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
segunda-feira, 20 de setembro de 2010
Sim, é um deadlock
Se você prefere ler o artigo em PDF, baixe aqui.
Revisando os posts da última semana eu encontrei um post interessante do nosso amigo Alexandre Lopes, que mostra um exemplo bem legal de deadlock. O post na íntegra está aqui: http://sqlserverday.com.br/alopes/?p=924 e aconselho lê-lo antes de continuar com
este post. Leu tudo? Então vamos a uma análise mais detalhada.
Monitorando com o profiler os eventos lock:acquired e lock:released, execute no banco de dados AdventureWorks a consulta “SELECT * FROM Sales.CurrencyRate” e veremos (Figura 01) que o lock manager optou por pegar um bloqueio de página, então temos um IS no objeto e, durante a leitura dos registros, o SQL Server vai pegando e liberando os bloqueios compartilhados na medida em que os registros das páginas são lidos.
(Figura 01)
Agora vamos ao deadlock, com base no script abaixo:
(Script 01)
USE AdventureWorks
go
select @@TRANCOUNT
-- Conexão 01
BEGIN TRAN
UPDATE Sales.CurrencyRate SET AverageRate = 2 WHERE CurrencyRateID =1
SELECT * FROM Sales.CurrencyRate
-- Script 02
BEGIN TRAN
UPDATE Sales.CurrencyRate SET AverageRate = 2 WHERE CurrencyRateID = 1
Quando iniciamos a transação da conexão 01 e executamos o primeiro update, veremos o SQL Server pegando um lock exclusivo no registro e IX na página e tabela (Figura 02).
(Figura 02)
Se a partir de outra conexão executarmos o mesmo comando de update, o que é de se esperar? Que o SQL Server requisite os mesmos recursos e a transação fique bloqueada pelo registro exclusivo colocado sobre a chave. Vejamos a saída do SP_LOCK para análise na figura 03.
(Figura 03)
Vemos claramente que a conexão de SPID 55 ficou bloqueada (WAIT) esperando que a conexão 52 libere o bloqueio exclusivo sobre o registro que está sendo atualizado. Outro ponto que eu quero chamar a atenção é para o bloqueio IX da página 1040, que foi concedido para a transação de SPID 55.
Se buscarmos no BOL o tópico “Lock Compatibility” veremos que IX são compatíveis com IX e até existe uma nota sobre isso: “An intent exclusive (IX) lock is compatible with an IX lock mode because IX means the intention is to update only some of the rows rather than all of them. Other transactions that attempt to read or update some of the rows are also permitted as long as they are not the same rows being updated by other transactions”.
Porém se analisarmos a tabela de compatibilidade, veremos que o bloqueio compartilhado (S) não é compatível com o IX, pois eu não poderia ler uma página em que algum registro estivesse sendo alterado, seria uma leitura suja não compatível com o nível de isolamento read committed. Acho que vocês já devem ter percebido onde eu quero chegar...
Se nesse momento nós voltarmos para a primeira transação que está com o bloqueio exclusivo no registro e executarmos o SELECT para buscar todos os registros, o que veremos? Sim senhor, um deadlock. E os recursos envolvidos são detalhados na figura 04.
(Figura 04)
Analisando a saída acima, vemos as sessões 52 e 55 se bloqueando, então estamos em uma situação de deadlock, onde o SQL Server deve escolher uma vítima. Os recursos envolvidos são o registro bloqueado pelo lock exclusivo e a página 1040, onde a transação do SPID 52 fica bloqueada com o status CNVT (Convert). Pela documentação do SQL Server: “CNVRT: The lock is being converted from another mode, but the conversion is blocked by another process holding a lock with a conflicting mode”.
Então o deadlock aconteceu porque estamos trabalhando em níveis de granularidade diferentes, um na página e outro no registro! Se o que eu acabei de afirmar for verdade, esse tipo de deadlock pode ser resolvido com uma hint no SELECT, onde indicamos que o SQL Server deve pegar bloqueios de registros, e não de página: “SELECT * FROM Sales.CurrencyRate (ROWLOCK)”. Faça o teste e verá que realmente dessa forma o deadlock não irá acontecer.
No fim eu gostei bastante de fazer essa pequena análise, pois é um excelente exemplo (e não muito comum) de um deadlock que o Alexandre trouxe para nós, possibilitando mostrar para vocês um pouco mais do SQL Server e seu funcionamento.
Abraços e até um próximo artigo.
[]s
Luciano Caixeta Moreira - {Luti} luciano.moreira@srnimbus.com.br www.twitter.com/luticm www.srnimbus.com.br
Revisando os posts da última semana eu encontrei um post interessante do nosso amigo Alexandre Lopes, que mostra um exemplo bem legal de deadlock. O post na íntegra está aqui: http://sqlserverday.com.br/alopes/?p=924 e aconselho lê-lo antes de continuar com
este post. Leu tudo? Então vamos a uma análise mais detalhada.
Monitorando com o profiler os eventos lock:acquired e lock:released, execute no banco de dados AdventureWorks a consulta “SELECT * FROM Sales.CurrencyRate” e veremos (Figura 01) que o lock manager optou por pegar um bloqueio de página, então temos um IS no objeto e, durante a leitura dos registros, o SQL Server vai pegando e liberando os bloqueios compartilhados na medida em que os registros das páginas são lidos.
(Figura 01)
Agora vamos ao deadlock, com base no script abaixo:
(Script 01)
USE AdventureWorks
go
select @@TRANCOUNT
-- Conexão 01
BEGIN TRAN
UPDATE Sales.CurrencyRate SET AverageRate = 2 WHERE CurrencyRateID =1
SELECT * FROM Sales.CurrencyRate
-- Script 02
BEGIN TRAN
UPDATE Sales.CurrencyRate SET AverageRate = 2 WHERE CurrencyRateID = 1
Quando iniciamos a transação da conexão 01 e executamos o primeiro update, veremos o SQL Server pegando um lock exclusivo no registro e IX na página e tabela (Figura 02).
(Figura 02)
Se a partir de outra conexão executarmos o mesmo comando de update, o que é de se esperar? Que o SQL Server requisite os mesmos recursos e a transação fique bloqueada pelo registro exclusivo colocado sobre a chave. Vejamos a saída do SP_LOCK para análise na figura 03.
(Figura 03)
Vemos claramente que a conexão de SPID 55 ficou bloqueada (WAIT) esperando que a conexão 52 libere o bloqueio exclusivo sobre o registro que está sendo atualizado. Outro ponto que eu quero chamar a atenção é para o bloqueio IX da página 1040, que foi concedido para a transação de SPID 55.
Se buscarmos no BOL o tópico “Lock Compatibility” veremos que IX são compatíveis com IX e até existe uma nota sobre isso: “An intent exclusive (IX) lock is compatible with an IX lock mode because IX means the intention is to update only some of the rows rather than all of them. Other transactions that attempt to read or update some of the rows are also permitted as long as they are not the same rows being updated by other transactions”.
Porém se analisarmos a tabela de compatibilidade, veremos que o bloqueio compartilhado (S) não é compatível com o IX, pois eu não poderia ler uma página em que algum registro estivesse sendo alterado, seria uma leitura suja não compatível com o nível de isolamento read committed. Acho que vocês já devem ter percebido onde eu quero chegar...
Se nesse momento nós voltarmos para a primeira transação que está com o bloqueio exclusivo no registro e executarmos o SELECT para buscar todos os registros, o que veremos? Sim senhor, um deadlock. E os recursos envolvidos são detalhados na figura 04.
(Figura 04)
Analisando a saída acima, vemos as sessões 52 e 55 se bloqueando, então estamos em uma situação de deadlock, onde o SQL Server deve escolher uma vítima. Os recursos envolvidos são o registro bloqueado pelo lock exclusivo e a página 1040, onde a transação do SPID 52 fica bloqueada com o status CNVT (Convert). Pela documentação do SQL Server: “CNVRT: The lock is being converted from another mode, but the conversion is blocked by another process holding a lock with a conflicting mode”.
Então o deadlock aconteceu porque estamos trabalhando em níveis de granularidade diferentes, um na página e outro no registro! Se o que eu acabei de afirmar for verdade, esse tipo de deadlock pode ser resolvido com uma hint no SELECT, onde indicamos que o SQL Server deve pegar bloqueios de registros, e não de página: “SELECT * FROM Sales.CurrencyRate (ROWLOCK)”. Faça o teste e verá que realmente dessa forma o deadlock não irá acontecer.
Conclusão
O comportamento do SQL Server está correto e é realmente um deadlock, então vou discordar do Alexandre em relação à qualidade do produto e que não existe um deadlock, mas sim tentar pensar como um program manager do produto. Qual é o maior ganho para o SQL Server? Permitir bloqueios de registro e utilizar o IX para indicar que existe algum recurso com menor granularidade sendo bloqueado (acelerando a análise de compatibilidade dos bloqueios) ou evitar esse comportamento impedindo bloqueios de registro ou análises custosas de compatibilidade de bloqueios em diferentes níveis (imagine bilhões de registros, um bloqueio exclusivo em um registro e outra transação pedindo um bloqueio compartilhado na tabela). Eu também ficaria com o row lock.No fim eu gostei bastante de fazer essa pequena análise, pois é um excelente exemplo (e não muito comum) de um deadlock que o Alexandre trouxe para nós, possibilitando mostrar para vocês um pouco mais do SQL Server e seu funcionamento.
Abraços e até um próximo artigo.
[]s
Luciano Caixeta Moreira - {Luti} luciano.moreira@srnimbus.com.br www.twitter.com/luticm www.srnimbus.com.br
Assinar:
Postagens (Atom)