GAURAV RATHOD's questions

Informações ambientais:

• Postgres 14.7 em RDS

Estou tentando aplicar alterações no banco de dados por meio do liquibase e, para minha surpresa, estou recebendo o seguinte erro. A função mencionada no erro (xxxxx) não existe no banco de dados. Nem a sequência que está tentando alterar.

O que não consigo descobrir é de onde o mecanismo de banco de dados está obtendo essas informações. Executar a mesma instrução de inserção simples diretamente no postgres também produz o mesmo erro. Esta é uma instância nova e deve ser o primeiro registro na tabela.

[ERROR] Failed to execute goal org.liquibase:liquibase-maven-plugin:4.3.5:update (default-cli) on project liquibasedatabase:
[ERROR] Error setting up or running Liquibase:
[ERROR] liquibase.exception.MigrationFailedException: Migration failed for change set src/main/dbschema/changesets/common/master-data/changes.xml::change-id::owner:
[ERROR]      Reason: liquibase.exception.DatabaseException: ERROR: role "xxxxx" does not exist
[ERROR]   Where: SQL statement "ALTER SEQUENCE IF EXISTS NON_EXISTING_SEQ OWNER TO XXXXX"
[ERROR] PL/pgSQL function create_sequence() line 21 at EXECUTE [Failed SQL: (0) INSERT INTO table (id,name,serial_number) VALUES (7,'something','something')]

Detalhes do ambiente: SQL Server 2019 (CU 19) – 96 processadores lógicos, 1,5 TB de RAM Hospedando 1 banco de dados de 3 TB

Distribuí a configuração do grupo de disponibilidade (assíncrono) que se estende por dois datacenters. Ambos os lados (AGs primários e encaminhadores) são clusters de 2 nós com réplica de sincronização.

Tudo funciona perfeitamente o dia todo, mas às vezes vejo um enorme log_send_queue_size (até 7 GB). Ele desaparece em alguns minutos a um bom ritmo, então não suspeito que a largura de banda seja um gargalo aqui.

O que estou tentando descobrir é o que está gerando tanto log. E o que devo usar para rastreá-lo (eventos estendidos podem ser?). Qualquer ajuda seria apreciada.

Eu tenho valores JSON como seguir em uma coluna. Eu tentei analisá-lo usando OPENJSON.

DECLARE @json NVARCHAR(MAX)='[[108,290,1388,2056],[108,290,1388,2057]]'
DECLARE @json2 NVARCHAR(MAX)='{"1":29893,"2":1}'

DROP TABLE IF EXISTS #T1
SELECT @json AS [json] INTO #t1
INSERT INTO #t1 ([json]) SELECT @json2

SELECT * FROM #T1
CROSS APPLY OPENJSON([json]) 
WHERE ISJSON([json]) > 0

@json2 é retornado conforme o esperado, pois possui um par chave-valor. Mas @json precisa de outro nível de análise, já que não possui um nome de chave, não consegui analisá-lo usando JSON_VALUE.

Fazer CROSS APPLY novamente está resultando em erro para @json2, pois não estaria em par agora ( para o valor 29893 ).

SELECT * FROM #T1
CROSS APPLY OPENJSON(JSON) A
CROSS APPLY OPENJSON(value) B
WHERE ISJSON([JSON]) > 0

Msg 13609, Level 16, State 4, Line 66
JSON text is not properly formatted. Unexpected character '2' is found at position 0.

Existe uma maneira mais simples de fazer isso para objetos JSON sem nomes de chave onde não preciso aplicar duas lógicas separadas para formatos diferentes?

Recentemente, descobrimos em nosso cluster AlwaysOn que um nó estava usando uma NIC como reserva em uma equipe de duas NICs. Enquanto em outro nó, ele estava usando ambos os NICs ativamente. Primeiro, mudamos para ativo da mesma forma que o outro nó.

Minha pergunta é: precisamos reiniciar os serviços SQL ou o próprio servidor para que essas alterações entrem em vigor na perspectiva do SQL (como na sincronização do AG)?

Estou observando um log_send_rate baixo em minha configuração de AG distribuído. Eu entendo que o AG usa o fluxo de log e, portanto, suponho que não deve ter nada a ver com dados, mas queria saber se isso tem algo a ver com os dados que ele está transmitindo também e não apenas com os recursos do sistema operacional (rede, E/S)?

Métricas básicas para consideração:

• SQL Server 2019-CU16
• RAM de origem 1,5 TB, 48 CPU <> RAM de destino 128 GB, 48 CPU - A diferença na memória desempenha algum papel aqui?
• Ambos os servidores estão no mesmo DC, a latência do ping é <1ms. O servidor de destino é VM.
• O teste ROBOCOPY mostra uma taxa de transferência de arquivos de ~100 MB/s
• Quando atividades de geração de log de transações altas (como manutenção ou criação de índice) são enviadas para outra réplica - ele é transferido com uma taxa máxima de 20 MB/s (o que não é esperado). É quando o log_send_queue se acumula.
• A taxa de REDO do outro lado é boa, nenhuma fila de REDO se acumulando lá.

No AG de origem, não vejo nada para o contador 'Bytes Enviados para Transporte/Sec', então não posso determinar se isso é um gargalo ou não.

Por favor, sugira se eu perdi alguma coisa que eu deveria ter incluído.

Eu tive uma observação interessante sobre as permissões de segurança do SQL Server.

Minha configuração é como abaixo. Estou tentando restringir o usuário de atualizar tabelas em esquema específico.

A declaração do problema é Por que o usuário tem permissão para fazer inserções na tabela por meio da exibição (de esquema diferente), mesmo que a inserção seja explicitamente negada no esquema da tabela na definição da exibição?

USE master
GO

CREATE LOGIN Login1
    WITH password = 'Admin@123'
GO

CREATE DATABASE TestDB
GO

USE TestDB
GO

CREATE user Login1
FROM LOGIN Login1
GO

CREATE SCHEMA sch1
GO

CREATE SCHEMA V
GO

CREATE TABLE sch1.table1 (
    id INT
    ,name VARCHAR(5)
    )
GO

CREATE VIEW v.view1
AS
SELECT *
FROM sch1.table1
GO

CREATE VIEW sch1.view2
AS
SELECT *
FROM sch1.table1
GO

--User can update all tables
ALTER ROLE [db_datawriter] ADD MEMBER [Login1] 
GO

--Except tables under this schema
DENY INSERT
    ON SCHEMA::[sch1]
    TO [Login1]
GO



--Open session with Login1
USE TestDB
GO

--Should not work, does not work.
INSERT sch1.table1
SELECT 1, 'A'
--The INSERT permission was denied on the object 'table1', database 'TestDB', schema 'sch1'.


--Should not work, does not work.
INSERT sch1.view2
SELECT 1, 'A'
--The INSERT permission was denied on the object 'view2', database 'TestDB', schema 'sch1'.


-- Works! - even though write is denied on underlying table?
INSERT v.view1
SELECT 1, 'A'
--(1 row affected)

Estou propagando um banco de dados usando o grupo de disponibilidade distribuído. A propagação é automática, mas o modo de sincronização é assíncrono. A compactação do fluxo de log para propagação automática NÃO é habilitada via TF 9567. O valor para 'is_compression_enabled' no DMV 'sys.dm_hadr_physical_seeding_stats' está mostrando 0 durante a operação de propagação.

De acordo com a documentação do MS, a compactação do fluxo de log é habilitada por padrão para réplicas assíncronas. ' De acordo com isso, a compactação do fluxo de log não deve ser habilitada por padrão para esta operação de propagação? É por isso que recebi essa pergunta se esse é o mesmo comportamento para grupos de disponibilidade distribuídos também.