Esse artigo faz parte da revista SQL Magazine edição 01. Clique aqui para ler todos os artigos desta edição

Os melhores recursos para Replicação

Replicação é uma feature importantíssima nos SGBD’s atuais - consiste em copiar, distribuir e manter a sincronia entre dados, estes normalmente situados em servidores distintos.

O modelo desenvolvido pela Microsoft para o SQL Server, que desde a versão 6.0 agregou replicação de dados em seu engine, será o enfoque nesta edição.

No mundo corporativo, a replicação de dados está nitidamente ligada a ambientes distribuídos, onde o acesso a dados básicos (descrição de um produto numa loja, por exemplo) é feito no próprio local da consulta. Acessando dados localmente, reduzimos a possibilidade de conflitos e otimizamos tráfego de dados nos links de comunicação entre as instalações distribuídas, que muitas vezes constituem gargalos nos sistemas.

A escolha do modelo de replicação adequado depende das características do negócio. Considere-se uma empresa com gestão de preços centralizada chamada “Corp”, com matriz de mesmo nome em São Paulo-SP e filiais no Paraná-PR, Rio de Janeiro-RJ e Rio Grande do Sul-RS.  Abaixo, seguem algumas perguntas que direcionam na escolha do modelo apropriado:

a)     A distribuição de dados deve ser efetuada de maneira unilateral (da base central para as filiais) ou a própria loja poderá alterar o preço dos produtos? Se a própria loja alterar o preço de um produto, será preciso distribuí-lo para as demais?

b)     Qual a latência desejável para sincronia dos dados?

c)     As filiais devem receber somente os preços praticados naquele local ou uma loja deve possuir acesso aos preços praticados em toda a rede?

d)     A sincronização deve ser feita sempre para toda a lista de produtos ou somente para os produtos cujo preço foi alterado?

A Microsoft, em face desses questionamentos, sugere três modelos para réplica de dados - Transacional, Merge e Snapshot - que serão analisados tomando por base a empresa fictícia “Corp”, onde toda a rede pratica a mesma política de preços, ditada pela matriz em atualizações semanais de listas.

O Modelo Transacional

Como o próprio nome sugere, esse modelo baseia-se na atualização das filiais a partir do log de transações copiado do servidor principal. Ao atualizar o preço de um produto em “Corp” (figura-1), o log do comando que gerou essa alteração será copiado para uma base específica (“Distrib”), para posterior distribuição nas filiais de RJ, PR e RS. Resumidamente, a replicação transacional armazena e distribui comandos de manipulação de dados (Insert/Update/Delete) nas tabelas assinaladas para réplica de dados. Note que a atualização é unidirecional (Central => Filiais).

Figura 1

O Modelo Snapshot

Na replicação Snapshot, os objetos são exportados integralmente a cada execução de um job específico no distribuidor, também conhecido como “agente de sincronização”. Isto significa que as listas de preços nas filiais seriam substituídas semanalmente por cópias atualizadas, independentemente de alteração de preços.

Essa modalidade de replicação não controla atualizações, inserções e/ou deleções; simplesmente substitui uma cópia por outra.

Figura 2

O Modelo Merge

Baseia-se em triggers criadas nas tabelas replicadas. Essas triggers fazem a movimentação de dados para tabelas de sistema responsáveis pela sincronização entre as bases replicadas. Os Jobs ou “Agentes de Sincronização” que, no modelo snapshot eram específicos do distribuidor, agora funcionam em todas as instalações distribuídas. Eles identificam as alterações e desencadeiam o processo de atualização nas bases replicadas. Observe-se que, na figura-3, o preço Y, alterado diretamente no ponto de venda PR, deve ser atualizado primeiramente em “Corp” para que depois seja sincronizado com os outros pontos.

Um fato interessante diz respeito ao que aconteceria se, na empresa “Corp”, após uma reestruturação, fosse permitido que as filiais tivessem autonomia para alterar e divulgar preços para as outras filiais e, conseqüentemente, em duas filiais, o preço de um mesmo produto fosse alterado para valores diferentes. Na sincronização semanal, surgiria um impasse: que preço aplicar para a rede? O mais baixo? Aquele que foi primeiramente registrado? A replicação merge possui um tratamento especial para conflitos, que permite rastrear e resolver esse tipo de problema. O algorítmo é bastante simples: na criação do modelo, são definidas prioridades para cada participante, vencendo quem possuir a maior. Se o preço do produto X for alterado na filial  RJ (prioridade 0.3) para R$ 4,00, e na filial RS (prioridade 0.8) para R$5,00, na ocasião do conflito o preço da filial RS seria vencedor, sendo então repassado para a rede.

Figura 3

Segue agora um exemplo prático para criação do processo de replicação. Serão definidas, passo a passo, as etapas existentes na criação de um modelo que atenda a empresa “Corp” na distribuição de listas de preços para suas filiais.

O primeiro passo é registrar no Enterprise Manager todos os servidores envolvidos (\\Corp, \\Distrib, \\PR, \\RJ e \\RS )  com uma conta que possua privilégios de “system administrator”, aqui chamada de “replicador”, especialmente criada para esse fim.

Definição do distribuidor

A replicação é um processo complexo que envolve agentes específicos para o controle das diversas operações. O passo inicial é, portanto, definir um servidor, aqui chamado de Distribuidor, para gerenciar esses agentes. As atribuições de um distribuidor envolvem armazenamento, distribuição e controle das cópias de dados. É aconselhável que o Distribuidor esteja num servidor separado do banco de dados por questões de segurança (uma vez que ele precisa ter acesso as instalações distribuídas e, se o banco de dados estivesse fisicamente na mesma máquina, teríamos o risco do acesso indevido a dados da base corporativa) e também da otimização do processamento tanto do distribuidor, que executa os jobs referentes a replicação, quanto do banco de dados que, se acessado por outros clientes, não teria sua performance prejudicada. No servidor \\Distrib, selecione Replication\ ConfigurePublishing . Na próxima tela confirme Make “Distrib” its own Distributor  e prossiga (Vide Figura 4).

Figura 4

Figura 5

“Snapshot Folder” é uma pasta que deve ser criada no distribuidor para armazenamento temporário do schema e dados para inicialização das subscrições (como podemos chamar as filiais receptoras das atualizações). Deve ser uma pasta pública e visível pelas subscrições.  (Vide Figura 5).

Pra prosseguir selecione No, user the following default settings em Customize Configuration.

Definição do publicador, publicação e modelo de réplica

É necessário definir que o servidor \\Corp (onde é efetuado o cadastro e alteração das listas de preços), utilizará os serviços de \\Distrib  para divulgação das listas nas filiais. Nesse contexto, \\Corp passa a ser chamado de “Publicador”, por ser responsável pela publicação da lista de preços.

Inicialmente, é preciso liberar o acesso de \\Corp aos serviços do distribuidor. Para isso, na máquina \\Distrib, entre no Enterprise Manager e clique com o botão direito do mouse em Replication. No menu, selecione “Configure Publishing, Subscribers and Distributor”  e escolha a guia Publishers conforme a figura 6.

Tuning - Plano de Execução - Parte 2

Olá!

Aprenderemos agora a efetuar a leitura do Plano de Execução Gráfico de uma query, assunto que iniciei na coluna anterior.

A leitura de um plano de execução deve ser efetuada da direita para a esquerda e de cima para baixo. Cada objeto sinaliza uma operação distinta, e existem setas indicando o caminho a seguir. Vamos analisar o plano de um select na tabela Orders , localizado no database NorthWind :

PS: Para geração do plano, selecione Query...Display Estimated Execution Plan na barra de ferramentas do Query Analyzer ou aperte em conjunto +L

O simbolo indica que está sendo efetuada uma varredura sequencial na tabela Orders (=Clustered Index Scan) , tendo por base o índice cluster PK_Orders.

O símbolo  indica que após o processo de varredura sequencial na tabela Orders , o resultado da seleção será apresentado ao cliente.

Vamos buscar informações de outro empregado na tabela Orders e observar o plano de execução:

Nesse plano existe dois simbolos novos: representa um processo de Index Seek , e indica que a busca do empregado para employeeId=9 foi uma busca pontual, realizada com o auxílio de um índice não-cluster.

Verificando a composição do índice utilizado na pesquisa com o comando sp_HelpIndex Orders , nota-se que esse índice é composto apenas pela coluna employeeId . Como a query executada necessita de todas as colunas da tabela Orders , será necessário acessar a página de dados através de um ponteiro localizado na estrutura do índice. Esse processo de busca da página de dados à partir de ponteiros localizados na estrutura do índice é conhecido por bookmark lookup, representado no plano de execução pelo símbolo.

Variáveis tipo Table

Definição

Variável tipo TABLE nada mais é do que um tipo especial de variável que pode ser utilizada para armazenamento temporário de dados, de maneira similar a tabelas temporárias.

Vantagens

·         Devido à sua utilização estritamente local, tabelas criadas a partir de variáveis tipo TABLE não consomem recursos para controle de bloqueios;
·         A manipulação de dados em variáveis tipo TABLE é mais eficiente porque essas operações são minimamente logadas (um ROLLBACK após um INSERT não tem efeito em variáveis tipo TABLE);
·         Em função do seu escopo local, procedures que se utilizam de variáveis tipo TABLE estão sujeitas a um número menor de recompilações quando comparadas às tabelas temporárias.

Desvantagens

·         A vida útil de uma tabela criada a partir de uma variável tipo TABLE está limitada ao batch e/ou procedure onde é utilizada;
·         Com variáveis tipo TABLE não é permitido:
§         Criação de índices não-cluster,
§         Criação de constraints CHECK, DEFAULT;
§         Criação e/ou atualização de esta

Subqueries Parte II: Queries correlatas

No artigo anterior – Subqueries Parte I – vimos que uma subquery é um comando SELECT que foi "embutido" noutro comando SELECT, UPDATE, DELETE ou dentro de outra subquery. Vimos também que a finalidade da subquery é retornar um conjunto de linhas para a query principal.

Subqueries Correlatas

Quando uma subquery referencia colunas da query principal, recebe o nome de Subquery Correlata.

Diferentemente das subqueries convencionais, a Subquery Correlata será executada tantas vezes quantas forem as linhas de output da query principal, num processo de Nested Loop Join.

Exemplos de utilização de Subqueries Correlatas

Os exemplos a seguir foram executados no database-exemplo NorthWind tendo por base as tabelas Orders e Order Details.

·         Subquery Correlata na linha do SELECT: na query a seguir será listado, junto com os dados da header do pedido (=tabela Orders), a totalização de itens (=tabela Order Details).

PS: Note a relação de dependência com a query principal no filtro da subquery (... where od.orderId = o.orderId ...)

SELECT
  customerId,
  orderId,
  qtde_itens_orderId = (select sum(quantity) from [order details] od     whereod.orderId = o.orderId )
from Orders o
---------------------------------------------------------------------

customerId orderId     qtde_itens_orderId
---------- ----------- ------------------
ALFKI         10643          38
ALFKI         10692          20
ALFKI         10702          21
ALFKI         10835          17
ALFKI         10952          18
ALFKI         11011          60
ANATR        10308          6
ANATR        10625          18
ANATR        10759          10
.
...
.....

Subqueries – Parte I

O que é uma subquery ?

Subquery é um comando SELECT que foi "embutido" noutro comando SELECT, UPDATE, DELETE ou dentro de outra subquery.

A finalidade da subquery é retornar um conjunto de linhas para a query principal

Utilização

Tipicamente utilizamos subqueries na filtragem de pesquisas (=cláusula WHERE) nas cláusulas IN() e EXISTS(), mas subqueries também podem aparecer também na cláusula FROM ou como substituto de expressões. Exemplos:

• Utilizando uma subquery em conjunto com a cláusula IN().

select *
from [order details]
where orderid IN (select orderid from orders where CustomerID='VINET')

---------------------------------------------------------------------
OrderID        ProductID         UnitPrice             Quantity Discount
----------- ----------- --------------------- -------- --------------
10248             11                14.0000                  12       0.0
10248             42                9.8000                   10       0.0
10248             72                34.8000                  5        0.0
10274             71                17.2000                  20       0.0
10274             72                27.8000                  7        0.0
10295             56                30.4000                  4        0.0
10737             13                6.0000                   4        0.0
10737             41                9.6500                   12       0.0
10739             36                19.0000                  6        0.0
10739             52                7.0000                   18       0.0

• Utilizando uma subquery em conjunto com a cláusula EXISTS().

Gerenciando Bloqueios–Parte II

Os métodos convencionais utilizados no rastreamento de bloqueios nem sempre são eficientes:

• A visualização de processos e/ou bloqueios ativos pelo Enterprise Manager não possui boa performance durante picos de utilização do servidor;
• Quando existem muitas conexões ativas, identificar a conexão responsável pela avalanche de travamentos pode consumir um tempo precioso: as procedures SP_WHO, SP_WHO2 e SP_LOCK e Enterprise Manager não possuem um mecanismo eficiente para solucionar esse problema. Sabemos que a conexão 52 está travada pela 65, que a 32 está bloqueada pela 433, ....., mas não somos informados “de maneira explícita” que o spid 34 é quem está ocasionando todos esses bloqueios.

Analisando tabela de sistema SYSPROCESSES

Quando os modelos prontos não atendem nossas necessidades, temos que partir para soluções específicas, feitas sob encomenda para nossas necessidades – é aí que entra a tabela de sistema SYSPROCESSES.

A tabela de sistema SYSPROCESSES localizada no database MASTER é responsável por armazenar o metadata de todos os processos ativos no servidor SQL Server 2000 (ver Figura 1)

Figura 1. Select na tabela de sistema SYSPROCESSES.

Bem, e daí? Como a tabela SYSPROCESSES poderia ajudar a resolver a questão do travamento?

A coluna BLOCKED na tabela SYSPROCESSES (ver Figura 1) pode ser utilizada para rastrear o spid responsável pelos bloqueios da seguinte forma:

• ...

Gerenciando Bloqueios–Parte I

O controle de bloqueios é uma atividade desenvolvida pelo Lock Manager, um dos componentes do SQL Server 2000 Relational Engine. Bloqueios são fundamentais para garantir o isolamento necessário às transações, mas cabe ao DBA ou responsável pelo banco estabelecer um método eficiente para identificar as conexões e, numa análise mais detalhada, os processos responsáveis por bloqueios de longa duração.

A verificação de bloqueios é uma ação passiva, isto é, o travamento só pode ser detectado DEPOIS  que acontece. Já que não podemos eliminar a questão do travamento, deveremos trabalhar em duas frentes:

1.      A curto prazo: detectar e eliminar travamentos, de preferência ANTES das reclamações de usuários.

2.      A médio prazo: analisar o porquê dos travamentos, promovendo mudanças no modelo de dados e no código das transações.

Essa matéria será dividida em duas partes: na primeira serão apresentados alguns métodos “prontos” para identificação de bloqueios. Na segunda parte será proposto um modelo simples para identificação do processo bloqueador, assim como o comando responsável pelo travamento. O assunto será finalizado com dicas para minimizar travamentos.

Métodos para detecção de travamentos

 O Enterprise Manager

O método mais simples para identificar a conexão responsável por um travamento nos leva ao Enterprise Manager em Manangement\Currenct Activity. Na Figura 1, pode-se observar que o spid 52 está sendo bloqueado pelo 54.

Figura 1. Utilizando o Enterprise Manager na identificação de bloqueios

A opção do Enterprise Manager – apesar da magnífica apresentação - mostra-se pouco eficiente:

Tabelas Temporárias
por Paulo Ribeiro

Tabelas Temporárias, como o próprio nome sugere, são tabelas utilizadas para armazenamento provisório de dados.

Como criar

Tabelas Temporárias são criadas no database TempDB e podem ser classificadas em Locais e Globais:

·         Tabelas Temporárias Locais são criadas com o prefixo "#" e possuem visibilidade restrita para a conexão responsável por sua criação; outras conexões não "enxergam" a tabela.
·         Tabelas Temporárias Globais são criadas com o prefixo "##" e são visíveis por todas as conexões

Nos dois casos, o database TempDB não deve ser referenciado como parte do nome da tabela.

Como dropar

Uma tabela temporária (Local ou Global) só existe enquanto a conexão responsável pela sua criação estiver ativa. O momento da desconexão, tabelas temporárias remanescentes serão dropadas automaticamente.

Exemplos de utilização

Exemplo-1:

create table #temp
( cod_cli int,
  nome_cli varchar(50)
)
insert into #temp values (1,'Livia')
select * from #temp

Exemplo-2:

select ano = year(OrderDate), qtde_pedidos = count(*)
into ##temp
from northwind.dbo.orders
group by ye

Explorando os Tipos de Join – Parte II

Olá !

Com o auxílio da figura-1 listada a seguir e, à partir do script para criação das tabelas produto (cod_ produto , descr_ produto ) e venda (cod_ produto , qtde, vlr_unit) forcecido na matéria anterior (Explorando os tipos de Join  – Parte I)  ...

... vamos praticar a execução diferentes tipos de join para responder as questões a seguir :

1. Listar os produtos que foram vendidos e possuem cadastro

A resposta está na interseção entre produto e venda, representado na figura-1 pela cor verde . Será resolvido com um inner join :

select produtos_vendidos_com_cadastro = p.cod_produto
from produto p
inner join
    venda v
on p.cod_produto = v.cod_produto
--------------------------------------------------------------------------------------------------------------------------------------------
produtos_vendidos_com_cadastro
-----------------------------------------------
101001
101002
101003
(3 row(s) affected)

2.      Listar os produtos que foram vendidos sem cadastro

Deveremos resgatar os produtos da área em azul , que não possuem correspondência na tabela produto . Será utilizado um right join para selecionar todas as linhas da tabela venda ;  o filtro .... ... where p.cod_ produto is null nos permitirá filtrar somente as vendas de produtos sem cadastro :

select produtos_vendidos_sem_cadastro = v.cod_produto
from produto p
right outer join
      venda v
on v.cod_produto = p.cod_produto
where p.cod_ produto IS NULL
-------------------------------------------------------------------------------------------------------------------------------------------
produtos_vendidos_sem_cadastro
-----------------------------------------------
101030
101031
(2 row(s) affected)

3. Listar os produto com cadastro que NÃO foram vendidos

A resposta para essa pergunta está na área em vermelho da figura-1. Para sua resolução foi empregado um left join , mas o mesmo resultado poderia ser obtido com um right join , bastando para isso inverter a ordem das tabelas   ... from venda v right outer join  produto p on ....

select produtos_com_cadastro_sem_venda = p.cod_produto
from produto p
left outer join
      venda v
on v.cod_produto = p.cod_produto
where v.cod_produto IS NULL

produtos_com_cadastro_sem_venda
-------------------------------
101004
101005

Explorando os Tipos de Join – Parte I

Olá !

Join é a ferramenta básica de trabalho nos bancos de dados relacionais. É através dos diferentes tipos de join que conseguimos recuperar dados de uma ou mais tabelas com o auxílio dos relacionamentos existentes.

Nessa matéria discutiremos os 4 modêlos de join (inner join, left join, right join e full outer join);  aprenderemos também como escolher o tipo certo de join para cada situação.

Para os exemplos a seguir serão consideradas duas tabelas : produto e venda. A tabela venda - como o prórpio nome sugere - irá registrar vendas de itens cadastrados na tabela produto, mas pela característica do negócio também serão permitidas vendas de produtos sem cadastro.

O script abaixo irá criar e popular as tabelas venda e produto:

/* criação da tabela produto */
create table produto
(
cod_produto int primary key,
descr_produto varchar (20)
)

/* criação da tabela venda.*/

create table venda
(
id_venda int identity primary key,
cod_produto int ,
qtde int,
vlr_unit dec(9,2)
)

/* populando a tabela produto */

insert into produto values (101001,'Livro-1')
insert into produto values (101002,'Livro-2')
insert into produto values (101003,'Livro-3')
insert into produto values (101004,'Livro-4')
insert into produto values (101005,'Livro-5')

/* populando a tabela venda */

insert into venda (cod_produto,qtde,vlr_unit)  values (101001,2,14.00)
insert into venda (cod_produto,qtde,vlr_unit)  values
(101002,1,20.50)
insert into venda (cod_produto,qtde,vlr_unit)  values
(101003,4,12.00)
insert into venda (cod_produto,qtde,vlr_unit)  values (101030,6,
8.00)
insert into venda (cod_produto,qtde,vlr_unit)  values
(101031,1,44.00)

O relacionamento entre as tabelas produto e venda pode ser visualizado na figura-1.

Figura-1: Relacionamento entre as tabelas produto e venda

Versões existentes do SQL Server 2000

Olá!

O SQL Server 2000 pode ser encontrado sob diversas versões. Essas versões diferenciam-se quanto à capacidade dos databases, número de processadores e a existência ou não de componentes para gerenciamento e Data Warehousing. Outro item importante diz respeito à utilização do produto: existem versões para desenvolvimento, para servidores corporativos, para serem distribuídas de forma “embutida” com aplicações, etc.

Podemos dividir as versões do SQL Server 2000 em dois grandes grupos: Cliente-Servidor e outro que convencionaremos chamar de Grupo Especial, que detalharemos a seguir:

Versões para utilização em ambiente cliente-servidor

Segundo definição da Microsoft “ ... as versões Standard e Enterprise são as únicas edições do SQL Server 2000 formatadas para utilização client-server ...” A instalação dessas versões exige a existência de sistemas operacionais de servidores: Microsoft Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, Windows Server 2003 Datacenter Edition, 64-bit versions of Windows Server 2003 Enterprise and Datacenter Editions, Windows ® 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT ® Server 4.0, ou Windows NT Server 4.0 Enterprise Edition.

A Microsoft faz questão de frisar que um ambiente de produção client-server é diferente de ambientes de “desenvolvimento” ou “testes”, posição em que se enquadram as versões especiais.

·         SQL Server 2000 Standard Edition

Versão indicada para pequenas e médias empresas, consegue acessar até 2GB de memória e pode ser utilizada em máquinas multi-processadas respeitando o limite de 4 processadores. Dentre suas principais características, podemos citar:

·         Ferramentas gráficas para administração e desenvolvimento (Query Analyzer e Enterprise Manager) Replicação de Dados;

·         Ferramenta gráfica extrair, transportar e consolidar dados multi-plataforma (DTS);

·         Suporte nativo a XML;

·         Suporte nativo para processamento analítico e data mining através do Analysis Services, ferramenta destinada a criação de cubos e análise de tendências;

·         Suporte à criação de índices full-text, permitindo busca otimizada de palavras ou frases em colunas com textos longos;

·         Ferramenta para aferição de performance (Profiler), que permite ao administrador capturar, armazenar e analisar eventos que responsáveis por gargalos no servidor;

·         Utilização de Indexed Views, também conhecida por Materialized View;

Alavancando Performance - Desfragmentando

Fragmentar é o mesmo que quebrar em partes ou despedaçar. Dizemos que um índice está fragmentado quando suas páginas não estão contíguas OU apresentam-se pouco utilizadas. Exemplos:

(1) Índice com fragmentação Externa <=> as páginas estão desordenadas (1-2-2-5-4...)

Procedures Não Documentadas no SQL Server 2000 - Parte 2

Darei continuidade nessa matéria, explicando o funcionamento de mais algumas procedures não documentadas existentes no SQL Server 2000.

xp_RegRead

Você instalou o SQL Server 2000 e perdeu aquele “papelzinho” onde estava anotado o CD Key (número de registro) do SQL Server 2000 ... Agora você está em apuros porque fez um upgrade de máquina e precisa realizar uma nova instalação ... E agora? Utilize a procedure xp_RegRead para ler informações do registry; basta informando a chave:

use master
exec xp_RegRead
                  'HKEY_LOCAL_MACHINE',
                  'SOFTWARE\Microsoft\Microsoft SQL Server\80\registration\',
                  'CD_KEY'
-------------------------------------------------------------------------------

Value          Data
CD_KEY      M3XXD-KQ4K5-XYQ89-YT9P5-DAG6F

xp_FileExist

Utilize para verificar se um arquivo existe em disco. Exemplo:

exec master..xp_FileExist 'c:\autoexec.bat'
-------------------------------------------------------------------------------

File Exists         File is a Directory         Parent Directory Exists
------------      ------------------         ------------------------
1                          0                                      1

Procedures Não Documentadas no SQL Server 2000

Existem diversas procedures não documentadas no SQL Server 2000. Por que não são documentadas? Boa pergunta. O que posso dizer com plena convicção é que são bastante úteis e costumo utilizá-las em várias rotinas administrativas que estão sob minha responsabilidade. Vale ressaltar que, como todo processo não documentado, sua utilização deve ser vista com cautela pelo fato de não existerem garantias concretas de que tais procedimentos continuarão existindo em novas versões do produto.

Como a listagem dessas procedures é extensa, estarei periodicamente voltando a esse assunto. Seguem alguns exemplos.

sp_MSForEachDb

Utilize essa sp para executar um ou mais procedimentos em todos os databases de um servidor. Por exemplo, vamos imaginar uma rotina para checagem da integridade de databases. Você possui algumas opções:

1. Utilizando um script com linhas de comando fixas

dbcc checkdb(‘northwind’)
dbcc checkdb(‘pubs’)
dbcc checkdb(‘master’)

.

...

2. Utilizando um cursor para executar o comando DBCC em todos os databases:

declare cr_Cursor cursor fast_forward
for

     select name from master.dbo.SysDatabases

declare @database varchar(200)
declare @cmd varchar(200)
open cr_Cursor

fetch next from cr_Cursor into @database
while (@@fetch_status <> -1)
begin
          if (@@fetch_status <> -2)
          begin
               set @cmd = 'dbcc checkdb('+''''+@database+''''+')'
                         print ''
               print '-------------------------------------------'
               print '>>>> Database: '+ @database
               print '-------------------------------------------'
                         exec (@cmd)
          end
          fetch next from cr_Cursor into @database
end

close cr_Cursor
deallocate cr_Cursor

3. Utilizando a procedure sp_MSForEachDB, para realizar o mesmo procedimento

exec sp_MSForEachDB @command1="print '?'" ,
                                          @command2="DBCC CHECKDB ('?')"

Os parâmetros da procedure são:

SQL Server 2005 - YUKON

As mudanças são bastante significativas, estão por toda a parte e servirão como um “divisor de águas” quando nos referirmos ao SQL Server. Elaborei um resumo das principais features, que estão listadas a seguir.

Espelhamento de Databases

O espelhamento de databases é uma implementação no atual processo de Log-Shipping, cuja finalidade é permitir redundância de bases de dados através da troca de logs entre servidores. Em caso de falha no servidor principal, o servidor espelhado irá detectar o problema e assumir o comando num prazo de máximo de 2 segundos, encarregando-se à partir desse momento, de capturar e processar suas requisições.

Indexação On-Line

Você poderá criar e dropar índices num ambiente de produção sem bloquear usuários.

Snapshot Isolation

Irá funcionar mais ou menos assim: no momento em que acontece uma alteração, serão criadas visões “transitórias” de dados, com a “última versão comitada” das linhas que estão em processo de modificação. Essa visão transitória é disponibilizada para processos de leitura de dados, que não são bloqueadas pela modificação. O isolamento snapshot irá contribuir para o aumento da disponibilidade da informação, à medida em que aumenta a eficiência dos processos de leitura de dados.

Notification Services

É um framework destinado a informar usuários sobre a ocorrência de eventos. Por exemplo, cria-se um evento chamado “Reposição de Produto”, para controlar a recompra de produtos com estoque próximo de um limite. Gera-se então uma assinatura desse evento para o supervisor de compras, que se encarregará de fazer o pedido para o fornecedor.

Suporte nativo a linguagens da família CLR (Common Language Runtime)

Além do tradicional T-SQL, você poderá criar objetos (funções, triggers ou stored-procedures) utilizando sua linguagem favorita do mundo .NET (Visual Basic® .NET ou Microsoft Visual C#®, por exemplo).

SQL Service Broker

Cria um mecanismo seguro para envio, recebimento e processamento de mensagens assíncronas. Por exemplo, numa aplicação Web um processo de venda dispara uma série de processos (inserção do pedido, baixa do estoque, faturamento, etc). Normalmente essas requisições tem de trafegar entre vários servidores, o que pode acarretar em períodos longos de espera. O papel do Service Broker é administrar essas chamadas assíncronas através do proces

SQL Server 2000 : o Contra-Ataque

Sou partidário da idéia de que o melhor ataque é a defesa, e é nesse sentido que gostaria de iniciar nosso primeiro encontro: esclarescendo minha opinião sobre uma série de comentários à respeito do banco de dados da Microsoft.

Periodicamente o leitor é apresentado a matérias comparando o SQL Server com outros bancos de dados. Comparações são saudáveis, pois permitem nortear os usuários na escolha do produto que melhor se adapte às suas necessidades. Comparações também estimulam melhorias nos produtos, pois forçam produtos concorrentes a estarem evoluindo sempre.

O SQL Server 2000 não chegou onde está por acaso. São mais de dez anos e 3 grandes saltos (6.5, 7.0 e 2000). Para o início do ano que vem está prevista a versão 2005 (codename Yukon, se preferir), que está chegando para arrasar.

Destaquei algumas frases, que serão comentadas a seguir.

O SQL Server não “aguenta o tranco” ...

• Quem faz esse tipo de afirmação está no mínimo desatualizado. Existem organizações sem fins lucrativos, reconhecidas internacionalmente por sua independência a quaisquer tipo de produto ou marca, que executam testes comparativos entre os principais SGBD´s existentes no mercado. Nesses benchmarks, que são bastante rigorosos e possuem auditagem de resultados independente, o SQL Server 2000 merece sempre posição de destaque. São aferidos itens como performance e escalabilidade em bases OLTP (TPC-C), em bases OLAP (TPC-H) e em número de iterações por segundo, simulando um processo de venda na Web (TPC-W) . Esses resultados podem ser comprovados em www.tpc.org/.
• Alguns números das maiores instalações de SQL Server pelo mundo podem também ser confirmadas por recente pesquisa da Winter Corporation entre as maiores instalações de bancos de dados existentes pelo mundo no ano de 2003:(www.wintercorp.com/VLDB/2003_TopTen_Survey/TopTenWinners.asp):
• Maior database no ambiente Windows (sexto na classificação geral) : 5.3 Terabytes;
• Maior tabela em número de linhas em bases OLTP: 33 bilhões de linhas;
• Segundo colocado em número de transações por segundo: 4.010 transações/segundo;
• Ainda no item número de transações por segundo, das 10 maiores instalações do mundo, quatro operam com SQL Server.

O SQL Server custa caro ...

• Sabemos que tudo tem seu preço. Tudo vai depender do que realmente precisamos e de onde queremos chegar. Você pode comprar um carro popular, o chamado ‘pé-de-boi’ e ficar bastante satisfeito. Sim, é difícil suportar aqueles dias de calor sem ar condicionado. Por várias vezes também um motor 1.0 deixa a desejar. Se isso não for um problema para você, então o tal carro popular que estamos falando serve para você. Sim, concordo que você pode colocar um ar-condicionado depois, mas o motor dificilmente será substituído. Com banco de dados (assim como tudo na vida!) acontece a mesma coisa. O que devemos ter em mente é a relação custo-benefício, aliada à satisfação dos usuários.
• O banco de dados da Microsoft vale o quanto pesa. Já na versão Standard você consegue somar às funcionalidades do banco:
• Replicação de dados: você pode, por exemplo, replicar alterações de preços e qualquer alteração em sua base de produtos para suas filiais. Em contrapartida, todas as transações realizadas nessas filiais podem ser replicadas para um servidor central de hora em hora, para uma visão consolidada de suas vendas;
• Dispositivos para criação de bases redundandes: o SQL Server possui mecanismos para manter cópias atualizadas de sua base de dados noutro servidor, através de um processo conhecido por log shipping. A base no servidor secundário (também conhecido por stand-by) pode ainda ser utilizada em processos de leitura de dados, desafogando gargalos de processamento no servidor principal;
• Geração de cubos para análise de tendências: o Data Warehousing tornou-se uma ferramenta fundamental nos dias de hoje. É através da garimpagem de dados históricos que são obtidas valiosas informações para serem utilizadas em processos de tomada de decisão;
• Ferramentas nativas para análise e tuning de aplicações (Profiler, Index Tuning, Análise Gráfica do Plano de Execução): a captura de processos num servidor de banco de dados é fundamental para identificação e eliminação de gargalos. O Profiler, em conjunto com o Index Tuning Wizard e com a ajuda do Analisador Gráfico do Plano ...

Boas-Vindas

Olá pessoal !

A partir de hoje estarei também contribuindo nesse site com várias dicas e truques “quentes” sobre o banco de dados da Microsoft, o SQL Server 2000. Quem vos escreve é Paulo Ribeiro; muitos de vocês já devem me conhecer da SQLMagazine, onde escrevo há um ano e meio. Sou natural de São Paulo-SP, onde fixei minhas raízes – pelo menos até hoje. Sou Tecnólogo em Processamento de Dados pela Universidade Mackenzie, Microsoft Certified Dabatase Administrator (MCDBA), pós-graduado em Administração de Empresas pela Fundação Armando Álvares Penteado (FAAP) e em Qualidade pela Fundação Oswaldo Cruz.

Durante o dia trabalho como DBA Sênior na Livraria e Papelaria Saraiva S/A, sendo o responsável direto pela área de Banco de Dados. Para quem não conhece, a Saraiva foi pioneira no ramo de livrarias e uma das primeiras redes - considerando também outros segmentos - a implantar o conceito de “mega lojas” e “cyber coffees”, existentes na rede de livrarias espalhadas pelo Brasil desde 1997. A livraria Saraiva possui também uma loja virtual no endereço abaixo: http:\\www.LivrariaSaraiva.com.br

À noite me transformo – no bom sentido da palavra – num misto de escritor e aprendiz. Costumo devorar muitos livros técnicos, e escrevo bastante. Minha proposta com essa coluna será fornecer uma série de textos curtos e diretos, destinados à resolução de problemas, otimização de código T-SQL e administração de servidores SQL Server. Essas dicas se baseiam em vários anos de contato direto com o produto, num parque formado por quase duas centenas de servidores.

Aproveito também o momento para agradecer a você LEITOR pelo sucesso da revista e pelos e-mails carinhosos que tenho recebido. É bastante gratificante saber que ambos – a revista e o site – tem contribuido para disseminar conhecimento de maneira simples e modesta, com artigos bastante qualificados e aprovados por vocês leitores.

Um forte abraço a todos !

Paulo Ribeiro

Backups Parte IV - Backup Diferencial

Um backup diferencial é uma cópia de todas as páginas dos objetos que sofreram alteração desde o último backup de database. Ao contrário dos backups de log, backups diferenciais não são incrementais: o último backup diferencial é suficiente para substituir todos os backups de log e diferenciais executados até então.

Como gerar um backup diferencial

Para gerar um backup diferencial à partir do Enterprise Manager, selecione o database e, com o botão direito do mouse acionado, clique em e por último em para que a tela de execução de backup (ver Figura 1) receba o foco. 

Figura 1. Executando backup de log do database dbTeste

As opções em destaque na Figura 1 assinalam o tipo de backup (=Diferencial), o destino do backup (=Destination=c:\temp\dump_dbTeste_full.bak)  e informam também que, se o arquivo em disco C:\temp\dump_dbTeste_full.bak já existir, o backup diferencial que está sendo executado deverá ser adicionado na mídia, preservando o conteúdo anterior. Para executar o backup, basta pressionar a tecla .

O comando T-SQL BACKUP DATABASE DIFERENCIAL também pode ser utilizado em oposição ao Enterprise Manager para geração de backups diferenciais (ver Listagem 1).

Listagem 1. Executando backup de log do database db_Teste com o comando T-SQL BACKUP LOG

BACKUP database