paulH's questions

Consultar o número de bloqueios mantidos me dá um número na casa das centenas:

SELECT count(*) from
SYS.dm_tran_locks

Mas consultar o contador de desempenho 'Bloqueios de bloqueio' me dá um número na região de 45.000.

SELECT object_name, counter_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [counter_name] in ('Lock Blocks', 'Lock Blocks Allocated', 'Lock Memory (KB)', 'Lock Owner Blocks')

Os blocos de bloqueio são definidos pela Microsoft como:

Especifica o número atual de blocos de bloqueio em uso no servidor (atualizados periodicamente). Um bloco de bloqueio representa um recurso bloqueado individual, como uma tabela, página ou linha.

Então eu esperaria que os números fossem os mesmos, ou pelo menos na mesma faixa. Meu entendimento está obviamente faltando em algum lugar, então estou tentando entender isso melhor. Qualquer ajuda seria apreciada.

Estou no meio da migração de um banco de dados para o Azure SQL Database. Eu estava lendo sobre as diferenças entre o Azure SQL Database e o Azure Managed Instance e notei que as funções CLR NÃO são suportadas no Azure SQL Database.

Isso me surpreendeu, pois já carreguei uma versão de teste do banco de dados no Azure SQL Database e ninguém reclamou de problemas. Dei uma olhada e, com certeza, o assembly CLR está lá e executar consultas que usam as funções CLR funciona muito bem.

Então fui pesquisar na web, e todas as informações que vejo são que o CLR não funciona com o Azure SQL Database. No entanto, aqui estou eu, com um assembly CLR funcionando no Azure SQL Database.

Então agora estou pensando, digo à empresa que temos que mudar para usar a Instância Gerenciada porque esse é o único lugar onde o CLR é suportado? Ou continuo com o Banco de Dados SQL do Azure porque está funcionando bem? Ou esqueci de alguma coisa? A Microsoft reativou o CLR sem avisar ninguém?

Estou migrando um pacote SSIS do SQL Server 2012 para um novo servidor 2022. O pacote usa a tarefa Executar Pacote dentro de um loop para executar outro pacote no projeto. Estou descobrindo que na primeira vez que a tarefa Executar Pacote é executada, parece que demora muito para iniciar e não sei por que ou onde procurar uma causa.

A parte relevante do pacote principal é esta:

Observando os tempos de execução, a primeira vez que o pacote Generic Parsing é chamado leva mais de 10 segundos (a coluna final em ms), mas os componentes do pacote levam apenas uma fração desse tempo. As execuções subsequentes da Análise Genérica (também mostradas nos resultados) são executadas conforme esperado, sem aquele atraso inicial.

Eu tenho um ambiente SQL Server 2012 ao vivo que não tinha SPN registrado - isso anteriormente não era um problema, pois a autenticação Kerberos não era necessária. Mas agora é necessário.

Configurei tudo corretamente, mas após essas alterações, quero garantir que o SQL Server possa registrar os SPNs com êxito - de preferência sem uma reinicialização do serviço, pois este é um ambiente ativo.

Existe alguma forma de fazer isso?

PS Eu sei que posso registrar os SPNs manualmente, mas quero ter certeza de que eles podem ser registrados automaticamente.

Eu tenho um banco de dados muito ocupado e me pediram para procurar transações que revertem.

Usei o SQL Server Profiler para monitorar o TM: Rollbackevento Tran concluído, o que me mostra que dezenas desses eventos estão acontecendo a cada minuto, mas não me dá nenhuma indicação sobre qual transação está sendo revertida, quais objetos são afetados pela reversão , ou por que ocorreu a reversão. Em suma, parece de uso muito limitado.

Se eu tentar também monitorar, por exemplo, SQL:StmtStartingpara dar algum contexto ao rollback, simplesmente haverá muito ruído neste ambiente ocupado para ser capaz de identificar qual instrução é responsável pelo rollback.

Eu também tentei executar a instrução

SELECT *
FROM fn_dblog (NULL, NULL)
WHERE Operation = 'LOP_ABORT_XACT';

mas isso não retornou nenhum resultado (o que parece estranho, dado o número de reversões relatadas pelo SQL Profiler).

Existe alguma maneira de produzir um relatório mostrando as transações que foram revertidas?

TIA!

Nas propriedades de uma fonte de dados no SSRS, posso especificar uma conta de domínio do Windows para usar, assim:

Esta fonte de dados foi originalmente implantada de um projeto SSDT e preciso que essas configurações sejam refletidas nesse projeto - caso contrário, a fonte de dados não funcionará mais corretamente na próxima vez que o projeto for implantado.

Infelizmente, o SSDT não parece fornecer uma maneira de fazer isso. Se eu especificar as credenciais aqui, ele assumirá automaticamente a autenticação do SQL Server (o que não tem utilidade para mim).

Estou perdendo alguma coisa ou sou mais uma vez vítima da incapacidade da Microsoft de ser consistente?

Criei um índice não clusterizado em um servidor ativo (SQL Server 2008 R2) e acabou não fornecendo os benefícios de desempenho que eu esperava. Então, eu quero excluir o índice novamente.

Infelizmente, não consigo bloquear o índice, pois ele está em uso. Provavelmente estará sempre em uso. Reiniciar o SQL Server não é realmente uma opção.

Eu também tive esse mesmo problema no passado quando quis reconstruir um índice e tive que contornar o problema reorganizando (o que às vezes é muito ineficiente).

Existe alguma maneira de dizer ao SQL Server para parar de usar um índice? Ou é possível executar uma consulta que tentará obter um bloqueio exclusivo no índice, aguardar indefinidamente e excluir o índice? Quaisquer outras opções? Ou devo apenas esperar até que haja algum tipo de interrupção e, em seguida, espero me lembrar de removê-lo antes que tudo volte a ficar online?

No SQL Server 2008, ao usar o espelhamento de banco de dados, era possível configurar alertas quando a transação não enviada mais antiga excedia um determinado limite. Poderíamos verificar o estado de qualquer espelhamento de banco de dados usando o comando de menu Launch Database Mirroring Monitor.

No SQL Server 2012 agora temos Grupos de Disponibilidade. Parece-me que existe o mesmo problema potencial que, se as transações não puderem ser enviadas para o servidor secundário, o espelhamento será suspenso e, potencialmente, os logs de transações preencherão todo o nosso espaço em disco. No entanto, a ferramenta Database Mirroring Monitor não parece reconhecer os bancos de dados em Availability Groups como sendo espelhados.

Existe uma maneira de configurar um alerta se a transação não enviada mais antiga exceder um determinado valor? Existe uma maneira de definir esse determinado valor?

Eu tenho um banco de dados que parece estar funcionando bem sem erros aparentes, exceto que qualquer backup completo feito está quebrado - a tentativa de restauração falha com um erro "RESTORE detectou um erro na página (18469:-1767164485)"

DBCC CheckDB no banco de dados é concluído sem erros.

EDIÇÃO #1

O backup é criado com o seguinte comando:

BACKUP DATABASE @DatabaseName
TO
DISK = @backupFile1,
DISK = @backupFile2,
DISK = @backupFile3
WITH COMPRESSION, RETAINDAYS = 0, FORMAT, INIT, SKIP, NAME = @DatabaseName

EDIÇÃO Nº 2

Acabei de concluir um backup usando o backup do banco de dados da GUI, caso meu script estivesse errado de alguma forma - isso deu o mesmo resultado de um backup danificado.

--

Isso só começou a acontecer ontem à noite. A única mudança significativa que conheço é que alterei a opção 'auto-shrink' do banco de dados (ela foi originalmente definida como true).

Alguém está ciente de um problema nesta área com o SQL Server 2012 (especificamente estou na versão 11.0.3128)? Pode ser apenas coincidência ou relacionado a algo totalmente diferente, mas essa parece a causa mais provável no momento.

Além disso, alguém tem algum conselho sobre o que fazer em tal situação? O banco de dados está funcionando bem (tanto quanto posso determinar), mas não me importo de ficar sem backups por muito tempo...!

Eu tenho um banco de dados de terceiros no qual um grande número de tabelas tem uma coluna 'companyID' e a maioria das consultas nessas tabelas inclui companyID = @companyIDa cláusula where.

[ EDIT: Além da cláusula where, o companyID geralmente também é usado na cláusula order by da maioria das consultas: por exemplo order by companyId, otherField1, otherField2 etc.. ]

Em nossa organização, a coluna companyID é sempre preenchida com 1 (embora haja uma chance externa de mudar em algum momento no futuro).

Agora estou procurando criar alguns índices nessas tabelas. O SQL Server recomenda alguns 'índices ausentes' e todas as recomendações contêm o campo companyID como a primeira coluna do índice.

Seguindo o princípio de especificar a coluna mais seletiva primeiro, eu pensaria que deveria colocar a coluna companyID por último, ou talvez nem mesmo tê-la no índice. Mas então estou me perguntando por que a exibição de índices ausentes do SQL Server sempre sugere colocá-la em primeiro lugar - certamente o SQL Server é inteligente o suficiente para saber que cada linha contém o mesmo valor para essa coluna?

Uma questão puramente teórica, pois tenho considerado possíveis cenários de DR ...

Neste cenário:

• O link entre um princípio e um servidor espelho fica indisponível por um período de tempo (por exemplo, interrupção da rede)
• Backups de log incrementais ainda estão sendo feitos durante esse período
• Em seguida, o banco de dados principal falha e é irrecuperável

É possível restaurar os backups de log incrementais no espelho para atualizá-lo e colocá-lo novamente on-line ou você precisaria começar do zero com uma restauração de um backup completo?

Dependendo do tamanho do banco de dados, a diferença pode ser de horas de inatividade, por isso seria bom saber. Estou predominantemente interessado no SQL Server 2008 R2 e 2012, mas outras pessoas podem estar interessadas em outras versões se houver uma diferença.

A Microsoft recomenda não se preocupar em reconstruir índices que tenham menos de 1.000 páginas (a partir da memória, acho que é porque eles são tão pequenos que serão mantidos na RAM).

Se eu não os reconstruir, eles ficarão fortemente fragmentados. Nesse caso, há algum sentido em tê-los? Estou imaginando uma lista telefônica onde cada entrada está no lugar errado - seria inútil!

Para esclarecimento, estou falando principalmente sobre índices não clusterizados, embora eu esteja interessado em saber se a resposta seria ou não diferente para índices clusterizados.

A resposta a esta pergunta sugere que os índices podem ajudar a evitar problemas de bloqueio por trás dos bloqueios de linha, o que seria uma razão pela qual os índices ainda podem ser úteis se estiverem corretos e se aplicarem ao SQL Server.

Eu tenho o seguinte índice criado em uma tabela no meu banco de dados:

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

O servidor está sugerindo o seguinte índice 'ausente':

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

Parece-me lógico alterar a definição de índice existente para incluir as colunas sugeridas, em vez de criar um novo índice que precisa ser mantido. Uma consulta que seleciona em col1 e col2 pode usar index1 com a mesma eficiência que index2. Estou correto ou talvez esteja faltando alguma coisa?

Eu tenho um servidor de banco de dados SQL Server 2008 R2 que hospeda um banco de dados de data warehouse. Neste servidor também está instalado o SQL Server Reporting Services, e seus dois bancos de dados ReportServer e ReportServerTempDB.

Por motivos de desempenho, desejo separar o banco de dados do data warehouse e o Reporting Services. Eu tenho outro servidor disponível para instalar o SSRS. Ambos os servidores são virtuais e, portanto, suas especificações são facilmente alteradas, ou outros servidores podem ser 'criados', se necessário.

O que não consigo entender é onde seria o melhor lugar para hospedar o ReportServer e o ReportServerTempDB. Vejo três opções:

1. deixe-os com o banco de dados do data warehouse
2. coloque-os no servidor que terá o Reporting Services instalado nele
3. crie outro servidor especificamente para hospedar esses dois bancos de dados.

Com a opção 1, temo que separar o Reporting Services de seus bancos de dados afete o servidor do data warehouse ou afete os relatórios. Com a opção 2 eu me preocupo que a instalação do mecanismo de banco de dados no servidor afete o desempenho do servidor do Reporting Services, e com a opção 3 eu me preocupo por estar desperdiçando recursos criando um servidor que dificilmente fará qualquer coisa, e também impactando os relatórios separando os Reporting Services de seu banco de dados.

Acho que a principal informação de que preciso é saber qual parte do Reporting Services consome mais recursos. Se for o aplicativo Reporting Services, posso deixar os bancos de dados com o data warehouse. Se forem os bancos de dados que consomem muitos recursos, preciso colocá-los no aplicativo Reporting Services ou criar um novo servidor.

Alguém pode dar uma luz por favor?

Obrigado!

Se eu definir a compactação (página ou linha) no índice clusterizado de uma tabela, isso é o mesmo que definir a compactação na tabela?

O SQL Server fornece opções para fazer ambos, o que sugere que são diferentes, mas tive a impressão de que um índice clusterizado e uma tabela eram essencialmente a mesma coisa, e meu modelo mental de como os índices clusterizados funcionam me diz que compactar o índice clusterizado também deve comprimir a tabela.

Estou importando uma grande quantidade de dados para um banco de dados vazio e, antes de começar, desativei todos os índices não clusterizados não exclusivos para ver se poderia melhorar o desempenho da importação.

Agora quero reativar os índices e gostaria de saber se há algo que eu possa fazer para otimizar isso.

Existem > 100 tabelas e quase 2.000 índices a serem reconstruídos. O banco de dados tem 200 GB de tamanho.

A seção principal do script que estou executando é esta:

declare c_toggle_index cursor FORWARD_ONLY READ_ONLY for
    select  'alter index ' + QUOTENAME(i.name) + ' on ' + o.name + ' rebuild'
    from    sys.indexes as i
    Inner Join sys.objects o
    On o.object_id = i.object_id
    Where o.is_ms_shipped = 0
    And i.index_id >= 1
    and i.type > 1
    and i.is_disabled = 1

Considerei definir ONLINE=OFF para a instrução alter index, mas como os índices começam desabilitados, não tinha certeza se essa configuração teria algum efeito. Também considerei definir SORT_IN_TEMPDB = ON, mas como os arquivos tempdb estão na mesma unidade que os arquivos .mdf dos bancos de dados, presumi que também não haveria benefício em fazer isso.

Ao executar o script de reconstrução, notei que tenho muitos tipos de espera CXPACKET. Eu realmente não entendo por que isso aconteceria ou se é um problema que eu deveria procurar resolver.

Um ponto final que pode ser relevante: todo o meu servidor está atualmente inativo, exceto esta importação de dados para o banco de dados. Não há nenhuma outra atividade do usuário a ser considerada ou com a qual se preocupar; minha única preocupação é importar os dados para o banco de dados no menor tempo possível.

Eu tenho um procedimento armazenado que executa backups de banco de dados. Como estou analisando os Grupos de Disponibilidade no SQL Server 2012, desejo utilizar a função *sys.fn_hadr_backup_is_preferred_replica* nesse script para testar se o script deve produzir o backup.

Se o script for executado manualmente em vez de como parte de um trabalho agendado do SQL Agent, ou se o trabalho do SQL Agent for executado manualmente em vez de por meio de um agendamento, desejo que o trabalho falhe com uma mensagem de erro para permitir que o usuário veja que o backup não foi bem-sucedido por não estar na réplica preferencial. Se o trabalho for executado de acordo com um cronograma, obviamente não quero que ele falhe, pois produziria erros e enviaria alertas o dia todo no servidor que não é a réplica preferida.

A única coisa que não sei fazer é verificar se o job está sendo executado por agendamento ou manualmente. Isso é possível?

Caso contrário, existe alguma outra maneira de alertar um usuário de que o script não produziu um backup, sem causar falha na tarefa agendada e produzir um alerta?

Eu tenho a inicialização instantânea de arquivo habilitada em nosso SQL Server, então a parte 'vazia' do arquivo de banco de dados não é zerada antes de ser alocada. Meu entendimento é que isso significa que o arquivo pode conter dados 'excluídos'.

Agora, quero enviar uma cópia de um banco de dados (provavelmente um arquivo de backup) para fora da empresa. Mas há todos os dados 'excluídos' potencialmente confidenciais dentro do arquivo. Agora gostaria de zerar a parte não utilizada do arquivo.

Isso é possível? Imagino que poderia criar um novo banco de dados e copiar tudo, ou talvez restaurar uma cópia do banco de dados para outro servidor sem a inicialização instantânea de arquivo habilitada e, em seguida, ser agressivo com um comando ShrinkFile para remover a maior parte ou toda a parte não utilizada do arquivo de banco de dados , mas existe um método menos manual e demorado? Idealmente, um comando para dizer ao SQL para zerar o arquivo, como teria feito se a inicialização instantânea de arquivo não estivesse habilitada.

Percebo que minha pergunta não é estritamente 'banco de dados', mas sei que muitos DBAs usarão a ferramenta SQLIO para verificar o desempenho de I/O em seus sistemas, então espero que alguém aqui seja capaz de responder a esta pergunta:

Quando executo o SQLIO, a terceira linha de saída diz algo como:

usando o contador do sistema para tempos de latência, 14318180 contagens por segundo

O que isso significa? Obtenho valores diferentes em sistemas diferentes e, como estou comparando sistemas diferentes, gostaria de saber o que esse número está me dizendo (se houver).

Atualmente, estou trabalhando no monitoramento do desempenho do SQL Server. Encontrei o seguinte script[1] que calcula 'Porcentagem de pesquisas de página' - a sugestão é que um valor "bom" seja algo menor que 100.

SELECT 1.0*cntr_value /
(SELECT 1.0*cntr_value
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Batch Requests/sec') 
AS [PageLookupPct]
FROM sys.dm_os_performance_counters
WHERE counter_name = 'Page lookups/sec'

Agora, executei esse script em cerca de uma dúzia de servidores diferentes - principalmente virtuais, mas alguns físicos, principalmente 2008R2 Enterprise, mas alguns de 2005, alguns ao vivo e alguns em desenvolvimento, e até mesmo uma edição física do 2008R2 Express que sempre foi apenas uma testemunha servidor e está atualmente inativo (sem espelhos configurados com failover ativo). Em apenas um desses servidores o valor esteve abaixo de 100. Na maioria dos casos, foi na casa dos 1000 ou pelo menos em meados dos 100. No servidor testemunha inativo, o valor era de ridículos 20.000!

Isso indica que temos problemas generalizados nessa área ou há alguma explicação inocente para o motivo desse número ser tão alto em tantos servidores diferentes? Estamos enfrentando um desempenho lento em alguns desses servidores, portanto, seria útil para mim entender melhor o que essa figura está me dizendo.

[1] - http://thomaslarock.com/2012/05/are-you-using-the-right-sql-server-performance-metrics/