Durante a replicação transacional, temos dados indo do servidor A para o servidor B.
Digamos que devíamos propagar novamente uma coluna de identidade em uma tabela no servidor A (por qualquer motivo), como isso afetaria os dados no servidor B?
Minha intuição diria que os dados no servidor A usarão a identidade recém-semeada e que seriam enviados para o servidor B como estão (e o servidor B teria conteúdo usando a nova identidade), mas não tenho certeza se isso está correto.
Digamos que temos dois servidores: Servidor A e Servidor B. Os dados estão sendo replicados (replicação transacional vanilla) de A para B.
Para uma das Tabelas, temos os seguintes dados:
Server A - Server B
========= =========
ID|Content ID|Content
---------- ----------
1 | ... 1 | ...
2 | ... 2 | ...
... ...
98| ... 98| ...
99| ... 99| ...
Depois de um tempo, excluímos os dados antigos:
Server A - Server B
========= =========
ID|Content ID|Content
---------- ----------
50| ... 50| ...
51| ... 51| ...
... ...
98| ... 98| ...
99| ... 99| ...
Agora, alteramos a ordem de replicação, agora o servidor B está replicando para o servidor A.
A questão é:
Eu esperava que novos dados adicionados ao Servidor B (e depois replicados para o Servidor A) continuassem usando a coluna ID (Iria para 100, 101, 102, ...). Em vez disso, notei que começa em 1.
A questão é:
Como o banco de dados lidará com isso quando o ID finalmente atingir 50? O banco de dados começará a lançar violações de chave primária ou perceberá o que está acontecendo e pulará do ID 49 para o ID 100?
Se ele começar a gerar violações de chave primária, existe um comando que possamos usar para informar ao servidor B que ele deve começar no ID 100? E em caso afirmativo, esse comando pode ser executado durante a replicação de dados?
Quando executamos o seguinte comando:
DBCC SHRINKFILE('MyDB_log', 1)
Obtemos os seguintes resultados no SSMS:
DBID | Field | CurrentSize | MinimumSize | UsedPages | Estimated Pages
-----|-------|-------------|-------------|-----------|----------------
11 | 2 | 128 | 128 | 128 | 128
A questão:
Como podemos criar uma consulta que gere esses resultados em um arquivo de texto, sem usar a janela de saída do SSMS.
Eu tentei isso:
CREATE TABLE #x
(
[DBID] int,
FileID int,
CurrentSize int,
MinimumSize int,
UsedPages int,
EstimatedPages int
)
INSERT #x
EXEC('DBCC SHRINKFILE(''MyDB_log'', 1)')
SELECT *
FROM #x
DROP TABLE #x
Mas recebo o seguinte erro:
Msg 8920, Level 16, State 2, Line 1
Cannot perform a shrinkfile operation inside a user transaction. Terminate the transaction and reissue the statement.
Eu também tentei o seguinte:
DECLARE @Statement AS VARCHAR(2000);
SET @Statement = 'bcp "DBCC SHRINKFILE(''MyDB_log'', 1)" queryout C:\Test.txt -c -UDBAdmin -P1234 -S192.168.123.123';
exec xp_cmdshell @Statement
Eu recebo:
Error = [Microsoft][SQL Native Client]BCP host-files must contain at least one column
A configuração:
Digamos que temos um banco de dados no modo de recuperação total que faz backup noturno do banco de dados, backup do log de transações e redução do log de transações.
Agora, o log de transações cresce tão rapidamente durante o dia, então precisamos executar um backup do log de transações + redução do log de transações a cada 6 horas para mantê-lo pequeno.
A questão:
Dada essa sequência de eventos (especificamente o backup/diminuição do log de transações a cada seis horas), ainda seremos capazes de executar uma restauração "atualizada"? (Ou seja, usando o último backup do banco de dados + log de transações para obter os dados mais recentes).
Eu tenho uma tabela que possui as seguintes definições de coluna:
ID (INT, PK)
Name (VarChar)
Active (Bit)
Bunch_of (Other_columns)
Pergunta: Quero ter uma Constraint em Name/Activetal que só possamos ter 1 registro com dado Nameque seja Active( Active= 1), mas poderíamos ter muitos registros que tenham o mesmo Nameque seja Inactive( Active= 0). Isso é possível?
Eu tentei as restrições únicas normais, mas elas limitam o conjunto de dados para permitir apenas 1 registro com um dado Namecomo Inactive.
Eu herdei um Planos de Manutenção que faz o seguinte:
Do plano de manutenção de 23 minutos, a atualização das estatísticas leva impressionantes 13 minutos. Durante esse período de 13 minutos, o acesso ao banco de dados é bloqueado (ou pelo menos, a replicação desse banco de dados para os outros é pausada).
Minha pergunta é:
Quando devemos atualizar as estatísticas e por quê?
Este parece ser o tipo de coisa que devemos fazer com menos frequência do que todos os dias. Estou tentando nos tirar da mentalidade "só porque" de fazer manutenção desnecessária.
Hoje, tive um problema com o tempo limite de um procedimento armazenado (demorou mais de 30 segundos) quando foi executado em uma página da Web ASP.NET, mas foi executado rapidamente quando executado no SSMS (demorou 5 segundos).
Depois de suspeitar que o culpado era o sniffing de parâmetros, mascarei os parâmetros de entrada e a consulta foi executada mais rapidamente.
Minha pergunta é: por que isso aconteceu?
Este sistema está em produção há mais de 5 anos, e esta é a primeira vez que vimos algo assim em nossos procedimentos armazenados. Isso é "desgaste do banco de dados"?
Resolvemos o problema, então não é grande coisa, mas estou curioso para saber por que isso estava acontecendo.
O que aconteceu:
Reiniciei uma assinatura há 16 horas. Eu tinha cerca de 1,2 milhão de registros para transferir, então esperava que demorasse um pouco. O Replication Monitor estava dizendo " N transações com N comandos foram entregues " por horas, então achei que estava tudo bem.
O problema:
Esta manhã, quando verifico o Replication Monitor, vejo isto:
Ah, não!, exclamo, pensando que preciso reinicializar a replicação com um instantâneo mais recente para evitar puxar 1,2 milhões de linhas. Mas eu olho para a outra guia no monitor de replicação e vejo isso:
Pergunta:
Estou me perguntando por que as transações estão sendo entregues, apesar do Replication Monitor reclamar do instantâneo.
Eu tenho 4 servidores, servidores A, B, C, D.
O servidor A publica uma instância de replicação e os servidores B, C e D têm assinaturas pull para ela.
A assinatura do servidor B precisa ser reinicializada, mas estou preocupado que a reinicialização (usando o "snapshot atual", não gerando um novo) afete o desempenho da replicação para os outros servidores.
Devo me preocupar, ou porque os servidores B, C e D têm assinaturas Pull (em vez de Push), estou apenas pensando demais nisso?
Eu gostaria que a última etapa do meu Plano de Manutenção executasse um script SQL personalizado simples ( SELECT * FROM <SomeTable> WHERE <Condition>) e salvasse os resultados em um arquivo (Texto, CSV, etc).
Isso é possível? A coisa mais próxima que encontrei é fazer isso em um .batarquivo executado pelo Windows, mas isso parece um pouco complicado.
Sistema:
Eu tenho um plano de manutenção que reconstrói índices para várias tabelas (10 tabelas, 50 milhões de registros no total).
Questão:
Durante a reconstrução do índice (~ 20 minutos), falhamos ao inserir dados no banco de dados
Pergunta:
Como posso reduzir o tempo de inatividade durante o Plano de Manutenção? Eu estava pensando em garantir que o tamanho do log de transações seja pequeno (truncando-o 4 vezes ao dia), mas não acho que isso ajudará.
Também não tenho certeza se a reconstrução dos índices com mais frequência ajudará. (Desde que não sei se esta é uma operação "em massa" que se beneficiará de tabelas recentemente reindexadas).
Nota: Atualizar para o SQL Server 2005 Enterprise para o recurso Live Reindexing não é uma opção.
Configurar:
Pergunta: Existe uma maneira de usar as ferramentas de alerta no SSMS 2005 para iniciar um serviço do Windows no servidor secundário em caso de falha na replicação?
Caso contrário, esse recurso está disponível em uma versão mais recente do SSMS?
A História: Uma vez por semana, executamos um Plano de Manutenção especial que envolve a reindexação de 2 tabelas críticas que possuem aproximadamente 6 milhões de registros entre as duas. Usamos o SQL Server 2005 Standard Edition.
O problema: durante essa reindexação (operação de aproximadamente 15 minutos), falhamos ao inserir dados nas tabelas e nossos clientes ficam sem dados.
Disseram-me que o SQL Server 2008 Enterprise possui uma "reindexação online" que não está presente em versões inferiores do SQL Server que resolverá nossos problemas.
No entanto, acabei de encontrar a seguinte opção em nossas opções de Plano de Manutenção (SQL 2005 Standard):
Minha pergunta: Isso executa a mesma "reindexação online" que o 2008 Enterprise faz? Quais são as repercussões (desempenho sábio) para habilitar esta opção? Quase fui persuadido a comprar uma licença Enterprise 2008 desnecessariamente?
Ao tentar executar meu plano de manutenção, recebo o seguinte erro:
A execução da consulta "" falhou com o seguinte erro: "O índice "" (partição 1) na tabela "" não pode ser reorganizado porque o bloqueio no nível da página está desabilitado."
No momento, temos o bloqueio de nível de linha ativado neste índice. Posso ativar o bloqueio no nível da página, mas não tenho certeza de quais são as repercussões.
Minha pergunta é: qual é a diferença entre os dois esquemas de bloqueio e quais são suas consequências no mundo real (em produção)?