Neil Laslett's questions

Estou usando o Microsoft SQL Server Profiler para capturar dados de rastreamento de produção para reprodução em um servidor de desenvolvimento para testar alterações de indexação. Capturar o rastreamento não é problema: estou usando um modelo de rastreamento "TSQL_Replay" com o evento "Showplan XML Statistics Profile" adicionado. Na captura original, posso ver o plano de execução nos dados de rastreamento.

O problema é quando eu reproduzo esses dados de rastreamento no servidor de desenvolvimento. Não vejo nenhuma opção para configurar as opções de rastreamento de reprodução. Posso verificar "Exibir tempo de execução" e obter tempos para consultas individuais, mas não consigo ver os planos de execução que são executados quando o rastreamento é reproduzido. Isso é crítico para determinar como os novos índices estão sendo usados. Tentei executar um rastreamento paralelo separado no servidor de desenvolvimento enquanto reproduzo o rastreamento original, mas os replays não parecem ser captados.

Alguma dica sobre como medir resultados ao reproduzir um rastreamento?

Tentei usar o RML Utilities e o Database Experimentation Assistant, mas não descobri como fazer nenhum deles funcionar para esse caso de uso.

Temos um enorme ambiente de produção do MS SQL Server com milhares de tabelas que precisam urgentemente de ajuste e remoção de índices. Alguma sugestão sobre as melhores maneiras de testar as alterações propostas fora da produção?

Obviamente, podemos (e fazemos) criar um servidor de banco de dados DEV onde podemos fazer alterações, mas essa cópia do DEV não refletirá as demandas do mundo real feitas nas tabelas. Também temos um espelho de produção que usa envio de log de transações, mas os espelhos são sempre somente leitura (a menos que você faça failover deles para o primário), portanto, não podemos testar alterações de índice neles.

Existe alguma maneira de enviar logs de transações para uma instância que não seja um espelho somente leitura? Obviamente, isso pode encontrar problemas, especialmente se forem feitas alterações no esquema no ambiente de teste. Mesmo com alterações apenas no índice, você pode ter tempos limite de consulta e outros comportamentos inconsistentes.

Mas é exatamente isso que pretendemos fazer: dado um conjunto de alterações de índice, como funcionam as consultas do mundo real, sob carga do mundo real? Eles são mais rápidos? Eles falham?

Algumas consultas de teste não serão suficientes. Executamos todos os tipos de trabalhos de processamento noturnos, semanais e mensais que afetam fortemente o banco de dados. Também temos muitos scripts e serviços externos que consultam e atualizam o banco de dados de maneiras que nem sempre prevemos.

Dado o escopo das mudanças necessárias, estou muito hesitante em fazer quaisquer alterações no índice de produção ao vivo sem verificação.

Sinto que estou perdendo algo óbvio aqui...

Eu tenho uma situação com uma tabela primária (vamos chamá-la de People) e uma tabela secundária (vamos chamá-la de Groups) com dois papéis diferentes que as pessoas podem preencher ( Secretary& Treasurer). Ambas as colunas são inte FKs de volta para People.ID.

CREATE TABLE People(
ID int NOT NULL,
FullName varchar(50) NOT NULL,
CONSTRAINT [PK_People] PRIMARY KEY CLUSTERED (ID ASC))

CREATE TABLE Groups(
ID int NOT NULL,
Treasurer int NULL,
Secretary int NULL,
CONSTRAINT PK_Groups PRIMARY KEY CLUSTERED (ID ASC))

Até agora tudo bem. Mas as funções são opcionais (anuláveis), então eu quero poder excluir uma Pessoa e ter os valores FK em Grupos definidos como NULL.

ALTER TABLE dbo.Groups ADD CONSTRAINT FK_Groups_Treasurer FOREIGN KEY (Treasurer) REFERENCES dbo.People (ID) ON DELETE SET NULL

ALTER TABLE dbo.Groups ADD CONSTRAINT FK_Groups_Secretary FOREIGN KEY (Secretary) REFERENCES dbo.People (ID) ON DELETE SET NULL

Agora nós temos um problema:

A introdução da restrição FOREIGN KEY 'FK_Groups_Secretary' na tabela 'Groups' pode causar ciclos ou vários caminhos em cascata.

Qual é o problema aqui e por que o SQL Server se importa? Qual é o possível conflito em cascata? Se eu excluir um Person, defina NULL os valores FK em qualquer tabela relacionada. Isso não seria problema contra duas tabelas diferentes, cada uma com um FK. Mas ter dois valores FK na mesma tabela parece ser proibido.

Estou esquecendo de algo? Isso é de alguma forma um design ruim? Qual é a maneira correta de lidar com essa situação? Parece um caso de uso comum.