Eu tenho uma tabela que é publicada por meio de replicação transacional. Um desenvolvedor solicitou a modificação da tabela inscrita para adicionar uma coluna a ser usada para fins de relatório. A coluna será atualizada por meio de um processo externo.
Não é prudente adicionar a coluna à tabela publicada e inserir os dados lá, pois os dados necessários para atualizar a coluna estão no servidor do assinante.
Isso é possível? Existe uma maneira melhor?
Ao criar logins específicos do ambiente (desenvolvimento, controle de qualidade, preparação, produção, etc.), deparo-me com a escolha de tornar a denotação um prefixo ou um sufixo para o nome de login.
prod_MyAppLogin
MyAppLogin_prod
Existe alguma razão para eu preferir uma estratégia sobre a outra?
(Obviamente, devo ser consistente com qualquer escolha que eu fizer)
Eu tenho uma consulta que seleciona de várias exibições e é bastante pesada de E/S. Se eu executar esta consulta usando o Management Studio, ela usará paralelismo na maioria das 16 CPUs e será concluída em menos de 10 segundos. No entanto, ao executá-lo no SpotFire (um produto da Tibco), ele usa apenas 1 CPU e pode levar horas para ser concluído.
Consigo replicar o problema no Management Studio se estiver usando a dica de consulta OPTION (MAXDOP 1) .
Eu estava pensando que pode ser um problema do SpotFire, mas ele usa o driver Microsoft JDBC para conexão e não vejo propriedades de conexão em relação ao paralelismo. Eu confirmei usando o Profiler que as consultas do SpotFire e do Management Studio parecem exatas. a. mesmo. A única diferença parece ser a execução paralela.
Alguém pode oferecer uma visão de por que isso pode ocorrer?
!RESOLVIDO! [tipo de]
Corri novamente o rastreamento do SQL Profiler e descobri que as consultas são realmente as mesmas, mas a maneira como são executadas é diferente.
Do SpotFire:
declare @p1 int
set @p1=0
declare @p2 int
set @p2=0
declare @p7 int
set @p7=0
exec sp_cursorprepexec @p1 output,@p2 output,NULL,N'SELECT a, b, c , d FROM MyView',16,8193,@p7 output
select @p1, @p2, @p7
Do Management Studio:
SELECIONE a, b, c, d DO MyView
Em seguida, adicionei dois novos eventos ao SQL Profiler e executei novamente as consultas:
- Performance / Grau de Paralelismo
- Performance / Showplan All
Isso mostrou que a consulta do SpotFire estava usando DOP 0 (BinaryData = 0x00000000) e do Management Studio era DOP 12 (BinaryData = 0x1200000). Em seguida, o SHOWPLAN me mostrou que a consulta do SpotFire estava inserindo os resultados da exibição em uma tabela temporária antes de retornar os dados ao cliente.
Então, por que ele faz isso? Possivelmente por causa da instrução sp_cursorprepexec . Mas por que isso deveria fazer com que o DOP caísse para 0? Não sei.
Acho que a "solução" vai funcionar com o SpotFire e possivelmente ajustar a string de conexão JDBC.
Aqui está um artigo do MSDN sobre todos os parâmetros de conexão para JDBC.
Aqui está outro artigo de alguém que teve exatamente o mesmo problema que eu, também sem resolução.
Eu herdei um sistema onde o DBA anterior adicionou 7 arquivos de dados ao grupo de arquivos PRIMARY (tamanho inicial de 8 MB) e deixou a opção AUTOGROW em 8 MB. O que tenho agora é um conjunto de oito arquivos, cada um com cerca de 3 a 4 GB de tamanho, que vem crescendo lentamente ao longo de um período de dois anos. Eu gostaria de remover a fragmentação do arquivo da maneira mais rápida possível.
Aqui estão as opções que eu criei:
ou
Um nível de sistema operacional "Disk Defrag" ainda não é uma opção?
Não sei qual opção é a melhor ou se vai funcionar mesmo.
Além disso, esse banco de dados está sendo espelhado e replicado, portanto, a menor quantidade de trabalho em relação à reconstrução é ideal.
Obrigado pela ajuda.