marc_s's questions

Estou tentando definir uma forma de trabalhar com um banco de dados de teste (em SQL Server) para nossos testes de integração.

Minha ideia era fazer essas etapas no lançamento do assembly de teste de integração:

• criar um banco de dados totalmente vazio
• execute o script "criar objetos de banco de dados" para criar todos os objetos de banco de dados relevantes (tabela, exibições, sequências etc.)
• preencha os "dados base" (valores de pesquisa etc.)
• tire um instantâneo do banco de dados chamado (db)_Basisde "linha de base" para futuros testes de integração

Agora, antes de cada classe de teste (contendo 1-n testes), eu estava planejando simplesmente fazer uma "restauração do instantâneo" para voltar ao estado bem definido, mais ou menos "vazio" do banco de dados. Funciona como um encanto até agora.

No entanto, há um conjunto de testes de integração que precisam operar em um grande banco de dados de teste - então eu esperava fazer isso antes de cada um desses dispositivos de teste (classes com n testes individuais)

• restaurar banco de dados do (db)_Basisinstantâneo
• insira essas mais de 50.000 linhas de dados no banco de dados
• criar outro instantâneo (db)_With_Testdatainstantâneo

(db)_With_Testdatae, em seguida, para cada teste, redefina o banco de dados para a versão instantânea bem definida , execute os testes, verifique o resultado e assim por diante.

O problema é: parece que não consigo ter dois instantâneos de banco de dados ao mesmo tempo - uma vez que o faço, não consigo restaurar meu banco de dados para nenhum deles .... Continuo recebendo este erro:

Msg 3137, Nível 16, Estado 4, Linha 9 O
banco de dados não pode ser revertido. Os nomes primários ou instantâneos foram especificados incorretamente, todos os outros instantâneos não foram descartados ou há arquivos ausentes.

Msg 3013, Nível 16, Estado 1, Linha 9
RESTORE DATABASE está encerrando de forma anormal.

É realmente assim que os instantâneos do banco de dados do SQL Server funcionam? Parece terrivelmente restritivo. ?!?!?

Existe alguma diferença entre um SEQUENCEuso declarado NO CACHEe um uso declarado CACHE 1no SQL Server 2012+?

Sequência nº 1:

CREATE SEQUENCE dbo.MySeqCache1
AS INT
    START WITH 1
    INCREMENT BY 1
    MINVALUE 1
    MAXVALUE 9999
    NO CYCLE
    CACHE 1;
GO

Sequência nº 2:

CREATE SEQUENCE dbo.MySeqNoCache
AS INT
    START WITH 1
    INCREMENT BY 1
    MINVALUE 1
    MAXVALUE 9999
    NO CYCLE
    NO CACHE;
GO

Existe alguma diferença entre os dois? Eles se comportarão de maneira diferente ao serem usados ​​em um ambiente SQL Server 2012+?

Estou trabalhando em um conjunto de scripts (no SQL Server Management Studio) para corrigir certas inconsistências de dados em um banco de dados de clientes (SQL Server 2008 R2).

Peguei um .bakarquivo com o banco de dados e o restaurei em meu sistema, por exemplo, SampleDatabase. Agora estou trabalhando em meus scripts e, depois de um tempo, consertei a maioria dos problemas.

Agora, gostaria de restaurar o .bakarquivo original novamente, para ter certeza de que todos os meus scripts são executados nos dados originais e fazem o que devem fazer. Fecho todas as janelas no SQL Server Management Studio, abro uma nova janela de consulta em meu masterbanco de dados e emito meu RESTOREcomando:

RESTORE DATABASE [SampleDatabase] 
FROM DISK = N'c:\tmp\sample.bak'
WITH FILE = 1,  
MOVE N'Sample_PRIMARY' TO N'c:\mssql\Sample_PRIMARY.MDF',  
MOVE N'Sample_LOG' TO N'C:\mssql\Sample_LOG.LDF',
NOUNLOAD, REPLACE, STATS = 5

Infelizmente, agora recebo uma mensagem de erro:

Msg 3101, Nível 16, Estado 1, Linha 2
Não foi possível obter acesso exclusivo porque o banco de dados está em uso.
Msg 3013, Nível 16, Estado 1, Linha 2
RESTORE DATABASE está encerrando de forma anormal.

o que parece um pouco estranho, já que me certifiquei de ter fechado todo o SSMS Windows nesse banco de dados - por que ainda está em uso?

Como posso resolver essa situação o mais rápido possível? A única solução que conheço que funciona agora é reiniciar o MSSQLSERVERserviço - mas esse é um processo bastante demorado e um tanto complicado ...

Existe outra maneira mais eficiente e simplificada de deixar esse banco de dados "fora de uso" para que eu possa restaurar o backup sobre ele novamente para verificar meus scripts?

Supondo que você precise garantir que seu aplicativo que depende do SQL Server 2012 como seu back-end de banco de dados esteja disponível 24 horas por dia, mesmo que uma máquina servidora falhe.

Como desenvolvedor e não DBA, estou com dificuldades para entender quando usar qual cenário para meu failover/alta disponibilidade:

• Dois (ou mais) servidores em um cluster de failover do Windows, SQL Server como uma instância clusterizada
• Duas (ou mais) instâncias do SQL Server que são mantidas atualizadas com replicação transacional
• Dois (ou mais) SQL Servers em um SQL Server Availability Group, configurados em um modo de confirmação síncrona

Qual desses cenários funciona para que tipo de carga de trabalho e que tipo de falha/interrupção pode ser tratada por esses cenários? Eles são mesmo comparáveis/trocáveis?

Complementando minha pergunta anterior :

existe uma maneira de precisar descobrir quais são as configurações ANSI_NULLSe ANSI_PADDINGetc. onde quando um determinado procedimento foi criado no meu banco de dados?

Parece que meu cliente tem vários procedimentos armazenados e alguns gatilhos que foram "ajustados" - mas, infelizmente, usando um conjunto "errado" dessas configurações de banco de dados. Posso descobrir quais procedimentos e gatilhos são afetados ou preciso recriar todos eles com as configurações adequadas?

Recebi um caso em que um cliente está enfrentando esse erro - de vez em quando:

Msg 8624, Nível 16, Estado 21, Linha 1
Erro interno do processador de consulta: O processador de consulta não pôde produzir um plano de consulta. Para mais informações, contacte os Serviços de Apoio ao Cliente.

Eles estão usando nosso software e executando-o no SQL Server 2008 R2 (RTM) e no nível de compatibilidade 100 (SQL Server 2008). O banco de dados, no entanto, foi originalmente criado em uma máquina de 2000 ou 2005 (não pode mais ser reproduzido) e depois movido para 2008 R2 recentemente.

O procedimento armazenado em questão tem uma declaração de aparência feia INSERTque obtém dados de dez (sim!) "cópias" de uma determinada tabela, todas unidas RIGHT OUTER JOINentre si (mesma tabela - dez JOINs contra ela).

A única solução que achei mais adequada tem a ver com várias configurações - é recomendável usar:

set ANSI_NULLS ON
set ANSI_PADDING ON
set ANSI_WARNINGS ON
set CONCAT_NULL_YIELDS_NULL ON
set QUOTED_IDENTIFIER ON
set ARITHABORT ON

set NUMERIC_ROUNDABORT OFF 

OK - claro - posso defini-los antes de cada procedimento armazenado que criar (ou alterar).

Minha pergunta para os gurus do banco de dados seria: algum risco quando eu definir essas configurações como padrão para meu banco de dados?

Por exemplo

ALTER DATABASE MyDB SET ANSI_NULLS ON

e acabar com isso? Pensamentos? Percepções? Recomendações?

Como acompanhamento da minha pergunta anterior sobre solução de problemas de perf em um site do Sharepoint , gostaria de saber se poderia fazer algo sobre as esperas do CXPACKET.

Eu sei que a solução instintiva é desligar todo o paralelismo definindo MAXDOP como 1 - parece uma má ideia. Mas outra ideia é aumentar o limite de custo antes que o paralelismo entre em ação. O padrão de 5 para o custo de um plano de execução é razoavelmente baixo.

Então, eu queria saber se há uma consulta já escrita que encontraria as consultas com o maior custo do plano de execução (eu sei que você pode encontrar aquelas com a maior duração de execução e assim por diante - mas o custo do plano de execução pode ser recuperado em algum lugar, também?) e isso também me diria se tal consulta foi executada em paralelo.

Alguém tem esse script em mãos ou pode me indicar a direção do DMV, DMF ou outras exibições de catálogo do sistema relevantes para descobrir isso?

Sou muito novo nesse ajuste de desempenho com esperas e filas - fascinante, mas também nem sempre tão intuitivo ...

Neste momento, um cliente meu tem um SQL Server 2008 64-bit Enterprise Edition, atualmente com 16 GB de RAM atribuídos a ele, rodando em um servidor físico com 64 GB de RAM (existem outras instâncias do SQL Server e mutáveis ​​no mesmo máquina também).

Este aplicativo que ele está executando é uma solução Sharepoint 2010, que executa - bem - OK para um site Sharepoint - na maioria das vezes. Exceto pelas buscas, que são terrivelmente lentas.

Agora, do ponto de vista do SQL Server, tenho observado as estatísticas de espera por alguns dias e os três principais tipos de espera são:

1) CXPACKET em torno de 49%
2) SOS_SCHEDULER_YIELD em torno de 10,5%
3) OLEDB em torno de 9,5%

Isso parece ser bastante consistente - sem grandes mudanças ao longo do tempo.

• PAGEIOLATCH_SH vem em sétimo lugar - 2,5% do tempo total de espera, o tempo médio de espera do recurso é de 14 ms.
• ASYNC_IO_COMPLETION vem em oito - menos de 2% do total de tempos de espera, mas alta média de tempo de espera do recurso de 38 segundos (sim, segundos - não milissegundos!)

O tempo de espera do sinal é extremamente baixo, então isso não parece indicar pressão da CPU. Então, o que está causando esse padrão - e o que podemos fazer para (a) encontrar informações mais relevantes ou (b) encontrar uma solução para acelerar as coisas?

Alguma ideia? Percepções? Ideias? Estou praticamente aberto a qualquer coisa - o que não podemos mudar é a arquitetura básica (instâncias separadas do SQL Server, sendo movidas entre servidores físicos - e uma SAN baseada em Unix que não pode garantir a separação de dados e fazer logon em discos físicos separados)

Novamente: este é um site do SharePoint - até onde eu sei, tentar resolver as coisas com indexação ou reestruturação do banco de dados está entre o difícil e o impossível.

Estou tentando configurar um rastreamento do lado do servidor no SQL Server 2008 R2. Embora eu não tenha problemas para selecionar eventos e colunas de dados, a filtragem parece um pouco estranha...

Eu estava tentando configurar uma filtragem na duração do lote SQL ou no procedimento armazenado (filtre qualquer coisa >= 1000 ms), mas também queria filtrar o nome do banco de dados envolvido.

Quando exporto a definição de rastreamento do SQL Profiler para um *.sqlarquivo, no entanto, não encontro nenhuma filtragem no nome do banco de dados:

-- lots of other stuff up here - setting up trace events and so on...

-- Set the Filters
declare @intfilter int
declare @bigintfilter bigint

exec sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Server Profiler - 100479e4-6eeb-4608-af17-64141f1631ec'
set @bigintfilter = 1000000
exec sp_trace_setfilter @TraceID, 13, 0, 4, @bigintfilter

....

Então o que isso quer dizer? Por que posso especificar um nome de banco de dados para filtrar - mas a definição de rastreamento não o contém, no final?

• Isso significa que o rastreamento do lado do servidor está sempre verificando apenas o banco de dados em que está sendo criado?
• Mas então por que posso especificar um filtro pelo nome do banco de dados?
• Isso também significa que não há como fazer rastreamento em todo o servidor de banco de dados em, por exemplo, deadlocks?

Atualização: depois de mais algumas brincadeiras, cheguei à seguinte conclusão:

• o filtro no nome do banco de dados não foi aplicado ao Create Tracescript no meu caso, pois acabei selecionando apenas o Locks / Deadlock Graphevento - e esse evento não expõe a Database Namecomo uma coluna de evento

• se eu escolher outros eventos, como RPC completedesse , expor Database Namecomo uma coluna de evento, posso filtrar Database Namee esse filtro também é adicionado corretamente ao Create Tracescript.

Não consigo descobrir como consegui definir um filtro em Database Name, pois normalmente, se um evento não expõe uma coluna, essa coluna também não está disponível na caixa de Column filterdiálogo ....

De qualquer forma - por quaisquer razões que estejam além de mim (por enquanto, pelo menos), Deadlock Graphnão expõe o Database Namee, portanto, também não posso filtrar essa propriedade ....

Obrigado a todos que ajudaram e forneceram comentários perspicazes!

Comecei com sucesso um rastreamento do lado do servidor na instância do SQL Server de um cliente graças a algumas ótimas postagens, mas como essa é realmente a minha primeira vez em uma situação da "vida real", fiquei pensando sobre algumas coisas.

1) Eu defini o nome "base" de um arquivo de rastreamento no script que cria o rastreamento. Estou iniciando o rastreamento às 6h e desligando novamente às 19h todos os dias. O que eu realmente adoraria fazer é definir o nome base do arquivo de rastreamento para incluir a data, por exemplo, eu adoraria que fosse

 (some directory)\MyTrace-2012-Apr-19

e assim por diante - para que os arquivos de rastreamento de cada dia sejam facilmente reconhecidos. Existe uma maneira de conseguir isso?? Eu teria que realmente criar e descartar o rastreamento todos os dias para obter isso?

2) Se eu ligar e desligar o rastreamento diariamente, meu arquivo de rastreamento de ontem ( MyTrace.trc) será reutilizado hoje, até seu tamanho máximo definido? Ou o SQL Server criará um novo arquivo de rastreamento ( MyTrace_1.trc, MyTrace_2.trc) todos os dias quando for inicializado?

3) Além disso, tive problemas para tentar obter o arquivo de rastreamento, mesmo depois das 19h - parece que ele ainda estava bloqueado por algum processo e eu não poderia simplesmente copiá-lo para outro lugar ... Eu supunha que, uma vez que o o rastreamento for interrompido, o arquivo estará disponível "livremente" - estou errado?

Aqui está uma para os gurus do SQL Server: se eu definir meu nível de isolamento de transação do SQL Server 2008 como READ UNCOMMITTED, isso também afetará as páginas de índice?

Por exemplo, usando ISOLATION LEVEL READ UNCOMMITTED, que efeito (se houver) o ALLOW_PAGE_LOCKSou ALLOW_ROW_LOCKSem um índice tem?

ALTER INDEX IX_FirstName ON Employee
SET (ALLOW_PAGE_LOCKS=OFF, ALLOW_ROW_LOCKS=OFF)

Não consigo encontrar uma resposta definitiva em nenhum lugar - a documentação do MSDN sobre os níveis de isolamento da transação realmente fala apenas sobre as páginas de dados ....