All perguntas(dba)

Tenho um monte de propriedades (colunas no banco de dados) que devem ter um valor de string de uma lista de valores predefinidos, por exemplo active, inactive, pending.

Fora do banco de dados, que é javascript (deno+react no front-end), eu realmente quero tê-los como enumerações de strings, e não como inteiros, porque isso adiciona alguma clareza ao código e, na verdade, reduz a quantidade de código que você precisa escrever.

No banco de dados, tenho duas opções: armazená-los como estão (strings) ou smallintconvertê-los de/para strings durante a seleção/inserção no banco de dados.

O problema com a segunda opção é que ela requer uma transformação adicional no código e, ao usar o TypeScript, essa transformação não é tão direta quanto fazer um mapeamento simples, porque o ts não permite que você reatribua tipos diferentes a propriedades existentes, então você precisa copiar e fazer mais coisas...

De qualquer forma, eu só queria perguntar, quanto é o desempenho do postgres e/ou sobrecarga de tamanho se eu armazená-los diretamente como strings no banco de dados também, para eliminar a etapa de transformação? Imagino que cada registro cresceria em cerca de 20 bytes se eu mudasse de smallintpara texte isso teria algum tipo de efeito no desempenho? Além disso, essas colunas precisam ser indexadas, e isso adiciona outros 20 bytes para cada registro

Se eu tiver uma chave composta feita de 3 colunas, como

constraint some_index unique (parent_store_id, store_type, store_name),

E também preciso poder fazer consultas de seleção com where store_type = ...ou where store_name = ..., ainda preciso criar índices separados para cada uma dessas colunas? Ou o índice exclusivo acima resolve esses casos?

Todas as tabelas e colunas do meu banco de dados usam o conjunto de caracteres utf8mb4 e a ordenação utf8mb4_unicode_ci. Gostaria de migrar para a ordenação utf8mb4_0900_ai_ci, mas usá-la convert toé inviável em minhas tabelas grandes, a menos que eu use gh-ost ou pt-osc.

Parece-me que isso convert tonão deveria ser necessário, visto que o conjunto de caracteres não muda, mas não consigo encontrar nenhuma documentação que confirme ou negue isso. Preciso usar convert toneste caso ou é alter table ... modify col ... collate ...suficiente?

Dei uma olhada em "Usando CONVERTER EM CONJUNTO DE CARACTERES para alterar apenas a ordenação?", que faz uma pergunta muito semelhante, mas a idade dessa pergunta torna as respostas um tanto obsoletas. Mesmo assim, uma resposta parece sugerir que isso convert toé desnecessário. A outra resposta se aprofunda na conversão de conjuntos de caracteres e no uso de pt-osc, o que eu gostaria de evitar.

Tenho duas consultas diferentes que preciso unir em UNION e, então, agregar cada grupo de tipo de taxa em uma tabela final. Para cada grupo de taxa (Rate_001mo, Rate_003mo, etc.)

SELECT EffectiveDate, 
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_001mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_003mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR006M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_006mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR012M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_012mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR024M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_024mo,
SUM(CASE WHEN RateName = 'FHLBCSOFR036M' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_036mo
FROM dbo.STAGING_FhlbRates WHERE EffectiveDate = '20250131'
group by EffectiveDate

UNION

SELECT EffectiveDate,
    SUM(CASE WHEN RateName = 'USOSFRA' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_001mo,
    SUM(CASE WHEN RateName = 'USOSFRC' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_003mo,
    SUM(CASE WHEN RateName = 'USOSFRF' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_006mo,
    SUM(CASE WHEN RateName = 'USOSFR1' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_012mo,
    SUM(CASE WHEN RateName = 'USOSFR2' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_024mo,
    SUM(CASE WHEN RateName = 'USOSFR3' THEN InterestRate ELSE 0 END) / 100.0 AS Rate_036mo
    FROM dbo.STAGING_SofrOisRates WHERE EffectiveDate = '20250131'
    GROUP BY EffectiveDate

As colunas da tabela de resultados finais devem incluir a Data Efetiva e, em seguida, cada grupo de taxas (Taxa_001mês, Taxa_003mês, etc.)

Tenho um deadlock em 10.6.21-MariaDB-ubu2004. Aqui está meu esquema:

CREATE TABLE INT_CHANNEL_MESSAGE
(
    MESSAGE_ID       CHAR(36)     NOT NULL,
    GROUP_KEY        CHAR(36)     NOT NULL,
    CREATED_DATE     BIGINT       NOT NULL,
    MESSAGE_PRIORITY BIGINT,
    MESSAGE_SEQUENCE BIGINT       NOT NULL AUTO_INCREMENT UNIQUE,
    MESSAGE_BYTES    BLOB,
    REGION           VARCHAR(100) NOT NULL,
    PRIMARY KEY (REGION, GROUP_KEY, CREATED_DATE, MESSAGE_SEQUENCE)
) ENGINE = InnoDB;

CREATE INDEX INT_CHANNEL_MSG_DELETE_IDX ON INT_CHANNEL_MESSAGE (REGION, GROUP_KEY, MESSAGE_ID);

Inicialmente, tenho uma única linha na tabela. Vamos supor que os valores de cada linha sejam únicos, únicos REGIONe GROUP_KEYfixos.

A transação nº 1 insere duas linhas usando INSERTinstruções separadas:

INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)

A primeira inserção é executada, depois a transação trava. O nível de isolamento para a Transação nº 1 é REPEATABLE_READ(embora tenha tentado mudar para READ_COMMITED).

A transação nº 2 inicia imediatamente após a execução da primeira inserção (da transação nº 1) (é acionada pela aplicação). O nível de isolamento é definido como READ_COMMITED. A linha inicial é selecionada para atualização e, em seguida, a transação trava na DELETEchamada:

    SELECT INT_CHANNEL_MESSAGE.MESSAGE_ID, INT_CHANNEL_MESSAGE.MESSAGE_BYTES
    from INT_CHANNEL_MESSAGE
    where INT_CHANNEL_MESSAGE.GROUP_KEY = ? and INT_CHANNEL_MESSAGE.REGION = ?
order by CREATED_DATE, MESSAGE_SEQUENCE LIMIT 1 FOR UPDATE SKIP LOCKED

DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?

SHOW ENGINE INNODB STATUSsaída:

| InnoDB |      | 
=====================================
2025-04-04 16:06:44 0x7fc6241b3700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 21 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 0 srv_active, 0 srv_shutdown, 2376 srv_idle
srv_master_thread log flush and writes: 2376
----------
SEMAPHORES
----------
------------
TRANSACTIONS
------------
Trx id counter 1646
Purge done for trx's n:o < 1646 undo n:o < 0 state: running
History list length 2
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 1643, ACTIVE 31 sec
2 lock struct(s), heap size 1128, 1 row lock(s), undo log entries 1
MariaDB thread id 76, OS thread handle 140489014748928, query id 8535 172.21.0.1 nbs 
---TRANSACTION 1640, ACTIVE 31 sec fetching rows
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 3 row lock(s), undo log entries 1
MariaDB thread id 75, OS thread handle 140488995890944, query id 8537 172.21.0.1 nbs Updating
SET STATEMENT SQL_SELECT_LIMIT=1 FOR DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID='ce0ce618-2430-0b4c-727b-7250e5388f15' and GROUP_KEY='cb18446f-633c-3a46-b5ac-95ab539126d1' and REGION='DEFAULT'
------- TRX HAS BEEN WAITING 31293172 us FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 55 page no 3 n bits 320 index PRIMARY of table `nbs_biometric`.`INT_CHANNEL_MESSAGE` trx id 1640 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 9; compact format; info bits 0
 0: len 7; hex 44454641554c54; asc DEFAULT;;
 1: len 30; hex 63623138343436662d363333632d336134362d623561632d393561623533; asc cb18446f-633c-3a46-b5ac-95ab53; (total 36 bytes);
 2: len 8; hex 80000196018d82b2; asc         ;;
 3: len 8; hex 8000000000000012; asc         ;;
 4: len 6; hex 00000000066b; asc      k;;
 5: len 7; hex bf000001410110; asc     A  ;;
 6: len 30; hex 63623533326436662d343362352d393164352d636561612d623965616434; asc cb532d6f-43b5-91d5-ceaa-b9ead4; (total 36 bytes);
 7: SQL NULL;
 8: len 30; hex aced0005737200346f72672e737072696e676672616d65776f726b2e6d65; asc     sr 4org.springframework.me; (total 1252 bytes);

------------------
---TRANSACTION (0x7fc6388d7180), not started
0 lock struct(s), heap size 1128, 0 row lock(s)
--------
FILE I/O
--------
Pending flushes (fsync) log: 0; buffer pool: 0
166 OS file reads, 332 OS file writes, 594 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 891776
Log flushed up to   891776
Pages flushed up to 42676
Last checkpoint at  42664
0 pending log flushes, 0 pending chkp writes
334 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 167772160
Dictionary memory allocated 931712
Buffer pool size   8112
Free buffers       7349
Database pages     763
Old database pages 261
Modified db pages  621
Percent of dirty pages(LRU & free pages): 7.654
Max dirty pages percent: 90.000
Pending reads 0
Pending writes: LRU 0, flush list 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 152, created 611, written 0
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 763, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 read views open inside InnoDB
Process ID=0, Main thread ID=0, state: sleeping
Number of rows inserted 63, updated 0, deleted 18, read 1182
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
 |

O deadlock não ocorre quando a Transação nº 1 insere uma única linha. Como posso evitar isso?

Estou anexando logs do aplicativo para um contexto mais amplo:

2025-04-04 18:06:13,426 [tx1]: TX START
2025-04-04 18:06:13,426 [tx1]: Executing prepared SQL update
2025-04-04 18:06:13,426 [tx1]: Executing prepared SQL statement [INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)
]
2025-04-04 18:06:13,427 [tx2]: Executing prepared SQL query
2025-04-04 18:06:13,427 [tx2]: Executing prepared SQL statement [   SELECT INT_CHANNEL_MESSAGE.MESSAGE_ID, INT_CHANNEL_MESSAGE.MESSAGE_BYTES
    from INT_CHANNEL_MESSAGE
    where INT_CHANNEL_MESSAGE.GROUP_KEY = ? and INT_CHANNEL_MESSAGE.REGION = ?
order by CREATED_DATE, MESSAGE_SEQUENCE LIMIT 1 FOR UPDATE SKIP LOCKED]
2025-04-04 18:06:13,429 [tx2]: Executing prepared SQL update
2025-04-04 18:06:13,429 [tx2]: Executing prepared SQL statement [DELETE from INT_CHANNEL_MESSAGE where MESSAGE_ID=? and GROUP_KEY=? and REGION=?]
2025-04-04 18:07:03,430  [tx2]: Error: 1205-HY000: Lock wait timeout exceeded; try restarting transaction
2025-04-04 18:07:03,432 [tx2]: Extracted SQL state class 'HY' from value 'HY000'
2025-04-04 18:07:03,434 [tx1]: Executing prepared SQL update
2025-04-04 18:07:03,434 [tx1]: Executing prepared SQL statement [INSERT into INT_CHANNEL_MESSAGE(
    MESSAGE_ID,
    GROUP_KEY,
    REGION,
    CREATED_DATE,
    MESSAGE_PRIORITY,
    MESSAGE_BYTES)
values (?, ?, ?, ?, ?, ?)
]
2025-04-04 18:07:03,435 [tx2]: Resetting isolation level of JDBC Connection [HikariProxyConnection@1449683964 wrapping org.mariadb.jdbc.Connection@5b1420f9] to 4
2025-04-04 18:07:03,436  [tx1]: TX END

Existem dois arquivos de dados brutos q4.csve q3.csv.
Mostrar q4.csv:

cat q4.csv    
nameofissuer,shares
nvr inc,11112
pool corp,598689
jefferies finl group inc,433558
constellation brands inc,5624324
bank amer corp,680233587
occidental pete corp,264178414

Mostrar q3.csv:

cat /tmp/q3.csv
nameofissuer,shares
nvr inc,11112
pool corp,404057
jefferies finl group inc,433558
bank amer corp,797683307
occidental pete corp,255281524
vanguard index fds,43000
spdr s&p 500 etf tr,39400
ulta beauty inc,24203

Entre no psql para preparar a tabela:

create database project;
\c project
create table q4(nameofissuer  text,shares int);
copy q4(nameofissuer,shares)
from '/tmp/q3.csv' delimiter ',' csv header;
create table q3(nameofissuer  text,shares int);
copy q3(nameofissuer,shares)
from '/tmp/q3.csv' delimiter ',' csv header;  

Use junção externa completa:

select           
    q4.nameofissuer as issuer_q4,q4.shares as shares_end,q3.nameofissuer as issuer_q3,q3.shares as shares_start from q4
full outer join q3
on q4.nameofissuer  = q3.nameofissuer;

        issuer_q4         | shares_end |        issuer_q3         | shares_start 
--------------------------+------------+--------------------------+--------------
 bank amer corp           |  680233587 | bank amer corp           |    797683307
 constellation brands inc |    5624324 |                          |             
 jefferies finl group inc |     433558 | jefferies finl group inc |       433558
 nvr inc                  |      11112 | nvr inc                  |        11112
 occidental pete corp     |  264178414 | occidental pete corp     |    255281524
 pool corp                |     598689 | pool corp                |       404057
                          |            | spdr s&p 500 etf tr      |        39400
                          |            | ulta beauty inc          |        24203
                          |            | vanguard index fds       |        43000

Como posso obter a seguinte saída desejada com um comando SQL puro?

     nameofissuer         | shares_end | shares_start |   change   
--------------------------+------------+--------------+------------
 bank amer corp           |  680233587 |    797683307 | -117449720
 constellation brands inc |    5624324 |            0 |    5624324
 jefferies finl group inc |     433558 |       433558 |          0
 nvr inc                  |      11112 |        11112 |          0
 occidental pete corp     |  264178414 |    255281524 |    8896890
 pool corp                |     598689 |       404057 |     194632
 spdr s&p 500 etf tr      |          0 |        39400 |     -39400
 ulta beauty inc          |          0 |        24203 |     -24203
 vanguard index fds       |          0 |        43000 |     -43000

Dado o seguinte banco de dados com duas tabelas tendo relacionamento de chave estrangeira entre elas:

CREATE DATABASE FKLocksTest
GO
ALTER DATABASE FKLocksTest SET READ_COMMITTED_SNAPSHOT OFF

USE FkLocksTest
GO

CREATE TABLE dbo.Department
(
    DeptID INT PRIMARY KEY,
    Deptname NVARCHAR(10)
)
INSERT INTO dbo.Department VALUES (1,'IT'),(2,'HR')


CREATE TABLE dbo.Person
(
    PersonID INT PRIMARY KEY,
    PersonName NVARCHAR(10),
    DepartmentId INT FOREIGN KEY REFERENCES dbo.Department(DeptId)
)
INSERT INTO dbo.Person VALUES (1,'JohnSmith',2) 

Se eu executar algumas atualizações, posso verificar quais bloqueios são tomados com o traceflag 1200. Primeiro, podemos verificar os IDs dos objetos:

SELECT  OBJECT_ID('dbo.Department') AS Department,
        OBJECT_ID('dbo.Person') AS Person

Agora que habilitei o TF1200 e executei algumas atualizações, posso ver os bloqueios realizados na aba de mensagens. Também vou garantir que estou usando a leitura confirmada:

DBCC TRACEON(1200,-1)

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

e executar minha primeira atualização

UPDATE dbo.Person SET PersonName = 'Jim'

O Plano não faz referência ao Departamento e a saída do Traceflag não faz referência ao ID do objeto 581577110, o que faz sentido

A seguir, se eu correr

UPDATE dbo.Person SET DepartmentId = 1 WHERE PersonID = 1

Neste caso, o plano de execução faz referência à tabela de departamentos e a saída do Traceflag mostra os bloqueios realizados em 581577110. Isso também faz sentido, pois o SQL Server precisa verificar se o DepartmentId que estamos definindo existe na tabela Department

Desta vez, se eu atualizar a tabela pai e atualizar a coluna Chave primária

UPDATE dbo.Department SET DeptID = 10 WHERE DeptID = 1

O plano de execução mostra uma referência à tabela Person e consigo ver os bloqueios realizados em 613577224. Isso faz sentido, pois o SQL Server precisará verificar se não há registros Person com o DepartmentID antigo que estamos atualizando. Também recebo um erro, pois há uma Person associada ao DeptId 1.

Finalmente, se eu correr

UPDATE dbo.Department SET Deptname = 'aaa' WHERE DeptID = 1

Posso ver na saída do Traceflag que um bloqueio foi feito na tabela de pessoas (613577224), mas não há nenhuma referência à tabela de pessoas no plano

A saída resumida do TF1200 mostra os bloqueios realizados na tabela Pessoa

    ......

Process 59 acquiring Sch-S lock on OBJECT: 9:613577224:0  (class bit0 ref1) result: OK

......

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

......

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring X lock on OBJECT: 9:613577224:0 [UPDSTATS] (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 releasing lock on OBJECT: 9:613577224:0 [UPDSTATS]

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0

......

Process 59 releasing lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0

Process 59 releasing lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock reference on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0

Process 59 releasing lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0

Process 59 releasing lock reference on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

Process 59 releasing lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 1), lockPartitionId = 0

Process 59 releasing lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 1), lockPartitionId = 0

......

Process 59 releasing lock on OBJECT: 9:613577224:0 

......

Process 59 acquiring IS lock on OBJECT: 9:613577224:0  (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 acquiring Sch-S lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0 (class bit0 ref1) result: OK

Process 59 releasing lock on METADATA: database_id = 9 INDEXSTATS(object_id = 613577224, index_id or stats_id = 2), lockPartitionId = 0

Process 59 releasing lock on METADATA: database_id = 9 STATS(object_id = 613577224, stats_id = 2), lockPartitionId = 0

......

Msg 547, Level 16, State 0, Line 1
The UPDATE statement conflicted with the REFERENCE constraint "FK__Person__Departme__267ABA7A". The conflict occurred in database "FKLocksTest", table "dbo.Person", column 'DepartmentId'.
The statement has been terminated.

O bloqueio na tabela Pessoa possivelmente parece fazer parte do processo de compilação, se eu executar o UPDATE várias vezes, eventualmente obtenho uma lista muito menor de bloqueios (abaixo na íntegra), embora o plano seja um plano trivial

Process 59 acquiring IX lock on OBJECT: 9:581577110:0  (class bit2000000 ref1) result: OK

Process 59 acquiring IX lock on PAGE: 9:1:280  (class bit2000000 ref1) result: OK

Process 59 acquiring X lock on KEY: 9:72057594043170816 (8194443284a0) (class bit2000000 ref1) result: OK

Process 59 releasing lock reference on KEY: 9:72057594043170816 (8194443284a0)

Process 59 releasing lock reference on PAGE: 9:1:280 

Minhas perguntas são: quando atualizamos uma coluna não-chave na tabela Departamento:

• Por que o bloqueio na tabela Pessoa é necessário
• Por que o bloqueio só é feito em tempo de compilação?

Tenho duas tabelas que armazenam dados semelhantes, mas para períodos de tempo diferentes:

MainTable: contém registros do ano atual.

ArchiveTable: contém registros de anos anteriores.

Ambas as tabelas têm uma coluna chamada DateColumn (do tipo DATETIME). Preciso escrever uma consulta T-SQL (ou conjunto de consultas) que se comporte da seguinte forma com base em dois parâmetros de entrada, @StartDate e @EndDate:

Somente ano atual: se ambas as datas estiverem dentro do ano atual, busque dados somente da MainTable.

Somente anos anteriores: se ambas as datas forem anteriores ao ano atual, busque dados somente do ArchiveTable.

Intervalo misto: se o intervalo de datas abranger anos anteriores e o ano atual, busque dados de ambas as tabelas.

Por exemplo, se o ano atual for 2025:

@StartDate = '2025-03-01' e @EndDate = '2025-03-31' devem retornar apenas linhas da MainTable.

@StartDate = '2024-11-01' e @EndDate = '2024-12-31' devem retornar apenas linhas de ArchiveTable.

@StartDate = '2024-12-15' e @EndDate = '2025-01-15' devem retornar linhas de ambas as tabelas (divididas no limite).

Pensei em usar a lógica IF…ELSE para decidir qual tabela consultar, mas estou procurando conselhos sobre a melhor e mais elegante maneira de implementar isso (talvez em uma única consulta, usando UNION ALL ou SQL dinâmico).

Quais são as melhores práticas ou métodos alternativos para implementar essa lógica? Isso pode ser alcançado em uma única consulta ou por meio de outras técnicas que podem simplificar a manutenção?

então estou importando alguns dados de um servidor diferente em uma tabela que tenho no banco de dados mestre

isso é feito por meio de uma consulta no servidor de destino, mas preciso especificar credenciais em ambos os servidores.

Como tenho que fazer isso várias vezes, quero salvar o pacote para que, com o mínimo de esforço, eu possa alterar a consulta e a tabela de destino e executá-lo novamente.

Então configurei minha consulta no servidor de origem e configurei a tabela no servidor de destino

Eu configurei para salvar meu pacote no servidor SQL como você pode ver na imagem abaixo, mas

onde posso vê-lo? Posso reutilizá-lo?

Estou executando isso no servidor de destino, então deveria estar lá, mas onde?

Como você faz a correspondência de padrões usando cte?

Eu tentei o seguinte:

with cte1 as (
    select '''' || '{' || accountids || '}' || '''' as accountids
    from table_a
    where email = '[email protected]'
)
select id 
from table_a
where accountids ^@ ANY (select accountids from cte1);

Eu esperaria que o conjunto de resultados retornasse a12 e c45. Isso é possível?