Instalei o Cassandra na minha máquina Linux (Ubutnu).
Eu tinha o OpenJDK 11 instalado, depois instalei o JDK 17, configurei-o para o padrão e reiniciei o Cassandra.
Posso ver que a nova versão está sendo usada em /var/log/cassandra/system.log
Tudo está funcionando, mas não está claro para mim se usar 17 é considerado "experimental" ou não, ou se é preferível a 11?
Estou executando o Mysql 8 com tabelas InnoDB. Tenho uma tabela com 100 mil linhas pequenas que está sob uso pesado (10-50 consultas por segundo).
Quero trocar a tabela com sua versão mais recente, usando RENAME table TO old_table, replacement_table TO table. O que acontece com as consultas em execução? Elas travam ou terminam graciosamente? As novas consultas esperam a renomeação terminar ou podem usar a nova versão da tabela, enquanto as consultas existentes são concluídas com a antiga?
Em geral, é uma abordagem OK para atualizar uma tabela? Eu precisaria comparar cada linha para alterações, caso contrário, procurar por linhas novas e excluídas, então trocar uma tabela como essa parece ser bem mais simples.
Obrigado
Eu sei que essa provavelmente é uma pergunta boba, É a minha primeira, Parece tão fundamental que não consigo encontrar a resposta em lugar nenhum, porque deve ser tão simples que ninguém explicou. Quero entender completamente como as transações funcionam e, em particular, os níveis de isolamento e, especialmente, o nível de isolamento UNCOMMITTED READ e dirty read.
Há algumas informações contraditórias. Todos esses links abaixo são da documentação oficial:
Li muitos recursos online, alguns destes: https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver16
https://medium.com/inspiredbrilliance/what-are-database-locks-1aff9117c290
https://docs.oracle.com/cd/E17277_02/html/TransactionGettingStarted/isolation.html#dirtyreads
diga algo como:
Uma leitura suja ocorre quando uma transação pode visualizar dados modificados por outra transação que ainda não foi confirmada. Mas como isso é possível e o que isso significa exatamente?
Mas isso é contraditório, se eu ver a documentação do PostgreSQL aqui: https://www.postgresql.org/docs/current/tutorial-transactions.html
Diz:
Transações são um conceito fundamental de todos os sistemas de banco de dados. O ponto essencial de uma transação é que ela agrupa várias etapas em uma única operação do tipo tudo ou nada. Os estados intermediários entre as etapas não são visíveis para outras transações simultâneas e, se ocorrer alguma falha que impeça a transação de ser concluída, nenhuma das etapas afetará o banco de dados.
E aqui:
Outra propriedade importante dos bancos de dados transacionais está intimamente relacionada à noção de atualizações atômicas: quando várias transações estão sendo executadas simultaneamente, cada uma não deve ser capaz de ver as alterações incompletas feitas por outras. Por exemplo, se uma transação estiver ocupada totalizando todos os saldos das agências, não seria bom incluir o débito da agência de Alice, mas não o crédito da agência de Bob, nem vice-versa. Portanto, as transações devem ser tudo ou nada, não apenas em termos de seu efeito permanente no banco de dados, mas também em termos de sua visibilidade à medida que acontecem. As atualizações feitas até agora por uma transação aberta são invisíveis para outras transações até que a transação seja concluída, quando todas as atualizações se tornam visíveis simultaneamente.
Eu pensei que as transações são autônomas e tudo ou nada, então como uma instrução de atualização, por exemplo, no meio de uma transação antes do commit, pode ser visível para outra? Afinal, duas ou mais transações podem até ter seus próprios threads/processos no caso do PostgreSQL, então como elas podem visualizar os dados antes do commit?
Isso significa que quando executamos instruções DML individuais dentro de uma transação, elas atualizam as linhas antes do commit e então revertem se falharem? Isso depende de como os bloqueios? Porque essa é a única maneira que eu consigo pensar que poderia funcionar
No que diz respeito às leituras sujas, uma leitura suja é o valor na linha original que foi selecionado por outra transação que pode modificá-la ou são os dados dentro de uma transação que foram atualizados, mas ainda não confirmados.
Não estou entendendo nada muito fundamental sobre isso
Por exemplo:
Considere esta tabela de exemplo básica:
CREATE TABLE TransactionEg (
id INT GENERATED BY DEFAULT AS IDENTITY,
name VARCHAR,
x INT,
y INT,
CONSTRAINT TransactionEgPk PRIMARY KEY(id)
);
INSERT INTO transactioneg (name, x, y)
VALUES
('Row 1', 5, 11),
('Row 2', 7, 23),
('Row 3', 11, 36);
Se transação 1:
BEGIN;
SELECT * FROM transactioneg T WHERE T.id = 1;
UPDATE transactioneg T SET x = x + 5 WHERE T.id = 1;
COMMIT;
Mais ou menos no mesmo momento ou logo após a instrução SELECT na 1ª transação, transação 2:
BEGIN;
SELECT * FROM transactioneg T WHERE T.id = 1;
UPDATE transactioneg T SET x = x + 10 WHERE T.id = 1;
COMMIT;
A transação 1 atualizaria o valor de x de 5 para 10. Então a transação 2 vê 10 antes do Commit? Ou ela só obtém 5, já que esse é o valor original antes do commit e o 5 se torna a leitura suja?
Qualquer conselho seria bem-vindo, embora eu ache que posso receber votos negativos por essa pergunta, espero que não.
Considerar:
Qual das seguintes opções seria mais eficiente?
SELECT * FROM B WHERE "aid" = f_name2id(<some_name>);SELECT B.* FROM B INNER JOIN A ON B."aid" = A."id" WHERE A."name" = <some_name>;
Tenho um site para mostrar partidas de um jogo RTS.
Um dos principais casos de uso é mostrar partidas recentes de um jogador ou de um grupo de jogadores .
PostgreSQL 14.13
Estrutura da tabela:
create table public.match (
match_id integer primary key not null,
started timestamp(3) without time zone,
...
);
create index "IDX_e7b6cfca8139b9aa85880aab9e" on match using btree (started);
create table public.player (
match_id integer not null,
profile_id integer not null,
slot smallint not null,
...,
primary key (match_id, profile_id, slot),
foreign key (match_id) references public.match (match_id)
match simple on update cascade on delete restrict,
foreign key (profile_id) references public.profile (profile_id)
match simple on update cascade on delete restrict
);
create index idx_player_profile_match on player using btree (profile_id, match_id);
create index "IDX_58afd2c450f166eacbdf982841" on player using btree (match_id);
create index "IDX_ba3de28aa98207f3a21145feb8" on player using btree (profile_id);
A tabela de partidas tem 50 milhões de registros. A tabela de jogadores tem 200 milhões de registros.
Há cerca de 50.000 partidas com 4 jogadores em média adicionados por dia ao banco de dados.
As tabelas atualmente contêm dados dos últimos 3 anos. A tabela match tem relation_size 6 GB e total_relation_size 12 GB. A tabela player 15 GB e 37 GB.
Consultar o BD para as 50 partidas mais recentes de um jogador ou para todas as partidas do último mês de um jogador leva quase um segundo . Após a primeira execução, é mais rápido porque é armazenado em cache, mas isso não me ajuda, pois frequentemente são solicitados usuários diferentes.
-- most recent 50 matches for a player
EXPLAIN ANALYSE
SELECT * FROM match m
JOIN player p on p.match_id = m.match_id
WHERE p.profile_id=582058 ORDER BY started desc LIMIT 50;
Limit (cost=12075.34..12081.09 rows=50 width=107) (actual time=675.517..682.833 rows=50 loops=1)
-> Gather Merge (cost=12075.34..12158.48 rows=723 width=107) (actual time=675.516..682.828 rows=50 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Sort (cost=11075.33..11077.14 rows=723 width=107) (actual time=663.726..663.731 rows=38 loops=2)
Sort Key: m.started DESC
Sort Method: top-N heapsort Memory: 39kB
Worker 0: Sort Method: top-N heapsort Memory: 37kB
-> Nested Loop (cost=22.66..11051.31 rows=723 width=107) (actual time=3.286..661.017 rows=1882 loops=2)
-> Parallel Bitmap Heap Scan on player p (cost=22.09..4853.22 rows=723 width=40) (actual time=2.774..210.891 rows=1882 loops=2)
Recheck Cond: (profile_id = 582058)
Heap Blocks: exact=1855
" -> Bitmap Index Scan on ""IDX_ba3de28aa98207f3a21145feb8"" (cost=0.00..21.79 rows=1229 width=0) (actual time=4.818..4.819 rows=3772 loops=1)"
Index Cond: (profile_id = 582058)
-> Index Scan using match_pkey on match m (cost=0.56..8.57 rows=1 width=67) (actual time=0.237..0.237 rows=1 loops=3764)
Index Cond: (match_id = p.match_id)
Planning Time: 0.305 ms
Execution Time: 682.897 ms
-- matches in the last month for a player
EXPLAIN ANALYSE
SELECT * FROM match m
JOIN player p on p.match_id = m.match_id
WHERE m.started > '2024-09-01' AND
p.profile_id=271202 ORDER BY started desc;
Gather Merge (cost=12053.93..12057.61 rows=32 width=107) (actual time=797.710..797.881 rows=161 loops=1)
Workers Planned: 1
Workers Launched: 1
-> Sort (cost=11053.92..11054.00 rows=32 width=107) (actual time=782.572..782.578 rows=80 loops=2)
Sort Key: m.started DESC
Sort Method: quicksort Memory: 36kB
Worker 0: Sort Method: quicksort Memory: 35kB
-> Nested Loop (cost=22.66..11053.12 rows=32 width=107) (actual time=171.842..781.756 rows=80 loops=2)
-> Parallel Bitmap Heap Scan on player p (cost=22.09..4853.22 rows=723 width=40) (actual time=1.254..268.523 rows=1682 loops=2)
Recheck Cond: (profile_id = 271202)
Heap Blocks: exact=1721
" -> Bitmap Index Scan on ""IDX_ba3de28aa98207f3a21145feb8"" (cost=0.00..21.79 rows=1229 width=0) (actual time=1.712..1.712 rows=3378 loops=1)"
Index Cond: (profile_id = 271202)
-> Index Scan using match_pkey on match m (cost=0.56..8.58 rows=1 width=67) (actual time=0.304..0.304 rows=0 loops=3365)
Index Cond: (match_id = p.match_id)
Filter: (started > '2024-09-01 00:00:00'::timestamp without time zone)
Rows Removed by Filter: 1
Planning Time: 0.446 ms
Execution Time: 797.931 ms
Ao executar isso novamente, o tempo de execução cai para cerca de 40 ms devido ao cache.
Até onde eu entendo, o Postgres primeiro encontra todos os registros de jogadores para o profile_id fornecido e então ordena por data de início e então filtra por contagem/data de início . Dessa forma, a consulta se tornará cada vez mais ineficiente à medida que mais correspondências forem adicionadas ao banco de dados.
Minha ideia é adicionar a data de início da partida à tabela de jogadores e criar um índice em profile_id, iniciado.
Você acha que essa é uma boa solução? Existem outras opções?
Também pensei em particionar a tabela de partidas/jogadores por data de início, mas isso parece dar muito trabalho.
Atualização usando a resposta de Erwin Brandstetter:
Obrigado pelo seu conselho!
Criei o índice e preenchi a startedcoluna da playertabela:
CREATE INDEX player_profile_id_started_match_id ON player (profile_id, started) INCLUDE (match_id);
A consulta de partidas recentes para um jogador agora é muito rápida:
-- get recent 50 matches for one player
EXPLAIN ANALYSE
SELECT *
FROM (
SELECT p.match_id
FROM player p
WHERE p.profile_id=199325
ORDER BY p.started DESC
LIMIT 50
) p
JOIN match m USING (match_id);
Nested Loop (cost=1.14..500.47 rows=50 width=67) (actual time=2.721..21.442 rows=50 loops=1)
-> Limit (cost=0.57..70.85 rows=50 width=12) (actual time=2.702..14.494 rows=50 loops=1)
-> Index Only Scan Backward using player_profile_id_started_match_id on player p (cost=0.57..1739.19 rows=1237 width=12) (actual time=2.701..14.480 rows=50 loops=1)
Index Cond: (profile_id = 199325)
Heap Fetches: 50
-> Index Scan using match_pkey on match m (cost=0.56..8.58 rows=1 width=67) (actual time=0.138..0.138 rows=1 loops=50)
Index Cond: (match_id = p.match_id)
Planning Time: 0.222 ms
Execution Time: 21.482 ms
Também tenho o caso de uso de consultar as partidas recentes de vários jogadores (um ou mais jogadores precisam estar na partida).
-- get recent 50 matches from multiple players
EXPLAIN ANALYSE
SELECT *
FROM (
SELECT p.match_id
FROM player p
WHERE p.profile_id IN (1136191, 19455781)
ORDER BY p.started DESC
LIMIT 50
) p
JOIN match m USING (match_id);
Nested Loop (cost=3557.08..3986.26 rows=50 width=67) (actual time=511.692..515.601 rows=50 loops=1)
-> Limit (cost=3556.51..3556.64 rows=50 width=12) (actual time=511.658..511.671 rows=50 loops=1)
-> Sort (cost=3556.51..3562.70 rows=2473 width=12) (actual time=511.657..511.663 rows=50 loops=1)
Sort Key: p.started DESC
Sort Method: top-N heapsort Memory: 29kB
-> Index Only Scan using player_profile_id_started_match_id on player p (cost=0.57..3474.36 rows=2473 width=12) (actual time=0.592..508.846 rows=5277 loops=1)
" Index Cond: (profile_id = ANY ('{1136191,19455781}'::integer[]))"
Heap Fetches: 2965
-> Index Scan using match_pkey on match m (cost=0.56..8.58 rows=1 width=67) (actual time=0.078..0.078 rows=1 loops=50)
Index Cond: (match_id = p.match_id)
Planning Time: 1.090 ms
Execution Time: 515.662 ms
Neste exemplo, ele estava muito lento. Mas depois de uma execução VACUUM ANALYZE public.player;que levou 7 minutos, ele está rodando rápido (cerca de 30 ms).
Observação: ainda não atualizei a chave estrangeira e o índice exclusivo porque a data de início nunca será alterada após a criação dos registros de partidas e jogadores.
Encontrei esta consulta linda online (não consigo lembrar a quem agradecer por ela) e tentei modificá-la para que backup_finish_date sem valor não fosse gerado como NULL, mas não consegui descobrir. A consulta faz exatamente o que eu gostaria de fazer (e aprender a fazer sozinho) com a única exceção da saída NULL. Eu também gostaria de formatá-la em dd-mm-aaaa hh:mm
SELECT name ,
recovery_model_desc as 'Recovery Model' ,
state_desc as 'State',
d AS 'Last Full Backup' ,
i AS 'Last Differential Backup' ,
l AS 'Last log Backup'
FROM ( SELECT db.name ,
db.state_desc ,
db.recovery_model_desc ,
type ,
backup_finish_date
FROM master.sys.databases db
LEFT OUTER JOIN msdb.dbo.backupset a ON a.database_name = db.name
) AS Sourcetable
PIVOT
( MAX(backup_finish_date) FOR type IN ( D, I, L ) ) AS MostRecentBackup
WHERE (name NOT IN ('master','msdb','model','tempdb'))
Estou tentando acessar a tabela Customer a partir dos dados na tabela SiteConfiguration.
Estou pegando os dados e configurando-os para @AdditionalVoteViewers, que seria uma sequência de endereços de e-mail. Então, divido a sequência e insiro os resultados em uma tabela temporária.
Nesse ponto, unirei a tabela temporária com a tabela Cliente para retornar o CustomerId .
Só quero ver se há uma maneira melhor de fazer isso.
Dados na tabela SiteConfiguration
[email protected];[email protected]
Dados na tabela Cliente
[email protected] 1
[email protected] 2
Código:
declare @AdditionalVoteViewers VARCHAR(100)
Select @AdditionalVoteViewers =
(
SELECT [Value] FROM [SiteConfiguration]
where Name = 'AdditionalVoteViewers'
)
print @AdditionalVoteViewers
--CREATE TABLE #TempAdditionalVoteViewers(email varchar(MAX) )
select * into #TempAdditionalVoteViewers
from [dbo].[Split] (@AdditionalVoteViewers,';')
--select * from #TempAdditionalVoteViewers
select [CustomerId] into #TempAdditionalVoteViewersId
from [dbo].[Customer] c
join #TempAdditionalVoteViewers t on c.Email = t.val
select * from #TempAdditionalVoteViewersId
Estou procurando o local da pasta de instantâneos para minha replicação de mesclagem
Eu tentei:
select top 5 * FROM sysmergepublications pub
select * FROM dbo.sysmergeSubscriptions
mas isso não me mostra o nome da pasta e como precisa de permissões sobre ela
onde posso obter essas informações usando t-sql?
Todas as noites o agendador Laravel executa "mysqldump -h $dbHost -u $dbUsername -p$dbPassword $dbDatabase > $path/$filename"comandos por meio exec()de funções.
E às vezes o dump é corrompido em algum lugar aleatório:
Um bom dump se parece com isso:
LOCK TABLES `action_categories_link` WRITE;
/*!40000 ALTER TABLE `action_categories_link` DISABLE KEYS */;
INSERT INTO `action_categories_link` VALUES (1,1,1),(10,2,1),(15,3,2);
/*!40000 ALTER TABLE `action_categories_link` ENABLE KEYS */;
UNLOCK TABLES;
E o ruim:
LOCK TABLES `action_categories_link` WRITE;
/*!40000 ALTER TABLE `action_categories_link` DISABLE KEYS */;
INSERT INTO `action_categories_link` VALUES (1,1,1),(10,2,1),(15,3,/*!4/*40000 ALTER TABLE `action_categories_link` ENABLE KEYS */;
UNLOCK TABLES;
Também vi esta linha:
LOCKLOCK TABLES `action_categories` WRITE;
Não posso executar um dump enquanto o aplicativo está em execução? O tamanho típico do dump é de quase 2 GB, mas esses erros aparecem desde o começo. Alguns dumps não estão corrompidos, então não tenho a mínima ideia.
Despejando no mesmo servidor Linux que o db, sem docker. MySQL dump 10.13 Distrib 8.0.29
Considere o seguinte código:
CREATE OR REPLACE PACKAGE the_package AS
PROCEDURE procA ( pval1 IN VARCHAR2 );
PROCEDURE procA ( pval1 IN NUMBER );
END;
/
Eles criaram um pacote PLSQL que possui os procedimentos sobrecarregados procA.
Agora criamos procedimentos que chamam estes:
CREATE OR REPLACE testProc1 AS
l_val VARCHAR2 := 'Boncho';
BEGIN
the_package.procA( l_val );
END;
/
CREATE OR REPLACE testProc21 AS
l_val NUMBER := 88;
BEGIN
the_package.procA( l_val );
END;
/
O que eu quero fazer é conseguir identificar quais variantes testProc1e testProc2chamar.
Não posso usar DBA_DEPENDENCIESporque ele apenas me diz que testProc1e testProc2dependem do pacote the_package.
Não posso usar DBA_PROCEDURESporque ele só me diz quais procedimentos podem ser chamados.
Parece que a única opção é usar de alguma forma uma combinação de DBA_PROCEDURES, DBA_ARGUMENTSe DBA_SOURCEe fazer alguma análise semelhante à de um compilador para obter a saída desejada de:
testProc1Chamadas de procedimento procAdo pacote the_packagena linha 2. testProc2Chamadas de procedimento procAdo pacote the_packagena linha 3.
Mas quem quer escrever um compilador PLSQL?
No entanto, acho que o Oracle faz a validação em tempo de compilação, ou seja, quando compila os procedimentos, ele verifica se os procedimentos que estão sendo chamados existem. Então, estou pensando que talvez haja informações de qual procedimento precisamente é chamado armazenado em algum lugar nos metadados.
Alguém sabe de algum lugar nas visualizações de metadados onde essas informações são mantidas?