Mark Freeman's questions

Quando eu executo isso:

DROP TABLE IF EXISTS #QueryHashes;
CREATE TABLE #QueryHashes (query_hash BINARY(8) NOT NULL PRIMARY KEY);

PRINT CAST(0x0169857CCD5BBBE4E AS BINARY(8)); -- just testing that the value is a legitimate BINARY(8)

/* Insert your query_hash values inside the outer parenthesis below, 
   each wrapped in parenthesis, comma-separated (for example, "(0x89E35F2D4C638298), (0x89E35F2D4C638298)") 
*/
INSERT INTO #QueryHashes (query_hash)
VALUES (0x0169857CCD5BBBE4E);

PRINT CAST(0x0169857CCD5BBBE4E AS BINARY(8)); -- just testing that the value is a legitimate BINARY(8)

Eu recebo este erro:

0x00169857CCD5BBBE Msg 2628, Nível 16, Estado 1, Linha 9 String ou dados binários seriam truncados na tabela 'tempdb.dbo.#QueryHashes______________________________________________________________________________________________________________000000000D06', coluna 'query_hash'. Valor truncado: ''. A instrução foi encerrada. 0x00169857CCD5BBBE

Observe que o valor na mensagem de erro parece ser uma string vazia.

Claramente, a inserção está falhando, enquanto as conversões funcionam. Alguém pode me ajudar a entender o que há de errado com a inserção ou definição da tabela? Mesmo se eu remover a "NOT NULL PRIMARY KEY", ainda recebo o mesmo erro.

(A intenção final é inserir alguns valores na tabela e juntá-los em uma grande consulta.)

Por que essas duas consultas produzem resultados diferentes (mas com cerca de um minuto de diferença uma da outra)?

SELECT  StartTime   =   sqlserver_start_time
  FROM  sys.dm_os_sys_info;

SELECT  StartTime   =   DATEADD(MILLISECOND, sqlserver_start_time_ms_ticks - ms_ticks, GETDATE()) 
  FROM  sys.dm_os_sys_info;

Qual é o mais preciso?

Quando executo o código a seguir em uma instância do Banco de Dados SQL do Azure (v12) ou SQL Server 2016, recebo valores na coluna EstimatedRowsRead , mas não na coluna EstimatedRows , e não estou vendo o motivo. Alguma ideia?

SET NOCOUNT ON;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

WITH XMLNAMESPACES(DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
,PlanHandles AS (
    SELECT  plan_handle
            ,total_elapsed_time =   SUM(total_elapsed_time)
            ,execution_count    =   SUM(execution_count)
      FROM  sys.dm_exec_query_stats
     GROUP  BY plan_handle
)
,Plans AS (
    SELECT  ph.plan_handle, qp.query_plan, ph.total_elapsed_time, ph.execution_count
      FROM  PlanHandles ph
            OUTER APPLY sys.dm_exec_query_plan(ph.plan_handle) qp
)
SELECT  p.total_elapsed_time
        ,p.execution_count
        ,p.plan_handle
        ,p.query_plan
        ,NodeId                 =   s.i.value(N'@NodeId', N'INT') 
        ,EstimatedRowsRead      =   s.i.value(N'(@EstimatedRowsRead)[1]', N'FLOAT')
        ,EstimatedRows          =   s.i.value(N'(@EstimatedRows)[1]', N'FLOAT')
  FROM  Plans p
        CROSS APPLY query_plan.nodes('/ShowPlanXML/BatchSequence/Batch/Statements/*') q(n)
        CROSS APPLY n.nodes('.//RelOp[IndexScan and IndexScan/Object[@Schema!="[sys]"]]') s(i)
 WHERE  s.i.value(N'(@EstimatedRowsRead)[1]', N'FLOAT') > 1.0;

Eu vejo a seguinte consulta em um Banco de Dados SQL do Azure (que tem Parametrização Forçada = FORCED, Parameter Sniffing = ON e Query Optimizer Fixes = ON) de dentro do Repositório de Consultas:

delete from [CMS_WebFarmTask] 
where [TaskIsAnonymous] = @0 
and [TaskID] not in ( select [TaskID] from [CMS_WebFarmServerTask] ) 
and [TaskCreated] < dateadd ( minute , @1 , getdate ( ) )

Possui um grande número de planos (17 na última hora), apesar de ambos os parâmetros serem inteiros com valores idênticos em cada plano:

        <ParameterList>
          <ColumnReference Column="@1" ParameterDataType="int" ParameterCompiledValue="(-3)" />
          <ColumnReference Column="@0" ParameterDataType="int" ParameterCompiledValue="(0)" />
        </ParameterList>

Por que apenas um plano não está sendo usado?

O SQL Server armazena em cache as tabelas temporárias criadas nos procedimentos armazenados e apenas as renomeia quando o procedimento termina e é executado posteriormente. Minha pergunta tem a ver com quando o espaço tempdb é liberado. Eu li que a tabela é truncada no final do procedimento . Eu li nos comentários que isso é tratado por sessão e vi uma pergunta sobre se a limpeza é necessária ou não respondida no MSDN . Mas e se ele nunca for executado pela mesma sessão duas vezes?

Também ouvi dizer que existe um processo de coleta de lixo em segundo plano que libera esse espaço quando a tabela está fora do escopo.

Truncando uma tabela temporária no final do procedimento armazenado que a cria parece fazer com que o espaço que a tabela usa em tempdb para os dados sejam liberados mais rapidamente do que se nenhuma instrução truncate for usada, apesar das expectativas em contrário. Por quê?

Quais seriam as implicações de desempenho relativo de usar ou não usar uma instrução truncada? Ao usar o isolamento SNAPSHOT, o tempdb é frequentemente estressado e eu acho que liberar o espaço usado no tempdb de uma grande tabela temporária o mais rápido possível impediria o crescimento desnecessário do tempdb. Essa economia de espaço potencial teria o custo do desempenho?

Aqui está algum código para reproduzir o problema (principalmente de @TheGameiswar, com algumas alterações):

SET NOCOUNT ON;
GO
ALTER PROC usp_test
AS
BEGIN
    IF object_id('tempdb..#temp') IS NOT NULL
        DROP TABLE #temp

    SELECT *
    INTO #temp
    FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused

    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS BeforeTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;
 --   TRUNCATE TABLE #temp
    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS AfterTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;

END
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'before'
FROM tempdb.sys.dm_db_file_space_usage;

EXEC usp_test
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'final'
FROM tempdb.sys.dm_db_file_space_usage;
GO 40

As linhas comentadas foram deixadas comentadas para algumas execuções e não comentadas para outras. Quando o TRUNCATEfoi comentado, demorou entre 2,25 e 4,5 segundos antes que os resultados da tempdb.sys.dm_db_file_space_usageconsulta (4472 páginas a mais e 34,9375 MB a mais) correspondessem ao resultado antes que o procedimento fosse executado. Com as linhas (incluindo o TRUNCATE) não comentadas, levou apenas cerca de 0,11 - 0,9 segundos. Esses resultados são de um sistema ativo, com um pequeno crescimento de dados na tabela de origem durante este experimento.

Exemplo de saída com o código comentado (2,69 segundos da primeira à última entrada "final"):

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:42.197

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.423

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.533

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.643

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.883

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.990

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.100

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.450

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.650

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.767

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.993

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.103

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.213

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.437

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.553

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.663

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.887

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:45.003

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:45.113

Resultados de amostra com o código sem comentários (0,11 segundos da primeira à última entrada "final"):

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:39.807

user object pages used user object space in MB                 BeforeTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

user object pages used user object space in MB                 AfterTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:40.160

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:40.270

Das cerca de 50 instâncias que gerencio atualmente, tenho duas que têm um deadlock quase todas as noites envolvendo "INSERT INTO msdb.dbo.sysjobhistory" (sempre a vítima) e "DELETE FROM msdb.dbo.sysjobhistory" chamado por "EXEC msdb.dbo.sp_purge_jobhistory", ambas as sessões executadas pela conta de serviço do SQL Server Agent. Eu nunca tive esse impasse em nenhuma das outras instâncias, nem em nenhum trabalho anterior. Em cada um desses servidores, os deadlocks ocorrem em horários diferentes durante a noite (1:30 sábados executados por um agendamento semanal para sp_purge_jobhistory ou 2:01 executados por uma etapa no agendamento noturno para syspolicy_purge_history).

Não parece haver nada significativamente diferente entre essas duas instâncias de "problema" e qualquer uma das outras. Um é um servidor de teste 2012 SP3 CU3 e o outro é uma instância de produção 2012 SP2.

Alguma ideia de como posso evitar isso?

sp_Blitz (20160715) está relatando "Too Much Free Memory" em uma instância de teste 2012 SP2 CU12 raramente usada (Developer Edition) que contém apenas os bancos de dados criados e usados ​​pelo SSRS. Os detalhes são:

0 GB de memória livre dentro do buffer pool do SQL Server, que é de 0 GB. Você pensaria que muita memória livre seria bom, mas verifique o URL para obter mais informações.

Modifiquei a consulta para retornar os valores brutos e obtive Livre = 587.896 e Total = 1.052.256. Minha consulta alterada:

SELECT Free = cFree.cntr_value, Total = cTotal.cntr_value
FROM sys.dm_os_performance_counters cFree
INNER JOIN sys.dm_os_performance_counters cTotal ON cTotal.object_name LIKE N'%Memory Manager%'
    AND cTotal.counter_name = N'Total Server Memory (KB)                                                                                                        '
WHERE cFree.object_name LIKE N'%Memory Manager%'
    AND cFree.counter_name = N'Free Memory (KB)                                                                                                                '
    AND CAST(cTotal.cntr_value AS BIGINT) * .3 <= CAST(cFree.cntr_value AS BIGINT)
     AND CAST(SERVERPROPERTY('edition') AS VARCHAR(100)) NOT LIKE '%Standard%'

dbo.sp_BlitzCache (@BringThePain = 1) exibe 316 linhas, todas aparentemente instruções internas de manutenção do SSRS. É mais provável que:

1. Eu tenho um problema conforme descrito em https://www.brentozar.com/blitz/too-much-free-memory/ , ou
2. A cláusula WHERE da consulta sp_Blitz precisa de ajustes para evitar um falso positivo nesta circunstância

No SQL Server 2012, tenho um Job Agent Alert configurado da seguinte forma:

EXEC msdb.dbo.sp_add_alert @name=N'Deadlock Alert', 
        @message_id=0, 
        @severity=0, 
        @enabled=1, 
        @delay_between_responses=0, 
        @include_event_description_in=1, 
        @category_name=N'[Uncategorized]', 
        @performance_condition=N'Locks|Number of Deadlocks/sec|_Total|>|0', 
        @job_id=N'00000000-0000-0000-0000-000000000000'

Tenho um trabalho agendado para ser executado todos os dias da semana às 17h30 que executa esta etapa:

EXEC msdb.dbo.sp_update_alert @name = N`enter code here`'Deadlock Alert', @enabled = 0;

Tenho outro que reativa o alerta às 8h todos os dias da semana. Ambos os trabalhos (e o alerta) estão funcionando bem há meses em dezenas de instâncias. Mas o trabalho às 17h30 da sexta-feira falhou em uma instância com as seguintes mensagens:

O object_name especificado ('Bloqueios') não existe. [SQLSTATE 42000] (Erro 14262) O object_name especificado ('Databases') não existe. [SQLSTATE 42000] (Erro 14262). A etapa falhou.

Se eu executar o comando sp_update_alert diretamente para esse alerta (com ativado definido como 0 ou 1). Eu recebo este erro:

Msg 14262, Nível 16, Estado 1, Procedimento sp_verify_performance_condition, Linha 50 O object_name especificado ('Bloqueios') não existe.

Tentei desabilitar o alerta usando a interface do usuário do SSMS e obtive:

O object_name especificado ('Bloqueios') não existe. (Microsoft SQL Server, erro: 14262)

Este par de tarefas ainda está funcionando sem erros em todas as outras instâncias. O que poderia estar causando a falha de sp_update_alert nisso ocorreu em apenas uma instância e somente desde sexta-feira?

[Adicionado:]

As tarefas habilitar e desabilitar também habilitam e desabilitam outro alerta, que examina o contador SQLServer:Databases|Data File(s) Size (KB)|tempdb e esses comandos lançam o erro "O object_name especificado ('Databases') não existe ". Novamente, apenas neste caso. Os mesmos trabalhos e alertas ainda funcionam bem em outra instância no mesmo servidor.

Estou usando o SSDT 14.0.50730.0 no Visual Studio Professional 2015. Estou comparando bancos de dados entre duas instâncias e descobri que existem procedimentos armazenados que não correspondem em relação às suas assinaturas.

Em ambas as instâncias, o Certificado foi criado em cada instância a partir do mesmo script e as assinaturas também foram adicionadas pelo CERTIFICADO com uma SENHA usando o mesmo script em cada instância.

No entanto, a Comparação de Esquema está mostrando o procedimento na origem e no destino como tendo um CERTIFICATE com uma ASSINATURA com valores de assinatura que não correspondem. COM ASSINATURA. O valor da assinatura corresponde ao que foi mostrado na instância de origem. No entanto, o script falha com a mensagem "A assinatura da chave pública é inválida".

O que devo fazer para sincronizar esses procedimentos?

Eu executei o seguinte:

USE [MyDatabase];
GO
CREATE LOGIN [MyDomain\MyAccount] FROM WINDOWS WITH DEFAULT_DATABASE=[MyDatabase];
CREATE USER [MyDomain\MyAccount] FOR LOGIN [MyDomain\MyAccount];
GRANT EXECUTE   ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];
GRANT SELECT    ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];
GRANT INSERT    ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];

(Não estou concedendo nenhuma função, pois não quero que este login seja capaz de acessar qualquer outro esquema neste banco de dados.)

Eu executo o SSMS como MyDomain\MyAccount (executo como um usuário diferente). Em seguida, tento conectar-me a esta instância. No entanto, estou obtendo:

Não é possível abrir banco de dados padrão do usuário. Falha na autenticação. Falha de login para o usuário
'MyDomain\MyAccount'. (Microsoft SQL Server, erro: 4064)

Obtenho o mesmo resultado se definir o banco de dados padrão como MyDatabase nas Propriedades da conexão.

Eu executei um rastreamento do Profiler e vejo um erro 18456 estado 38:

Falha de login para o usuário 'MyDomain\MyAccount'. Motivo: Falha ao abrir o banco de dados explicitamente especificado 'MyDatabase'. [CLIENTE: MyIpAddress]

Isso é seguido por um erro 18456 estado 40:

Falha de login para o usuário 'MyDomain\MyAccount'. Motivo: Falha ao abrir o banco de dados 'MyDatabase' especificado nas propriedades de login. [CLIENTE: MyIpAddress]

MyDatabase está online e não tenho problemas para me conectar a ele com um login diferente. Que permissão adicional preciso conceder a MyDomain\MyAccount? Há algo mais que estou perdendo?

Tenho um relatório de impasse que me diz que houve um conflito envolvendo

waitresource="KEY: 9:72057632651542528 (543066506c7c)"

e eu posso ver isso:

<keylock hobtid="72057632651542528" dbid="9" objectname="MyDatabase.MySchema.MyTable" indexname="MyPrimaryKeyIndex" id="locka8c6f4100" mode="X" associatedObjectId="72057632651542528">

dentro do <resource-list>elemento.

Quero poder encontrar o valor real da chave (id = 12345, por exemplo). Qual instrução SQL eu precisaria usar para obter essas informações?

Eu tenho um banco de dados em dois servidores de produção diferentes. Eu quero manter os esquemas consistentes entre os dois. Um tem trabalhos que chamam procedimentos armazenados que fazem referência a um servidor vinculado. O outro não contém (e não deve) esses trabalhos ou um servidor vinculado com o mesmo nome do primeiro servidor, mas desejo que ambos os servidores tenham os mesmos procedimentos armazenados. No entanto, o SQL Server se recusa a criar os procedimentos que fazem referência ao Linked Server no servidor que não possui Linked Server configurado. Entendo por que isso acontece, mas preciso de uma solução alternativa que não envolva alterar o código do procedimento (como usar SQL dinâmico para ocultar a referência do compilador).

Tentei criar um servidor vinculado com o nome esperado que aponta para o servidor local, mas o SQL Server é inteligente o suficiente para ver que as tabelas referenciadas não existem nesse servidor vinculado. Se eu criar um para um servidor inexistente, o SQL expira durante a criação do procedimento, informando que não foi possível conectar-se ao servidor remoto.

Existe alguma maneira de criar um servidor vinculado fictício de modo que o SQL Server não tente validar os nomes das tabelas no servidor vinculado?

Em uma instância do SQL Server 2012 SP2 Standard Edition, tenho um usuário no banco de dados A que precisa ser capaz de executar procedimentos armazenados no esquema foo dentro desse banco de dados. Eles não devem ser capazes de fazer mais nada. Por exemplo, eles não devem ser capazes de SELECT diretamente de qualquer visão ou tabela em qualquer banco de dados.

As stored procedures SELECT das tabelas nos bancos de dados A e B. Eu criei as procedures WITH EXEC AS OWNER. O banco de dados A pertence a sa, que tem a função sysadmin e, portanto, deve ter acesso a ambos os bancos de dados. Eu corri isso:

USE [master]
GO
CREATE LOGIN [foo] WITH PASSWORD=N'foo', DEFAULT_DATABASE=[A]
GO
USE [A]
GO
CREATE USER [foo] FOR LOGIN [foo]
ALTER ROLE [db_executor] ADD MEMBER [foo];
GO
GRANT EXECUTE ON SCHEMA :: [Bar] TO [foo];

Eu então conectei como [foo] e executei o procedimento, mas recebi o erro:

Msg 916, Nível 14, Estado 1, Procedimento GetReport, Linha 10 O servidor principal "sa" não pode acessar o banco de dados "A" no contexto de segurança atual.

Definir TRUSTWORTHY ON parece abrir as coisas muito mais do que é aceitável. Existe outra solução?

Em uma instância do SQL Server 2012 SP1, tenho um índice filtrado na coluna PK de uma tabela semelhante a esta:

CREATE INDEX [RF_IXF_Orders_OrderNumber] ON [dbo].[Orders]
(
    [OrderNumber] ASC
)
WHERE [OrderSource]='MO'
AND [Cancelled]=(0)
AND [NumItems]>(0)
AND [OrderDate]>'2014-05-15';

A contagem de linhas (dm_db_partition_stats.row_count) do índice é 8416, as linhas alteradas (sysindexes.rowmodctr) são 16803 (193,6%) e as estatísticas de atualização automática são verdadeiras. Houve 8.400 user_scans e 50.088 user_updates. O último user_scan foi hoje, mas as estatísticas não foram atualizadas em cerca de uma semana.

Por que as estatísticas não foram atualizadas automaticamente?

Eu tenho um pacote que estou atualizando. O pacote é executado por um job do Job Agent. Depois de excluir o pacote e implantar a nova versão, executo um script que executa todas as instruções [create_environment], [create_environment_reference], [create_environment_variable] e [set_object_parameter_value] necessárias.

No entanto, quando inicio o trabalho, ele falha com a seguinte mensagem de erro (onde "n" é um número que não aparece em nenhuma das tabelas ou visualizações relevantes do SSISDB como um id de qualquer tipo):

A referência de ambiente n não está associada ao projeto

Estou usando o Visual Studio 2012 Professional com SQL Server Data Tools com uma instância de banco de dados de edição padrão do SQL Server 2012.
Não consegui localizar um arquivo master.dacpac em minha máquina de desenvolvimento ou no servidor que hospeda a instância do SQL Server.

Como posso obter este arquivo, para que eu possa me livrar de avisos como o seguinte:

SQL71502: Procedure: <ProcedureName> has an unresolved reference to object [sys].[objects]  

Tenho um job (Tíquetes de atualização) agendado no Job Agent com um agendamento único de "Ocorre todos os dias a cada 30 minuto(s) entre 00:00:00 e 23:59:59. O agendamento será utilizado a partir de 11/ 4/2013." Quando uso o Log File Viewer para ver o histórico desse trabalho, não vejo nenhuma entrada por um período de 2,5 horas ontem. Outras tarefas no mesmo servidor foram executadas durante o tempo em que esta tarefa teve uma lacuna nas execuções.

O trabalho faz um INSERT de SELECT de um OpenQuery de um servidor vinculado. Se houvesse uma rede ou outro problema que impedisse o êxito da conexão com a fonte de dados, eu ainda esperaria ver uma mensagem de falha de trabalho no log, mas não vejo nenhuma entrada para ela. Nem o log do SQL Server, o log do SQL Server Agent, nem os logs do sistema ou aplicativo do Windows mostram algo relevante durante o intervalo.

Quais são as possíveis causas disso?

Obrigado,

Marca

Espero que alguém possa lançar alguma luz sobre esse comportamento que eu não esperava em relação ao isolamento SNAPSHOT vs. TRUNCATE.

Banco de Dados: Permitir Isolamento de Instantâneo = Verdadeiro; Instantâneo de leitura confirmado ativado = falso.

Procedimento1 (Substitui o conteúdo da tabela foo de um SELECT complexo de longa duração com muitas junções):

BEGIN TRAN; 
TRUNCATE TABLE foo; 
INSERT INTO foo SELECT...; 
COMMIT;

Procedimento2 (lê da tabela foo):

SET TRANSACTION ISOLATION LEVEL SNAPSHOT; 
SELECT * FROM foo;

Se o Procedimento1 estiver em execução enquanto o Procedimento2 for executado, o Procedimento2 será retido com uma espera LCK_M_SCH_S (de acordo com sp_WhoIsActive) até que o Procedimento1 seja concluído. E quando o Procedimento2 é concluído, ele gera esta exceção:

A transação de isolamento de instantâneo falhou no banco de dados 'DatabaseName' porque o objeto acessado pela instrução foi modificado por uma instrução DDL em outra transação simultânea desde o início desta transação. Ele não é permitido porque os metadados não têm controle de versão. Uma atualização simultânea de metadados pode levar à inconsistência se combinada com isolamento de instantâneo.

No entanto, a Microsoft não lista TRUNCATE como uma instrução DDL não permitida sob isolamento SNAPSHOT: http://msdn.microsoft.com/en-us/library/bb933783.aspx

Claramente, não estou entendendo algo corretamente, pois esperava um melhor caso de Procedimento2 retornando imediatamente os dados confirmados mais recentemente da tabela antes do TRUNCATE ou um pior caso de ser retido por Procedimento1 e retornar o novo conteúdo do tabela. Você pode ajudar?

Eu herdei um banco de dados de 10 GB com um log de 80 GB [apenas 3% em uso de acordo com DBCC SQLPERF (logspace)]. Parece seguro presumir que o crescimento extremo do log foi devido a problemas muito antes de eu ser contratado.

O primário tem um trabalho de backup de envio de log executado a cada 15 minutos. O primário tem tarefas de cópia e restauração executadas a cada 15 minutos.

Quando tento reduzir o log, recebo "Não é possível reduzir o arquivo de log 2 (DatabaseName_log) porque o arquivo de log lógico localizado no final do arquivo está em uso". Eu tentei isso várias vezes com 15 minutos de intervalo e até dias de intervalo, mas sempre obtive o mesmo resultado.

DBCC LOGINFO mostra 784 VLFs, com apenas o primeiro 245 e o último com um status de 2. p_WhoIsActive mostra que a transação aberta mais longa foi executada por menos de 2 horas (transações longas não são incomuns aqui devido a um terceiro Microsoft Acesse o aplicativo com problemas de driver ODBC).

Como posso reduzir esse log com êxito (sem criar uma interrupção para os usuários)?

Obrigado, Marcos

Com base em Query Performance e funções com valor de tabela de várias instruções e outros artigos, o SQL Server assume que uma função com valor de tabela de várias linhas retorna uma linha. Isso causa a seleção de um plano de execução ruim para a instrução de chamada se ela realmente retornar muitas linhas.

A adição SCHEMABINDINGà função resulta em uma estimativa de cardinalidade mais correta para o conjunto de valores retornado da função?

Se assumirmos que estamos passando um UserId para esta função e recuperando uma tabela de valores de RecordId que o usuário pode acessar, e que alguns usuários podem ver apenas alguns registros e alguns podem ver muitos ou mesmo todos os registros, a função ou as instruções de chamada (ou os procedimentos que os incluem) se beneficiariam com o uso RECOMPILE? O uso de SCHEMABINDINGna função altera essa resposta?

Percebo que poderia descobrir isso por experimentação, mas espero que alguém já tenha descoberto a resposta. Um ponteiro para algum lugar onde isso esteja bem documentado seria útil.