Hannah Vernon's questions

Não sou especialista em PostgreSQL, mas recentemente me deparei com um código PostgreSQL durante uma revisão de código que cria e remove tabelas temporárias de uma maneira que parece consistente com a maneira típica como fazemos isso no SQL Server. Ou seja, no SQL Server faríamos:

DROP TABLE IF EXISTS #temp_data;
CREATE TABLE #temp_data
(
    i int NOT NULL
);

A revisão do código mostrou este código:

BEGIN;
DROP TABLE IF EXISTS temp_data;
COMMIT;

BEGIN;
CREATE TEMP TABLE IF NOT EXISTS temp_data(
    i int NOT NULL
);
COMMIT;

Esta resposta no Stack Overflow afirma que você não deve remover e recriar tabelas temporárias com frequência por causa do pg_attributeinchaço.

O ChatGPT (ah!) tem isso a dizer sobre pg_attributeinchaço:

No PostgreSQL, criar tabelas temporárias com frequência pode causar inchaço em pg_attribute, pois cada nova tabela temporária adiciona metadados que persistem nos catálogos do sistema mesmo depois que a tabela é descartada. Para evitar inchaço excessivo, considere estas práticas recomendadas:

1. Use ON COMMIT DELETE ROWSem vez de descartar tabelas:

CREATE TEMP TABLE temp_data (
   i int NOT NULL
) ON COMMIT DELETE ROWS;

2. Use pg_tempSchema para tabelas temporárias em nível de sessão

CREATE TEMP TABLE pg_temp.temp_data (
    id SERIAL PRIMARY KEY,
    value TEXT
);

Já que tenho muitas dúvidas sobre a veracidade de quaisquer alegações feitas por qualquer modelo de linguagem grande, qual abordagem devo escolher? De fato, qualquer uma das abordagens é válida?

Estou tentando adicionar uma sessão de Eventos Estendidos para rastrear eventos de conclusão de backup .

Estou fazendo isso como um precursor da atuação RESTORE HEADERONLY ... LOADHISTORYno nó secundário de um Grupo de Disponibilidade com a intenção de que ambos os nós AG tenham detalhes precisos nas msdb.dbo.backupsettabelas relacionadas. Grupos de Disponibilidade Contidos não são uma opção, pois estamos usando o SQL Server 2019. Também estamos usando Grupos de Disponibilidade Distribuídos, o que exclui AGs Contidos, portanto, mesmo que pudéssemos atualizar para o SQL Server 2022, os AGs Contidos ainda não ajudariam.

A definição do Evento Estendido é:

CREATE EVENT SESSION [backup_finished]
ON SERVER 
ADD EVENT [D5149520-6282-11DE-8A39-0800200C9A66].[sqlserver].[backup_restore_progress_trace]
(
    ACTION
    (
          [sqlserver].[client_app_name]
        , [sqlserver].[client_hostname]
        , [sqlserver].[database_name]
        , [sqlserver].[nt_username]
        , [sqlserver].[server_principal_name]
        , [sqlserver].[session_id]
        , [sqlserver].[sql_text]
    )
    WHERE 
    (
        /* this is the database name where the BACKUP operation took place, not the database being backed up. */
            [CE79811F-1A80-40E1-8F5D-7445A3F375E7].[sqlserver].[database_name] = N'maintenance' 
        /* this is the name of the database that was backed up */
        AND [database_name] = N'<database_of_interest>'
        /* 'Backup' or 'Restore' */
        AND [operation_type] = N'Backup'
        /* 
            0 -> Information of major steps in the operation
            1 -> Verbose I/O related information 
        */
        AND [trace_level] = 0 
        AND 
        (
            /* the trace_message contains one or more characters at the end */
               [trace_message] LIKE N'BACKUP DATABASE finished%'
            OR [trace_message] LIKE N'BACKUP LOG finished%'
        )
    )
)
WITH
(
      MAX_MEMORY = 4096 KB
    , EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS
    , MAX_DISPATCH_LATENCY = 30 SECONDS
    , MAX_EVENT_SIZE = 0 KB
    , MEMORY_PARTITION_MODE = NONE
    , TRACK_CAUSALITY = OFF
    , STARTUP_STATE = OFF
);
GO

[D5149520-6282-11DE-8A39-0800200C9A66]é o GUID do módulo para sqlmin.dll, que contém o código do [backup_restore_progress_trace]Evento Estendido.

[CE79811F-1A80-40E1-8F5D-7445A3F375E7]é o GUID do módulo para sqllang.dll, que contém a maior parte do [sqlserver]código do Evento Estendido.

Na cláusula where, tenho dois predicados para [database_name]; o primeiro [CE79811F-1A80-40E1-8F5D-7445A3F375E7].[sqlserver].[database_name] = N'maintenance' limita os eventos capturados a instruções que foram executadas no contexto do maintenancebanco de dados. Esse predicado é totalmente qualificado com o GUID do módulo para diferenciá-lo do [database_name]nome do campo de evento com nome idêntico.

Os predicados [database_name], [operation_type], [trace_level]e [trace_message]não são totalmente qualificados porque não consigo determinar como qualificá-los totalmente.

Tentei qualificar os predicados não qualificados com todos os GUIDs de módulo que encontrei, mas nenhum deles resolveu, retornando este erro quando tento criar o Evento Estendido:

Msg 25706, Nível 16, Estado 8, Linha 62
O atributo do evento ou origem do predicado, "6D503F55-3041-4A62-BB8C-57C3CF081B7B.sqlserver.database_name", não foi encontrado.
Msg 15151, Nível 16, Estado 22, Linha 105
Não é possível alterar a sessão do evento 'backup_finished' porque ela não existe ou você não tem permissão.

A lista de módulos e seus guias estão listados nesta consulta:

SELECT 
      [module_guid] = QUOTENAME([dxp].module_guid)
    , [package_name] = QUOTENAME([dxp].[name])
    , [module_file_name] = RIGHT([dolm].[name], CHARINDEX(N'\', REVERSE([dolm].[name])) - 1)
FROM 
    [sys].[dm_xe_packages] [dxp]
    INNER JOIN [sys].[dm_os_loaded_modules] [dolm] ON [dxp].[module_address] = [dolm].[base_address]
ORDER BY 
    [dxp].[name];

Resultados do meu servidor:

Alguém sabe o que devo usar para qualificar totalmente os predicados não qualificados?

Eu tenho um grupo de disponibilidade do SQL Server 2019 de dois nós com um banco de dados que possui CDC habilitado para várias tabelas. O CDC é usado para rastrear transações que não foram capturadas para população em um data warehouse.

O Grupo de Disponibilidade é configurado com failover de várias sub-redes, com secundários legíveis.

O aplicativo replica as transações capturadas via CDC usando sp_repltrans para obter uma lista de transações, que então lê por meio da função não documentada fn_dump_dblog. Depois que uma transação for capturada e integrada ao data warehouse, o aplicativo marcará a transação como replicada por meio de sp_repldone . Nós o configuramos para ApplicationIntent=ReadOnlyconectar-se automaticamente ao nó secundário legível do Grupo de Disponibilidade.

O processo de captura/integração parece estar funcionando bem e se recupera bem durante um failover do Grupo de Disponibilidade, alternando automaticamente para o outro nó conforme necessário para manter uma conexão com um secundário legível. As transações estão sendo capturadas no data warehouse.

Depois que as transações são replicadas no data warehouse, o aplicativo é executado sp_repldoneno secundário, o que parece ter sido bem-sucedido, mas a transação nunca é marcada como replicada no primário, fazendo com que o log de transações seja relatado REPLICATIONna log_reuse_wait_desccoluna de sys.databases.

O aplicativo chama sp_repldoneassim:

EXEC sys.sp_repldone
        @xactid = NULL
      , @xact_seqno = NULL
      , @numtrans= 0
      , @time= 0
      , @reset= 1;

O acima foi capturado por meio de Extended Events sp_statement_completed. A sessão de captura de Eventos Estendidos também está configurada para capturar eventos de erro e nenhum está sendo relatado.

Se eu executar manualmente sp_repltranspara obter uma lista de transações não replicadas e, em seguida, executar sp_repldoneessa lista no secundário, parece ter êxito sem problemas, mas o primário ainda acredita que as transações não foram replicadas. ou seja, a execução sp_repltransno primário ainda mostra transações aguardando replicação.

Não vejo nada nos documentos de sp_repldone indicando que ele pode ou não ser executado a partir de um secundário legível; na verdade, eu acho que retornaria um erro se não pudesse marcar as transações como replicadas, mas talvez haja um bug na implementação. É certo que esta configuração provavelmente não é tão comum. Se configurarmos o processo de captura/integração para anexar ao nó primário, removendo ApplicationIntent=ReadOnly, a execução sp_repldoneno primário funcionará corretamente e todas as transações serão marcadas como replicadas, permitindo a reutilização do log de transações.

Há algo que precisa ser alterado para que isso funcione no secundário legível?

Relatei o comportamento por meio do site de Feedback do Azure aqui .

Considere o seguinte código de exemplo mínimo, completo e verificável (veja dbfiddle aqui ):

CREATE TABLE [dbo].[test]
(
      [i] bigint NOT NULL 
        identity(1,1) 
        PRIMARY KEY CLUSTERED
    , [d] varchar(10) NOT NULL
);
GO

Com um INSTEAD OF INSERT, UPDATEgatilho:

CREATE TRIGGER [dbo_test_trigger]
ON [dbo].[test]
INSTEAD OF INSERT, UPDATE
AS
BEGIN
    IF ROWCOUNT_BIG() = 0 RETURN;

    SET NOCOUNT ON;

    MERGE INTO [dbo].[test] [target]
    USING [inserted] [source] ON [target].[i] = [source].[i]
    WHEN NOT MATCHED THEN
        INSERT
        (
            [d]
        )
        VALUES 
        (
            [source].[d]
        )
    WHEN MATCHED THEN 
        UPDATE
        SET [target].[d] = [source].[d];
END;
GO

Estou executando um insert na tabela, na esperança de obter o valor da identidade inserida, porém o valor retornado é 0:

DECLARE @output TABLE
(
      [i] bigint NOT NULL
    , [d] varchar(10) NOT NULL
);

INSERT INTO [dbo].[test]
(
    [d]
)
OUTPUT 
      [inserted].[i]
    , [inserted].[d]
INTO @output 
(
      [i]
    , [d]
) 
VALUES ('test');

/* shows [i] is 0 */
SELECT *
FROM @output;

/* shows [i] is 1 */
SELECT *
FROM [dbo].[test];

Os resultados são:

e

O resultado desejado seria que ambos os conjuntos de resultados correspondessem, mas isso não acontece.

O que estou fazendo de errado?

Eu vi isso, no entanto, que parece bem diferente, já que não estou usando nenhuma visualização. O gatilho está na mesa no meu exemplo.

Eu tenho um trabalho do SQL Server Agent projetado para se reconfigurar em resposta às condições existentes quando o trabalho é iniciado.

Então, em essência, a primeira etapa atualiza a segunda etapa. Isso acontece corretamente, mas parece que o processo do SQL Server Agent não sabe que a segunda etapa foi atualizada e executa a cópia antiga em cache do comando da etapa 2. Tentei adicionar sp_update_joba primeira etapa na tentativa de fazer com que o processo do Agente atualizasse seu cache, mas não foi uma alegria.

Aqui está um mcve para seu prazer:

BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'Test self-updating job', 
        @enabled=1, 
        @notify_level_eventlog=0, 
        @notify_level_email=0, 
        @notify_level_netsend=0, 
        @notify_level_page=0, 
        @delete_level=0, 
        @description=N'No description available.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'sa', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'step 1 - update step 2', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=3, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'TSQL', 
        @command=N'USE [msdb];
GO
DECLARE @job_name sysname = N''Test self-updating job'';

DECLARE @command nvarchar(max);
IF EXISTS
(
    SELECT 1
    FROM [msdb].[dbo].[sysjobsteps] [sjs]
        INNER JOIN [msdb].[dbo].[sysjobs] [sj] ON [sjs].[job_id] = [sj].[job_id]
    WHERE [sj].[name] = N''Test self-updating job''
        AND [sjs].[step_id] = 2
        AND [sjs].[command] = N''PRINT N''''A'''';''
)
BEGIN
    SET @command = N''PRINT N''''B'''';''; 
END
ELSE
BEGIN
    SET @command = N''PRINT N''''A'''';''; 
END;
EXEC [msdb].[dbo].[sp_update_jobstep] @job_name = @job_name, @step_id = 2, @command = @command;
EXEC [msdb].[dbo].[sp_update_job] @job_name = @job_name, @automatic_post = 1;
', 
        @database_name=N'master', 
        @flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'step 2 - do the work', 
        @step_id=2, 
        @cmdexec_success_code=0, 
        @on_success_action=1, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'TSQL', 
        @command=N'PRINT N''A'';', 
        @database_name=N'master', 
        @flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:
GO

O trabalho de teste começa com a 2ª etapa alternando entre a impressão Aou Bcada execução. ou seja, na primeira vez que for executado, ele deverá imprimir B, na próxima vez que for executado, deverá imprimir A, na próxima vez que for executado, deverá imprimir Be assim por diante.

Executar o trabalho e verificar o histórico do trabalho mostra que a saída é A, porém a inspeção do comando para a segunda etapa mostra que é PRINT N'B';. Portanto, o comando step está sendo atualizado, mas o Agente está, na verdade, executando o antigo código de etapa pré-atualizado.

Existe uma maneira de fazer com que o SQL Server Agent execute o código atualizado na etapa 2 em vez do código antigo e desatualizado?

No trabalho real, a segunda etapa é o comando cmdExec que é executado usando um proxy, portanto não posso usar SQL dinâmico em uma única etapa.

Como determino o nível de isolamento padrão para nossa instância 11.5 do DB2 em execução no Linux?

Vejo que há um "registro especial" nesta documentação da IBM , no entanto, não sou um especialista em DB2, portanto não tenho certeza de onde procurar isso ou como "ver" valores para registros "especiais".

Eu também olhei para this , mas também não estou tendo sorte em entender como obter o isolamento atual disso.

A configuração do meu laboratório doméstico consiste em quatro servidores executados no HyperV em dois hosts físicos. As instâncias do SQL Server são SQLAG101, SQLAG102, SQLAG201 e SQLAG202.

SQLAG101 e SQLAG102 são membros do SQLAG100 Availability Group e estão na rede 192.168.0.0/24.

SQLAG201 e SQLAG202 são membros do SQLAG200 Availability Group e estão na rede 192.168.2.0/24.

O tráfego é roteado entre as duas sub-redes, que são locais para meu laboratório (ou seja, há muito pouca latência envolvida).

SQLDAG é um Grupo de Disponibilidade Distribuído que abrange SQLAG100 e SQLAG200. Isso está funcionando bem há cerca de 6 meses, com failover automático entre os servidores membros do AG e failovers manuais entre os dois AGs funcionando corretamente e sem perda de dados.

No meu servidor de teste, estou vendo os seguintes erros no meu Distributed AG Forwarder para um banco de dados usando FILESTREAM:

O sistema operacional retornou o erro '2(O sistema não pode encontrar o arquivo especificado.)' ao tentar 'CreateFileW' em 'F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8 -922c-4821-904e-7555c031630d\0000008f-000292b0-0006' em 'fsdohdlr.cpp'(2474).

A movimentação de dados dos Grupos de Disponibilidade Always On para o banco de dados 'dag_test_db' foi suspensa pelo seguinte motivo: "system" (Source ID 3; Source string: 'SUSPEND_FROM_CAPTURE'). Para retomar a movimentação de dados no banco de dados, você precisará retomar o banco de dados manualmente. Para obter informações sobre como retomar um banco de dados de disponibilidade, consulte os Manuais Online do SQL Server.

^{(adoro essa referência do Books Online, btw)}

Para solucionar problemas, abandonei completamente o dag_test_dbencaminhador e os encaminhadores secundários. Em seguida, fiz um backup completo do primário, restaurei-o no encaminhador e continuei restaurando os backups de log conforme necessário antes de adicionar o dag_test_dbretorno ao Grupo de Disponibilidade dos encaminhadores por meio deALTER DATABASE [dag_test_db] SET HADR AVAILABILITY GROUP = SQLAG200;

Inicialmente, o painel do grupo de disponibilidade para os encaminhadores AG (SQLAG200) mostrou o banco de dados como sendo sincronizado, mas após cerca de uma hora o estado de sincronização é exibido NOT SYNCHRONIZINGe a descrição do motivo da integridade da sincronização é exibida SUSPEND_FROM_CAPTURE.

A execução chkdsk /fna unidade F: não relata erros.

dbcc checkdb (dag_test_db)do primário não retorna nenhum erro.

Escrevi uma consulta para ler todos os dados do filestream; talvez isso mostre algo interessante. Assim que tiver os resultados desse teste, atualizarei a pergunta. A consulta está usando ApplicationIntent=ReadOnlyvia sqlcmd.exe para se conectar à instância do encaminhador. Esta é a consulta, para os interessados:

USE [dag_test_db];
GO
DECLARE @d varbinary(max);
DECLARE @f nvarchar(260);
DECLARE cur CURSOR LOCAL FORWARD_ONLY READ_ONLY
FOR
SELECT
      [f].[file_data]
    , [f].[original_file_name]
FROM [dbo].[files] [f];

OPEN cur;
FETCH NEXT FROM cur INTO @d, @f;
WHILE @@FETCH_STATUS = 0
BEGIN
    PRINT @f + N': ' + CONVERT(nvarchar(11), LEN(@d), 0);
    FETCH NEXT FROM cur INTO @d, @f;
END
CLOSE cur;
DEALLOCATE cur;

Talvez algum jovem e arrojado engenheiro da Microsoft possa me ajudar a entender o que está causando um erro em fsdohdlr.cpp at 2474?

DBCC CHECKDB ([dag_test_db]) WITH NO_INFOMSGS;no primário global não mostra nenhuma corrupção.

Converter o nome do arquivo na mensagem de erro para um LSN decimal e usar fn_dblogno primário global para exibir o conteúdo do log mostra:

O arquivo referenciado na mensagem de erro existe no sistema de arquivos do encaminhador:

C:\Users\Hannah>dir F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031 630d\0000008f-000292b0-0006
 O volume na unidade F não tem rótulo.
 O número de série do volume é 90BA-CEC3

 Diretório de F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d

28/04/2023 22:27 797.346 0000008f-000292b0-0006
               1 Arquivo(s) 797.346 bytes
               0 Dir(s) 123.663.937.536 bytes livres

icaclspara o caminho em questão no encaminhador mostra:

icacls F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d
F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d NT SERVICE\MS$H V2019:(I)(OI)(CI)(F )
                                                                                                                                           DIREITOS DO PROPRIETÁRIO:(I)(OI)(CI)(F)
                                                                                                                                           BUILTIN\Administradores:(I)(OI)(CI)(F)

1 arquivo processado com sucesso; Falha ao processar 0 arquivos

As permissões parecem boas pelo que posso ver - o serviço SQL Server como controle total sobre o arquivo e, de fato, toda a estrutura de pastas de F:\SQLServer\HV2019.

Estou no processo de configuração de um Grupo de Disponibilidade no SQL Server 2019 no Windows Server 2019.

Temos dois servidores Windows, UT01 e UT02, configurados com um único adaptador de rede, usando endereços IP estáticos em um domínio do Active Directory.

O grupo de rede atribuiu um endereço IP estático para o Cluster Virtual Computer Object, UTCL, 192.168.0.12. Eles também atribuíram um endereço IP estático para o Availability Group Listener, UTAG, 192.168.0.13.

A equipe do servidor configurou o Windows Server Failover Cluster e eu configurei os SQL Servers e o Availability Group. Ambos os SQL Servers são configurados como instâncias nomeadas; assim UT01\INSe UT02\INSsão os nomes retornados por@@SERVERNAME;

De qualquer máquina na sub-rede local (192.168.0.0/24), posso me conectar ao Grupo de Disponibilidade usando o sqlcmd como tal:

sqlcmd -S UTAG\INS

Quando eu executo PRINT @@SERVERNAME;, UT01\INSou UT02\INSé retornado, dependendo de qual nó está executando o nó primário do Grupo de Disponibilidade.

Posso me conectar aos SQL Servers individuais de uma rede fora da sub-rede local, por meio de um roteador, usando sqlcmd, ou seja, sqlcmd -S UT01\INSe sqlcmd -S UT02\INSfuncionar corretamente, retornando o nome de instância apropriado para @@SERVERNAME.

Tudo bem até agora, e completamente como esperado.

No entanto, quando tento me conectar ao nome AG por meio de uma sub-rede não local, o AG responde apenas quando UT01 está executando o nó primário. Quando UT02 está executando o nó primário, obtemos o erro típico de conectividade:

Ocorreu um erro relacionado à rede ou específico da instância ao estabelecer uma conexão com o SQL Server. Servidor não encontrado ou não acessível. Verifique se o nome da instância está correto e se o SQL Server está configurado para permitir conexões remotas.

O log de erro do SQL Server em UT02 não mostra logins com falha (ele é configurado com o padrão para auditar logins com falha).

ping UTAGretorna o endereço IP correto, 192.168.0.13, independentemente de onde eu o executo. ping UTAGfunciona corretamente na sub-rede local e funciona nas sub-redes remotas quando o AG está sendo executado em UT01, mas não quando UT02 é o primário.

Instalei o WireShark no UT01 e no UT02 para ver se consigo determinar o que está acontecendo. Eu filtrei a saída do WireShark:

((tcp.port == 2136) || (udp.port == 1434)) && ((ip.dst == 192.168.0.13 || ip.src == 192.168.0.13))

A porta de escuta do SQL Server AG está configurada para escutar na porta 2136 e ambas as instâncias também estão configuradas para escutar na porta 2136. O SQL Server Configuration Manager mostra que a configuração de rede está configurada para escutar em todos os endereços IP.

Assistir ao WireShark no UT01, ao tentar se conectar ao AG de um cliente localizado em outra sub-rede, mostra o tráfego TCP de entrada na porta 2136 e o ​​tráfego UDP na porta 1434, independentemente de qual nó é o AG primário. Quando o AG primário está sendo executado em UT01, a conexão com o AG funciona, quando o AG primário está em UT02, a conexão com o AG falha.

Ambos os servidores são máquinas virtuais, rodando em hosts físicos separados. O switch (virtual ou não) está claramente ciente de qual nó está executando o primário, pois ping UTAGa partir da sub-rede local funciona independentemente de qual nó possui o endereço IP UTAG. ping UTAGde qualquer outra sub-rede só responde quando o AG está rodando em UT01.

Alguma ideia?

Estou tentando otimizar a extração de valores obtidos de uma API REST que retorna valores json em uma matriz.

Aqui está um exemplo mínimo, completo e verificável que reflete exatamente o que estou fazendo.

USE tempdb;

DROP TABLE IF EXISTS dbo.json_test;

CREATE TABLE dbo.json_test
(
    json_test_id                int                 NOT NULL
        IDENTITY(1,1)
    , some_uniqueidentifier     uniqueidentifier    NULL
    , some_varchar              varchar(100)        NULL
    , the_json                  nvarchar(max)       NULL
);

INSERT INTO dbo.json_test (some_uniqueidentifier, some_varchar, the_json)
SELECT 
        some_uniqueidentifier       = NEWID()
      , some_varchar                = CONVERT(varchar(100), CRYPT_GEN_RANDOM(64), 1)
      , the_json = (
            SELECT st.* 
            FROM sys.tables st
                CROSS JOIN sys.tables st2
            WHERE st.object_id = t.object_id FOR JSON AUTO
            )
FROM sys.tables t;

;WITH src AS 
(
    SELECT jt.some_uniqueidentifier
        , jt.some_varchar
        , top_array.[key]
        , top_array.[value]
    FROM dbo.json_test jt
        CROSS APPLY OPENJSON(jt.the_json, N'lax $') top_array
),
src2 AS
(
    SELECT src.some_uniqueidentifier
        , src.some_varchar
        , src.[key]
        , src.[value]
        , inner_key = inner_array.[key]
        , inner_value = inner_array.[value]
    FROM src
        CROSS APPLY OPENJSON(src.[value], N'lax $') inner_array
)
SELECT src2.some_uniqueidentifier
    , src2.some_varchar
    , src2.[key]
    , [name]                                = MAX(CASE WHEN src2.[inner_key] = 'name'                               THEN src2.[inner_value] ELSE NULL END)
    , [object_id]                           = MAX(CASE WHEN src2.[inner_key] = 'object_id'                          THEN src2.[inner_value] ELSE NULL END)
    , [principal_id]                        = MAX(CASE WHEN src2.[inner_key] = 'principal_id'                       THEN src2.[inner_value] ELSE NULL END)
    , [schema_id]                           = MAX(CASE WHEN src2.[inner_key] = 'schema_id'                          THEN src2.[inner_value] ELSE NULL END)
    , [parent_object_id]                    = MAX(CASE WHEN src2.[inner_key] = 'parent_object_id'                   THEN src2.[inner_value] ELSE NULL END)
    , [type]                                = MAX(CASE WHEN src2.[inner_key] = 'type'                               THEN src2.[inner_value] ELSE NULL END)
    , [type_desc]                           = MAX(CASE WHEN src2.[inner_key] = 'type_desc'                          THEN src2.[inner_value] ELSE NULL END)
    , [create_date]                         = MAX(CASE WHEN src2.[inner_key] = 'create_date'                        THEN src2.[inner_value] ELSE NULL END)
    , [modify_date]                         = MAX(CASE WHEN src2.[inner_key] = 'modify_date'                        THEN src2.[inner_value] ELSE NULL END)
    , [is_ms_shipped]                       = MAX(CASE WHEN src2.[inner_key] = 'is_ms_shipped'                      THEN src2.[inner_value] ELSE NULL END)
    , [is_published]                        = MAX(CASE WHEN src2.[inner_key] = 'is_published'                       THEN src2.[inner_value] ELSE NULL END)
    , [is_schema_published]                 = MAX(CASE WHEN src2.[inner_key] = 'is_schema_published'                THEN src2.[inner_value] ELSE NULL END)
    , [lob_data_space_id]                   = MAX(CASE WHEN src2.[inner_key] = 'lob_data_space_id'                  THEN src2.[inner_value] ELSE NULL END)
    , [filestream_data_space_id]            = MAX(CASE WHEN src2.[inner_key] = 'filestream_data_space_id'           THEN src2.[inner_value] ELSE NULL END)
    , [max_column_id_used]                  = MAX(CASE WHEN src2.[inner_key] = 'max_column_id_used'                 THEN src2.[inner_value] ELSE NULL END)
    , [lock_on_bulk_load]                   = MAX(CASE WHEN src2.[inner_key] = 'lock_on_bulk_load'                  THEN src2.[inner_value] ELSE NULL END)
    , [uses_ansi_nulls]                     = MAX(CASE WHEN src2.[inner_key] = 'uses_ansi_nulls'                    THEN src2.[inner_value] ELSE NULL END)
    , [is_replicated]                       = MAX(CASE WHEN src2.[inner_key] = 'is_replicated'                      THEN src2.[inner_value] ELSE NULL END)
    , [has_replication_filter]              = MAX(CASE WHEN src2.[inner_key] = 'has_replication_filter'             THEN src2.[inner_value] ELSE NULL END)
    , [is_merge_published]                  = MAX(CASE WHEN src2.[inner_key] = 'is_merge_published'                 THEN src2.[inner_value] ELSE NULL END)
    , [is_sync_tran_subscribed]             = MAX(CASE WHEN src2.[inner_key] = 'is_sync_tran_subscribed'            THEN src2.[inner_value] ELSE NULL END)
    , [has_unchecked_assembly_data]         = MAX(CASE WHEN src2.[inner_key] = 'has_unchecked_assembly_data'        THEN src2.[inner_value] ELSE NULL END)
    , [text_in_row_limit]                   = MAX(CASE WHEN src2.[inner_key] = 'text_in_row_limit'                  THEN src2.[inner_value] ELSE NULL END)
    , [large_value_types_out_of_row]        = MAX(CASE WHEN src2.[inner_key] = 'large_value_types_out_of_row'       THEN src2.[inner_value] ELSE NULL END)
    , [is_tracked_by_cdc]                   = MAX(CASE WHEN src2.[inner_key] = 'is_tracked_by_cdc'                  THEN src2.[inner_value] ELSE NULL END)
    , [lock_escalation]                     = MAX(CASE WHEN src2.[inner_key] = 'lock_escalation'                    THEN src2.[inner_value] ELSE NULL END)
    , [lock_escalation_desc]                = MAX(CASE WHEN src2.[inner_key] = 'lock_escalation_desc'               THEN src2.[inner_value] ELSE NULL END)
    , [is_filetable]                        = MAX(CASE WHEN src2.[inner_key] = 'is_filetable'                       THEN src2.[inner_value] ELSE NULL END)
    , [is_memory_optimized]                 = MAX(CASE WHEN src2.[inner_key] = 'is_memory_optimized'                THEN src2.[inner_value] ELSE NULL END)
    , [durability]                          = MAX(CASE WHEN src2.[inner_key] = 'durability'                         THEN src2.[inner_value] ELSE NULL END)
    , [durability_desc]                     = MAX(CASE WHEN src2.[inner_key] = 'durability_desc'                    THEN src2.[inner_value] ELSE NULL END)
    , [temporal_type]                       = MAX(CASE WHEN src2.[inner_key] = 'temporal_type'                      THEN src2.[inner_value] ELSE NULL END)
    , [temporal_type_desc]                  = MAX(CASE WHEN src2.[inner_key] = 'temporal_type_desc'                 THEN src2.[inner_value] ELSE NULL END)
    , [history_table_id]                    = MAX(CASE WHEN src2.[inner_key] = 'history_table_id'                   THEN src2.[inner_value] ELSE NULL END)
    , [is_remote_data_archive_enabled]      = MAX(CASE WHEN src2.[inner_key] = 'is_remote_data_archive_enabled'     THEN src2.[inner_value] ELSE NULL END)
    , [is_external]                         = MAX(CASE WHEN src2.[inner_key] = 'is_external'                        THEN src2.[inner_value] ELSE NULL END)
    , [history_retention_period]            = MAX(CASE WHEN src2.[inner_key] = 'history_retention_period'           THEN src2.[inner_value] ELSE NULL END)
    , [history_retention_period_unit]       = MAX(CASE WHEN src2.[inner_key] = 'history_retention_period_unit'      THEN src2.[inner_value] ELSE NULL END)
    , [history_retention_period_unit_desc]  = MAX(CASE WHEN src2.[inner_key] = 'history_retention_period_unit_desc' THEN src2.[inner_value] ELSE NULL END)
    , [is_node]                             = MAX(CASE WHEN src2.[inner_key] = 'is_node'                            THEN src2.[inner_value] ELSE NULL END)
    , [is_edge]                             = MAX(CASE WHEN src2.[inner_key] = 'is_edge'                            THEN src2.[inner_value] ELSE NULL END)
FROM src2
GROUP BY src2.some_uniqueidentifier
    , src2.some_varchar
    , src2.[key]
ORDER BY src2.some_uniqueidentifier
    , src2.some_varchar
    , src2.[key];

O plano de consulta usa algumas junções de loops aninhados, independentemente de quantas linhas estão contidas na tabela de entrada. Presumivelmente, isso é um artefato de usar o CROSS APPLYoperador. Para sua diversão, já configurei um DB Fiddle .

Existe uma maneira mais eficiente de obter os dados do formato json em um conjunto "real" de colunas?

Criei o código acima usando minha instância local do SQL Server 2019, mas o destino será o Banco de Dados SQL do Azure, portanto, todas as opções mais recentes e melhores estão disponíveis.

Eu tenho uma tabela de valores de geometria onde algumas linhas se cruzam com outras linhas.

Preciso de uma lista de linhas em que a geometria se sobreponha a outras linhas, mas gostaria que a lista fosse o mais concisa possível.

Aqui está a configuração:

USE tempdb;
DROP TABLE IF EXISTS dbo.t;

CREATE TABLE dbo.t
(
    n varchar(100) NOT NULL
    , i geometry NOT NULL
);

INSERT INTO dbo.t (n, i)
VALUES ('poly1', geometry::STGeomFromText('POLYGON ((1 2, 1 4, 1 5, 4 6, 1 2))', 4326))
     , ('poly2', geometry::STGeomFromText('POLYGON ((1 2, 1 3, 2 5, 4 6, 1 2))', 4326))
     , ('poly3', geometry::STGeomFromText('POLYGON ((7 9, 8 7, 9 6, 7 9))', 4326))

SELECT t1.n
    , t2.n
FROM dbo.t t1
    INNER JOIN dbo.t t2 ON t1.i.STIntersects(t2.i) = 1
WHERE 
    t1.n <> t2.n;

A saída se parece com:

No entanto, eu gostaria de apenas uma única linha para brevidade. ou seja, porque poly1 se sobrepõe a poly2 e poly2 se sobrepõe a poly1, estou recebendo duas linhas retornadas onde gostaria de apenas uma, como em:

Considere a seguinte configuração, que você pode mexer em dbfiddle.uk :

No primeiro lote, configuramos três tabelas simples e adicionamos uma linha a cada tabela:

CREATE TABLE t1 (x int NOT NULL);
CREATE TABLE t2 (y int NOT NULL);
CREATE TABLE t3 (z int NOT NULL);

INSERT INTO t1 (x) VALUES (1);
INSERT INTO t2 (y) VALUES (2);
INSERT INTO t3 (z) VALUES (3);

Em seguida, criaremos três procedimentos armazenados:

DELIMITER //

CREATE PROCEDURE proc1()
BEGIN
    UPDATE t1 SET x = x + 1;
END
//

CREATE PROCEDURE proc2()
BEGIN
    UPDATE t2 SET y = y - 1;
END
//

CREATE PROCEDURE proc3()
BEGIN
    UPDATE t3 SET z = z / 0;
END
///

Em seguida, iniciaremos uma transação, executaremos os três procs e, em seguida, reverteremos a transação. Observe que estamos desabilitando o autocommit explicitamente, embora isso não seja estritamente necessário, pois temos uma transação explícita:

SET autocommit = 0;
START TRANSACTION
CALL proc1();
CALL proc2();
CALL proc3();
ROLLBACK

Agora, se inspecionarmos o conteúdo das três tabelas, notamos que a reversão parece não ter ocorrido. Na verdade, as linhas são exatamente como se não houvesse nenhuma transação, ou seja, parece que o autocommit estava ativado.

SELECT *
FROM t1;

SELECT *
FROM t2;

SELECT *
FROM t3;

Os resultados:

╔═══╗
║ x ║
╠═══╣
║ 2 ║
╚═══╝
╔═══╗
║ e ║
╠═══╣
║ 1 ║
╚═══╝
╔═══╗
║ z ║
╠═══╣
║ 3 ║
╚═══╝

O que está acontecendo aqui e como posso reverter as ações dos dois primeiros procs quando o terceiro claramente falha?

Para sua informação, isso foi testado no MySQL 5.7.2 e via DBFiddle.uk no MySQL 8.0.22.

Qual é o equivalente do tipo de dados do SQL Server varchar(max)no ASE?

Por ASE quero dizer o que costumava ser conhecido como Sybase ASE, que agora pertence à SAP.

Estou tentando executar um pedaço de T-SQL construído dinamicamente com mais de 8.000 caracteres.

Se eu declarar uma variável com varchar(max), ASE engasga com:

Sintaxe incorreta perto da palavra-chave 'max'.

Meu próximo pensamento foi tentar o tipo de textdados. Mas infelizmente:

Você especificou um tipo de dados incorreto para a variável que contém a string de comando 'execute imediato'.

Um exemplo mínimo, completo e verificável:

DECLARE @cmd varchar(max) --change this to varchar(4000) and it works
SET @cmd = 'SELECT 1;'
EXEC (@cmd);
GO

Alterar a declaração da variável para textou o que for adequado aos seus propósitos. Eu preciso executar um comando dinâmico que provavelmente tem 50.000 caracteres.

Como alternativa, eu poderia usar um cursor, mas não estou familiarizado com a forma como os cursores funcionam no ASE.

Observe que no SQL Anywhere, você pode definir um equivalente ao tipo de dados varchar(max) como declare @cmd long varchar;, mas isso não funcionará no ASE.

Na mensagem de erro a seguir, o motivo fornecido é "Opção de proteção inválida". O que isso indica?

O SQL Server detectou um erro de E/S baseado em consistência lógica: opção de proteção inválida

Para os fins desta pergunta, não preciso saber nada sobre "como executar o DBCC" ou "verificar se há corrupção". Eu entendi. Estou apenas curioso sobre a parte da "causa raiz" e o que poderia causar esse sabor do erro de E/S baseado em consistência lógica.

Pegue o seguinte código de exemplo ¹ minimamente completo e verificável :

USE tempdb;

DROP TABLE IF EXISTS dbo.t;
GO
CREATE TABLE dbo.t
(
    t_id int NOT NULL
        CONSTRAINT t_pk
        PRIMARY KEY 
        CLUSTERED
        IDENTITY(1,1)
    , k sysname NOT NULL
        INDEX t_001
    , s sysname NOT NULL
        INDEX t_002
    , somedata varchar(1000) NOT NULL
        CONSTRAINT t_somedata_df
        DEFAULT REPLICATE('A', 1000)
    , INDEX t_003 (k, s)
);

INSERT INTO dbo.t (s, k)
SELECT sc1.name, sc2.name
FROM sys.syscolumns sc1
    CROSS JOIN sys.syscolumns sc2;

CREATE STATISTICS t_st001 ON dbo.t (k) WITH FULLSCAN;
CREATE STATISTICS t_st002 ON dbo.t (s) WITH FULLSCAN;

A consulta a seguir usa propositalmente os tipos de variável errados. Eu esperava que o plano de consulta incluísse um aviso de conversão implícito, mas isso não acontece.

DECLARE @k char(128) = 'a';
DECLARE @s char(128) = '';
SELECT s 
FROM dbo.t 
    LEFT JOIN sys.syscolumns sc ON t.s = sc.name
WHERE dbo.t.s = @s
    OR dbo.t.k = @k;

Por que é que?

O plano de consulta está aqui .

^{1 - esse é o meu site, BTW}

Recentemente, atualizei meu SQL Server 2017 Developer Edition no RedHat Enterprise Linux 7.6 para SQL Server 2019 CTP 3.0.

O serviço mssql-server não será mais iniciado. /var/opt/mssql/log/errorlog mostra o seguinte:

2019-06-12 09:36:31.98 Servidor Microsoft SQL Server 2019 (CTP3.0) - 15.0.1600.8 (X64)
17 de maio de 2019 00:56:19
Copyright (C) 2019 Microsoft Corporation
Developer Edition (64 bits) em Linux (Red Hat Enterprise Linux)
2019-06-12 09:36:32.04 Ajuste do servidor UTC: -5:00
2019-06-12 09:36:32.05 Servidor (c) Microsoft Corporation.
2019-06-12 09:36:32.07 Servidor Todos os direitos reservados.
2019-06-12 09:36:32.08 Servidor O ID do processo do servidor é 32.
2019-06-12 09:36:32.09 Servidor Logging de mensagens do SQL Server no arquivo '/var/opt/mssql/log/errorlog'.
2019-06-12 09:36:32.10 Parâmetros de inicialização do Registro do Servidor:
-d /var/opt/mssql/data/master.mdf
-l /var/opt/mssql/data/mastlog.ldf
-e /var/opt/mssql/log/errorlog
2019-06-12 09:36:32.15 Parâmetros de inicialização da linha de comando do servidor:
--accept-eula
2019-06 -12 09:36:32.18 Servidor SQL Server detectou 1 soquete com 4 núcleos por soquete e 4 processadores lógicos por soquete, 4 processadores lógicos no total; usando 4 processadores lógicos baseados no licenciamento do SQL Server. Esta é uma mensagem informativa; Não é necessária nenhuma ação do usuário.
2019-06-12 09:36:32.20 Servidor SQL Server está iniciando na base de prioridade normal (=7). Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do usuário.
2019-06-12 09:36:32.23 Servidor detectado 7856 MB de RAM. Esta é uma mensagem informativa; Não é necessária nenhuma ação do usuário.
2019-06-12 09:36:32.24 Servidor Usando memória convencional no gerenciador de memória.
2019-06-12 09:36:32.28 A extensão do pool de buffers do servidor não é compatível com a plataforma Linux.
2019-06-12 09:36:32.29 Erro do servidor: 17128, Gravidade: 16, Estado: 1.
2019-06-12 09:36:32.29 Server initdata: Sem memória para buffers de kernel.

/var/opt/mssql/mssql.conf conteúdo:

[sqlagent]
habilitado = false

systemctl status mssql-servermostra:

mssql-server.service - Mecanismo de banco de dados do Microsoft SQL Server
Carregado: carregado (/usr/lib/systemd/system/mssql-server.service; habilitado; predefinição do fornecedor: desabilitado)
Ativo: falhou (Resultado: start-limit) desde segunda-feira de 2019 -06-17 13:57:45 CDT; 26min atrás
Documentos: https://learn.microsoft.com/en-us/sql/linux
Processo: 71357 ExecStart=/opt/mssql/bin/sqlservr (code=exited, status=1/FAILURE)
PID principal: 71357 ( code=exited, status=1/FAILURE)
Tarefas: 0
CGroup: /system.slice/mssql-server.service

17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: mssql-server.service: main process exited, code=exited, status=1/FAILURE
Jun 17 13:57:45 rhel72-sqlserver.localdomain systemd[ 1]: A unidade mssql-server.service entrou no estado de falha.
17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: mssql-server.service falhou.
Jun 17 13:57:45 rhel72-sqlserver.localdomain systemd[1]: mssql-server.service holdoff time over, agendamento de reinício.
17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: Mecanismo de banco de dados do Microsoft SQL Server interrompido.
17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: iniciar solicitação repetida muito rapidamente para mssql-server.service
17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: Falha ao iniciar o Mecanismo de Banco de Dados do Microsoft SQL Server.
17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: A unidade mssql-server.service entrou no estado de falha.
17 de junho 13:57:45 rhel72-sqlserver.localdomain systemd[1]: mssql-server.service falhou.

Eu tentei yum remove mssql-server, seguido por yum install mssql-server, mas nenhuma mudança.

Alguma ideia?

A tentativa de executar o mssql-conf setupexecutável, como root, resulta no seguinte:

[root@rhel72-sqlserver bin]# sudo ./mssql-conf setup
usermod: sem alterações
Escolha uma edição do SQL Server:
1) Avaliação (gratuita, sem direitos de uso de produção, limite de 180 dias)
2) Desenvolvedor (gratuito, não direitos de uso de produção)
3) Express (gratuito)
4) Web (PAID)
5) Standard (PAID)
6) Enterprise (PAID) - utilização de núcleo de CPU restrita a 20 físicos/40 hyperthreaded
7) Enterprise Core (PAID) - utilização de núcleo de CPU até Sistema Operacional Máximo
8) Comprei uma licença por meio de um canal de vendas no varejo e tenho uma chave de produto para inserir.

Detalhes sobre as edições podem ser encontrados em
https://go.microsoft.com/fwlink/?LinkId=852748&clcid=0x409

O uso de edições PAGAS deste software requer licenciamento separado por meio de um
programa de licenciamento por volume da Microsoft.
Ao escolher uma edição PAGA, você está verificando se possui o
número apropriado de licenças para instalar e executar este software.

Digite sua edição(1-8): 2
Os termos de licença para este produto podem ser encontrados em
/usr/share/doc/mssql-server ou baixados em:
https://go.microsoft.com/fwlink/?LinkId=855862&clcid =0x409

A declaração de privacidade pode ser visualizada em:
https://go.microsoft.com/fwlink/?LinkId=853010&clcid=0x409

Digite a senha do administrador do sistema SQL Server:
Confirme a senha do administrador do sistema SQL Server:
Configurando o SQL Server...

Esta é uma versão de avaliação. Faltam [153] dias no período de avaliação.
Este programa encontrou um erro fatal e não pode continuar em execução em Mon Jun 17 14:35:43 2019
As seguintes informações de diagnóstico estão disponíveis:

  Reason: 0x00000007  
  Status: 0xc0000218  
 Message: Cannot open or read the persistent registry: \SystemRoot\security.hiv.  

Stack Trace:
000000006bd347d0
000000006bd31af7
000000006bd31d3a
000000006bd30ea5
000000006bd2faf7
000000006bd73371
Process: 75209 - sqlservr
Thread: 75213 (application thread 0x4)
Instance Id: ffcf27f9-18a5-485a-8a9d-34482c5efe06
Crash Id: cb1238f4-2504-457c-bbb3-d7ecad750aec
Build stamp: fbef7d3acfbedcf62a42c8909366dbba3852b92cabb497c2169680835fd60276
Distribuição: Processadores Red Hat Enterprise Linux
: 4
Memória total: 16637898752 bytes
Timestamp: Mon Jun 17 14:35:43 2019

Red Hat Enterprise Linux
Capturando core dump e informações para /var/opt/mssql/log...
Dica: Você não está vendo mensagens de outros usuários e do sistema.
Os usuários do grupo 'systemd-journal' podem ver todas as mensagens. Passe -q para
desativar este aviso.
Nenhum arquivo de diário foi aberto devido a permissões insuficientes.
Dica: No momento, você não está vendo mensagens de outros usuários e do sistema.
Os usuários do grupo 'systemd-journal' podem ver todas as mensagens. Passe -q para
desativar este aviso.
Nenhum arquivo de diário foi aberto devido a permissões insuficientes.
/usr/bin/tail: não é possível abrir '/var/log/messages' para leitura: Permissão negada
Tentando capturar um dump com paldumper
Capturado um dump com paldumper
/usr/bin/find: '/usr/share/polkit-1/rules.d': Permissão negada
/usr/bin/find: '/usr/libexec/initscripts /legacy-actions/auditd': Permissão negada
Core dump e informações estão sendo compactadas em segundo plano. Quando
concluídos, eles podem ser encontrados no seguinte local:
/var/opt/mssql/log/core.sqlservr.06_17_2019_14_35_43.75209.tbz2 Falha na
configuração inicial do Microsoft SQL Server. Consulte o ERRORLOG
em /var/opt/mssql/log para obter mais informações.
[root@rhel72-sqlserver bin]#

Estou logado no servidor como root, então não entendo por que estou vendo erros de "acesso negado".

Faça a seguinte reprodução:

USE tempdb;

IF OBJECT_ID(N'dbo.t', N'U') IS NOT NULL
DROP TABLE dbo.t
GO
CREATE TABLE dbo.t
(
    id int NOT NULL 
        PRIMARY KEY 
        NONCLUSTERED 
        IDENTITY(1,1)
    , col1 datetime NOT NULL
    , col2 varchar(800) NOT NULL
    , col3 tinyint NULL
    , col4 sysname NULL
);

INSERT INTO dbo.t (
      col1
    , col2
    , col3
    , col4
    ) 
SELECT TOP(100000) 
      CONVERT(datetime, 
         DATEADD(DAY, CONVERT(int, CRYPT_GEN_RANDOM(1)), '2000-01-01 00:00:00'))
    , replicate('A', 800)
    , sc2.bitpos
    , CONVERT(sysname, CHAR(65 + CRYPT_GEN_RANDOM(1) % 26) 
        + CHAR(65 + CRYPT_GEN_RANDOM(1) % 26) 
        + CHAR(65 + CRYPT_GEN_RANDOM(1) % 26))
FROM sys.syscolumns sc
    CROSS JOIN sys.syscolumns sc2;

Aqui estou adicionando um índice clusterizado em um conjunto de colunas que não são exclusivas e um índice típico não clusterizado de coluna única:

CREATE CLUSTERED INDEX t_cx 
ON dbo.t (col1, col2, col3);

CREATE INDEX t_c1 ON dbo.t(col4); 

Essa consulta força o SQL Server a fazer uma pesquisa no índice clusterizado. Por favor, perdoe o uso da dica de índice, foi a maneira mais rápida de obter a reprodução:

SELECT id
    , col1
    , col2
    , col3
FROM dbo.t aad WITH (INDEX = t_c1)
WHERE col4 = N'JSB'
    AND col1 > N'2019-05-30 00:00:00';

O plano de consulta real mostra uma coluna inexistente na Lista de saída para a verificação de índice não clusterizado:

Aparentemente, isso representa o unificador usado no índice clusterizado não exclusivo. É esse o caso? Uma coluna com esse nome é sempre o unificador de índice clusterizado?

Considere o seguinte MCVE simples:

SET STATISTICS IO, TIME OFF;
USE tempdb;

IF OBJECT_ID(N'tempdb..#t1', N'U') IS NOT NULL DROP TABLE #t1;
CREATE TABLE #t1
(
    r int NOT NULL
);

IF OBJECT_ID(N'tempdb..##t1', N'U') IS NOT NULL DROP TABLE ##t1;
CREATE TABLE ##t1
(
    r int NOT NULL
);

IF OBJECT_ID(N'dbo.s1', N'U') IS NOT NULL DROP TABLE dbo.s1;
CREATE TABLE dbo.s1 
(
    r int NOT NULL
        PRIMARY KEY CLUSTERED
);

INSERT INTO dbo.s1 (r)
SELECT TOP(10000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM sys.syscolumns sc1
    CROSS JOIN sys.syscolumns sc2;
GO

Quando executo as seguintes inserções, inserir em #t1não mostra nenhuma E/S de estatísticas para a tabela temporária. No entanto, inserir em ##t1 mostra E/S de estatísticas para a tabela temporária.

SET STATISTICS IO, TIME ON;
GO

INSERT INTO #t1 (r)
SELECT r
FROM dbo.s1;

A saída das estatísticas:

SQL Server analisa e compila o tempo:
   Tempo de CPU = 0 ms, tempo decorrido = 1 ms.
Tabela 's1'. Contagem de varredura 1, leituras lógicas 19, leituras físicas 0, leituras antecipadas 0, leituras lógicas lob 0, leituras físicas lob 0, leituras antecipadas lob 0.

 Tempos de execução do SQL Server:
   Tempo de CPU = 16 ms, tempo decorrido = 9 ms.

(10.000 linhas afetadas)

INSERT INTO ##t1 (r)
SELECT r
FROM dbo.s1;

SQL Server analisa e compila o tempo:
   Tempo de CPU = 0 ms, tempo decorrido = 1 ms.
Tabela '##t1'. Contagem de varredura 0, leituras lógicas 10016, leituras físicas 0, leituras antecipadas 0, leituras lógicas lob 0, leituras físicas lob 0, leituras antecipadas lob 0.
Tabela 's1'. Contagem de varredura 1, leituras lógicas 19, leituras físicas 0, leituras antecipadas 0, leituras lógicas lob 0, leituras físicas lob 0, leituras antecipadas lob 0.

 Tempos de execução do SQL Server:
   Tempo de CPU = 47 ms, tempo decorrido = 45 ms.

(10.000 linhas afetadas)

Por que há tantas leituras na tabela ##temp quando estou apenas inserindo nela?

Usando a conectividade SqlClient do Microsoft.Net v4.0 integrada ao Microsoft.Net por meio do System.Data.SqlClientassembly, uma máquina específica não pode se conectar a um conjunto específico de servidores. Quando as conexões são tentadas, o seguinte erro é gerado:

System.Data.SqlClient.SqlException (0x80131904): Uma conexão foi estabelecida com sucesso com o servidor, mas ocorreu um erro durante o processo de login. (provedor: Provedor SSL, erro: 0 - Uma conexão existente foi fechada à força pelo host remoto.) ---> System.ComponentModel.Win32Exception (0x80004005): Uma conexão existente foi fechada à força pelo host remoto
   em System.Data.SqlClient.SqlInternalConnection.OnError(exceção SqlException, booleano breakConnection, Action`1 wrapCloseInAction)
   em System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
   em System.Data.SqlClient.TdsParserStateObject.SNIWritePacket(SNIHandle handle, SNIPacket packet, UInt32& sniError, Boolean canAccumulate, Boolean callerHasConnectionLock)
   em System.Data.SqlClient.TdsParserStateObject.WriteSni(Boolean canAccumulate)
   em System.Data.SqlClient.TdsParserStateObject.WritePacket(Byte flushMode, Boolean canAccumulate)
   em System.Data.SqlClient.TdsParser.TdsLogin(SqlLogin rec)
   em System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, Boolean withFailover)
   em System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover(ServerInfo serverInfo, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString connectionOptions, SqlCredential credential, TimeoutTimer timeout)
   em System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(TimeoutTimer timeout, SqlConnectionString connectionOptions, SqlCredential credential, String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance)
   em System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, SqlCredential credential, Object providerInfo,String newPassword, SecureString newSecurePassword, Boolean redirectedUserInstance, SqlConnectionString userConnectionOptions)
   em System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
   em System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)
   em System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 nova tentativa, DbConnectionOptions userOptions, DbConnectionInternal& connection)
   em System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 nova tentativa, DbConnectionOptions userOptions)
   em System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 nova tentativa)
   em System.Data.SqlClient.SqlConnection.Open()
   em ConsoleApplication1.Module1.Main()

Posso me conectar de outras máquinas ao mesmo servidor de destino usando o mesmo binário sem problemas. Também posso me conectar a partir do servidor problemático se recompilar o binário no Microsoft.Net v2.0.

O servidor de destino está configurado para auditar logins com falha, no entanto, nenhuma falha é registrada no log de erros do SQL Server como resultado desse problema - posso causar uma entrada de auditoria se fizer login com um login inválido do SQL Server apenas para ter certeza de que a auditoria está funcionando .

O código que estou usando para testar esse problema é:

Module Module1

    Sub Main()

        Dim bUseSSL As Boolean = False

        If My.Application.CommandLineArgs.Contains("/SSL") Then
            bUseSSL = True
        End If

        If bUseSSL Then
            Console.WriteLine("Encryption enabled")
        Else
            Console.WriteLine("Encryption disabled")
        End If

        Dim cb As New Data.SqlClient.SqlConnectionStringBuilder
        cb.ApplicationName = "SqlClientTest"
        cb.DataSource = "<server_name_here>"
        cb.IntegratedSecurity = True
        cb.Encrypt = bUseSSL
        'cb.TrustServerCertificate = True
        cb.NetworkLibrary = "dbmssocn"

        Try
            Using sqlconnection As New System.Data.SqlClient.SqlConnection(cb.ConnectionString)
                Try
                    sqlconnection.Open()
                    Console.WriteLine("Connected to " & cb.DataSource)
                    Dim sqlcommand As New System.Data.SqlClient.SqlCommand("SELECT @@SERVERNAME;", sqlconnection)
                    Dim sqlreader As System.Data.SqlClient.SqlDataReader = sqlcommand.ExecuteReader
                    While sqlreader.Read
                        Console.WriteLine(sqlreader.GetString(0))
                    End While
                    sqlreader.Close()
                Catch ex As Exception
                    Console.WriteLine(cb.ConnectionString)
                    Console.WriteLine("")
                    Console.WriteLine(ex.ToString)
                End Try
                Console.WriteLine("Press 'q' to quit.")
                Dim cki As ConsoleKeyInfo = Console.ReadKey
                While cki.KeyChar.ToString.ToLower <> "q"
                    cki = Console.ReadKey
                End While
            End Using
        Catch ex As Exception
            Console.WriteLine(cb.ConnectionString)
            Console.WriteLine("")
            Console.WriteLine(ex.ToString)
        End Try
    End Sub

End Module

A mesma falha é registrada independentemente da configuração de criptografia e independentemente da TrustServerCertificateconfiguração.

Algo parece estar forçando o .Net SqlClient v4.0 nesta máquina a usar SSL mesmo se eu desativá-lo através da string de conexão.

Alguma ideia do que verificar?

Estou tentando obter uma lista de páginas para uma tabela que possui linhas com ROW_OVERFLOW_DATA. Eu posso obter a lista de páginas alocadas do DMV não documentado sys.db_db_database_page_allocations, no entanto, parece não haver páginas ROW_OVERFLOW_DATA listadas na saída desse DMV. Existe algum outro DMV que eu simplesmente não consigo localizar?

Exemplo mínimo, completo e (espero!) verificável:

USE tempdb;

IF OBJECT_ID(N'dbo.t', N'U') IS NOT NULL
DROP TABLE dbo.t;
GO

CREATE TABLE dbo.t
(
    rownum int NOT NULL IDENTITY(1,1)
        PRIMARY KEY CLUSTERED
    , on_row_data varchar(30) NOT NULL
        DEFAULT ('on_row_data')
    , off_row_data varchar(MAX) NOT NULL
        DEFAULT REPLICATE('A', 20000) --PLENTY BIG ENOUGH!
) WITH (DATA_COMPRESSION = NONE); --not compressing those pages!

INSERT INTO dbo.t DEFAULT VALUES;

DECLARE @ObjectID int = (SELECT o.object_id FROM sys.objects o WHERE o.name = 't');
DECLARE @PageID int;
DECLARE @PageTypeDesc varchar(100);

SELECT FileID = dpa.allocated_page_file_id
    , PageID = dpa.allocated_page_page_id
    , PageTypeDesc = dpa.page_type_desc
FROM sys.dm_db_database_page_allocations(DB_ID(), @ObjectID, NULL, NULL, 'DETAILED') dpa

A saída se parece com:

╔════════╦════════╦══════════════╗
║ FileID ║ PageID ║ PageTypeDesc ║
╠════════╬════════╬══════════════╣
║ 1 ║ 1598 ║ IAM_PAGE ║
║ 3 ║ 105368 ║ DATA_PAGE ║
║ 3 ║ 105369 ║ NULL ║
║ 3 ║ 105370 ║ NULL ║
║ 3 ║ 105371 ║ NULL ║
║ 3 ║ 105372 ║ NULL ║
║ 3 ║ 105373 ║ NULL ║
║ 3 ║ 105374 ║ NULL ║
║ 3 ║ 105375 ║ NULL ║
╚════════╩════════╩══════════════╝

O que faz sentido, além da página ROW_OVERFLOW_DATA ausente. Temos uma única página de mapa de alocação de índice e uma extensão total de páginas de dados de 8 KB, com apenas uma dessas páginas realmente alocada.

Da mesma forma, se eu usar a sys.fn_PhysLocCrackerfunção não documentada para mostrar a página onde cada linha existe, como em:

SELECT *
FROM dbo.t
CROSS APPLY sys.fn_PhysLocCracker(%%PHYSLOC%%)

Só vejo os DATA_PAGElistados:

╔════════╦═════════════╦═════════════════════╦════ ═════╦═════════╦═════════╗
║ rownum ║ on_row_data ║ off_row_data ║ file_id ║ page_id ║ slot_id ║
╠════════╬═════════════╬═════════════════════╬════ ═════╬═════════╬═════════╣
║ 1 ║ on_row_data ║ AAAAAAAAAAAAAAAAAAA ║ 3 ║ 105368 ║ 0 ║
╚════════╩═════════════╩═════════════════════╩════ ═════╩═════════╩═════════╝

Da mesma forma, se eu usar DBCC IND(database, table, index)só vejo as duas páginas listadas:

DBCC IND (tempdb, t, 1);

Resultado:

╔═════════╦═════════╦════════╦════════╦═══════════ ═╦═════════╦═════════════════╦════════════════════ ═╦════════════════╦══════════╦════════════╦═══════ ══════╦═════════════╦═════════════╦═════════════╦═ ═╗
║ PageFID ║ PagePID ║ IAMFID ║ IAMPID ║ ObjectID ║ IndexID ║ PartitionNumber ║ PartitionID ║ iam_chain_type ║ PageType ║ IndexLevel ║ NextPageFID ║ NextPagePID ║ PrevPageFID ║ PrevPagePID ║ ║
╠═════════╬═════════╬════════╬════════╬═══════════ ═╬═════════╬═════════════════╬════════════════════ ═╬════════════════╬══════════╬════════════╬═══════ ══════╬═════════════╬═════════════╬═════════════╬═ ═╣
║ 1 ║ 1598 ║ NULL ║ NULL ║ 2069582411 ║ 1 ║ 1 ║ 6989586877272752128 ║ Dados em linha ║ 10 ║ NULL ║ 0 ║ 0 ║ 0 ║ 0 ║ ║ 0 ║ 0 ║ 0 ║
║ 3 ║ 105368 ║ 1 ║ 1598 ║ 2069582411 ║ 1 ║ 1 ║ 6989586877272752128 ║ Dados em linha ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ ║ 0 ║ 0 ║ 0 ║ 0 ║
╚═════════╩═════════╩════════╩════════╩═══════════ ═╩═════════╩═════════════════╩════════════════════ ═╩════════════════╩══════════╩════════════╩═══════ ══════╩═════════════╩═════════════╩═════════════╩═ ═╝

Se eu olhar para o conteúdo real da página, usando DBCC PAGE, parece que ainda não vejo nada sobre qual página contém o ROW_OVERFLOW_DATA - tenho certeza que deve estar lá, provavelmente não sei o que olhar:

DBCC PAGE (tempdb, 3, 105368 , 3) WITH TABLERESULTS;

Os resultados são grandes demais para caber aqui, se eu incluir as linhas de despejo de memória, mas esta é a saída do cabeçalho:

╔══════════════╦════════════════════════════════╦═ ══════════════════════════════╦═══════════════════ ════════════╗
║ ParentObject ║ Object ║ Field ║ VALUE ║
╠══════════════╬════════════════════════════════╬═ ══════════════════════════════╬═══════════════════ ════════════╣
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bpage ║ 0x000002431A8A2000 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bhash ║ 0x0000000000000000 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bpageno ║ (3:105368) ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bdbid ║ 2 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ referências ║ 0 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bcputicks ║ 0 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bsampleCount ║ 0 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bUse1 ║ 63172 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bstat ║ 0x10b ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ blog ║ 0x212121cc ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║bnext ║ 0x0000000000000000 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bDirtyContext ║ 0x000002435DA77160 ║
║ BUFFER: ║ BUF @0x000002437E86D5C0 ║ bstat2 ║ 0x0 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ m_pageId ║ (3:105368) ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ m_headerVersion ║ 1 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_type ║ 1 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ m_typeFlagBits ║ 0x0 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_level ║ 0 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_flagBits ║ 0xc000 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_objId (AllocUnitId.idObj) ║ 3920762 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_indexId (AllocUnitId.idInd) ║ 512 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ Metadados: AllocUnitId ║ 144115445026914304 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ Metadados: PartitionId ║ 6989586877272752128 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ Metadados: IndexId ║ 1 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ Metadados: ObjectId ║ 2069582411 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ m_prevPage ║ (0:0) ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_nextPage ║ (0:0) ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ pminlen ║ 8 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_slotCnt ║ 1 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_freeCnt ║ 66 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_freeData ║ 8124 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_reservedCnt ║ 0 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_lsn ║ (36:47578:1) ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_xactReserved ║ 0 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_xdesId ║ (0:0) ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_ghostRecCnt ║ 0 ║
║ CABEÇALHO DA PÁGINA: ║ Página @0x000002431A8A2000 ║ m_tornBits ║ 0 ║
║ PAGE HEADER: ║ Página @0x000002431A8A2000 ║ DB Frag ID ║ 1 ║
║ CABEÇALHO DA PÁGINA: ║ Status de alocação ║ GAM (3:2) ║ ALOCADA ║
║ CABEÇALHO DA PÁGINA: ║ Status de alocação ║ SGAM (3:3) ║ NÃO ALOCADO ║
║ PAGE HEADER: ║ Status de alocação ║ PFS (3:105144) ║ 0x40 ALLOCATED 0_PCT_FULL ║
║ CABEÇALHO DA PÁGINA: ║ Status de alocação ║ DIFF (3:6) ║ NÃO ALTERADO ║
║ CABEÇALHO DA PÁGINA: ║ Status de Alocação ║ ML (3:7) ║ NÃO MIN_LOGGED ║
║ PAGE HEADER: ║ Slot 0 Offset 0x60 Comprimento 8028 ║ Tipo de Registro ║ PRIMARY_RECORD ║
║ PAGE HEADER: ║ Slot 0 Offset 0x60 Comprimento 8028 ║ Atributos de Gravação ║ NULL_BITMAP VARIABLE_COLUMNS ║
║ CABEÇALHO DA PÁGINA: ║ Slot 0 Offset 0x60 Comprimento 8028 ║ Tamanho do Registro ║ 8028 ║
╚══════════════╩════════════════════════════════╩═ ══════════════════════════════╩═══════════════════ ════════════╝

Considere o seguinte código:

DECLARE @db sysname;
DECLARE @filename varchar(260);
DECLARE cur CURSOR LOCAL FORWARD_ONLY STATIC READ_ONLY
FOR
SELECT d.name
FROM sys.databases d;
OPEN cur;
FETCH NEXT FROM cur INTO @db
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @filename = 'C:\temp\create_database_' + @db + '.txt';
    :setvar c @filename
    :out $(c)
    PRINT $(c);
    FETCH NEXT FROM cur INTO @db
END
CLOSE cur;
DEALLOCATE cur;

Estou esperando obter vários arquivos criados em C:\temp, um para cada banco de dados, mas nada é criado e nenhum erro é relatado pelo SQL Server.

Eu tentei executar isso no SSMS usando o modo SQLCMD e também tentei executá-lo no sqlcmd.exe