Estamos testando um Oracle OCI DBCS e habilitei o backup automático. Vi que os logs de arquivo foram se acumulando desde que habilitei o backup automático e gostaria de saber se o OCI também exclui os logs de arquivo automaticamente?
Cumprimentos
Estou criando uma tabela com lógica de particionamento. Abaixo está a função e o esquema da partição:
DECLARE @StartDate datetime2 = '20230401';
DECLARE @YearlyQuartersPartitionFunction nvarchar(max) = N'CREATE PARTITION FUNCTION YearlyQuartersPartitionFunction (datetime2) AS RANGE RIGHT FOR VALUES (';
DECLARE @i datetime2 = @StartDate;
WHILE @i < '20300101'
BEGIN
SET @YearlyQuartersPartitionFunction += '''' + CAST(@i as nvarchar(10)) + '''' + N', ';
SET @i = DATEADD(MM, 3, @i);
END
SET @YearlyQuartersPartitionFunction += '''' + CAST(@i as nvarchar(10))+ '''' + N');';
--PRINT @YearlyQuartersPartitionFunction;
EXEC sp_executesql @YearlyQuartersPartitionFunction;
GO
Se você executar o bloco para criar a função de partição descomentando a instrução PRINT, verá o seguinte:
CREATE PARTITION FUNCTION YearlyQuartersPartitionFunction (datetime2) AS RANGE RIGHT FOR VALUES ('2023-04-01', '2023-07-01', '2023-10-01', '2024-01-01', '2024-04-01', '2024-07-01', '2024-10-01', '2025-01-01', '2025-04-01', '2025-07-01', '2025-10-01', '2026-01-01', '2026-04-01', '2026-07-01', '2026-10-01', '2027-01-01', '2027-04-01', '2027-07-01', '2027-10-01', '2028-01-01', '2028-04-01', '2028-07-01', '2028-10-01', '2029-01-01', '2029-04-01', '2029-07-01', '2029-10-01', '2030-01-01');
-- Partition scheme that maps to the PRIMARY filegroup
CREATE PARTITION SCHEME YearlyQuartersPartitionScheme
AS PARTITION YearlyQuartersPartitionFunction
ALL TO ([PRIMARY]);
E estou usando este esquema para criar uma tabela usando o DDL abaixo:
CREATE TABLE [dbo].[MyTable](
[Id] [uniqueidentifier] NOT NULL,
[CompanyId] [uniqueidentifier] NOT NULL,
[AddedUtc] [datetime2](7) NOT NULL,
[IsTest] [bit] NOT NULL
) ON YearlyQuartersPartitionScheme(AddedUtc) ON PRIMARY;
GO
ALTER TABLE [dbo].[MyTable] ADD CONSTRAINT [PK_MyTable] PRIMARY KEY CLUSTERED
(
[Id] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [IX_MyTable_CompanyId] ON [dbo].[MyTable]
(
[CompanyId] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, DROP_EXISTING = OFF, ONLINE = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO
ALTER TABLE [dbo].[MyTable] ADD DEFAULT (CONVERT([bit],(0))) FOR [IsTest]
GO
ALTER TABLE [dbo].[MyTable] WITH CHECK ADD CONSTRAINT [FK_MyTable_Companies_CompanyId] FOREIGN KEY([CompanyId])
REFERENCES [dbo].[Companies] ([Id])
ON DELETE CASCADE
GO
ALTER TABLE [dbo].[MyTable] CHECK CONSTRAINT [FK_MyTable_Companies_CompanyId]
GO
Se eu verificar as partições criadas para esta tabela, vejo que todas as partições têm o mesmo valor de número_de_partição. Isto está errado.
Alguém pode apontar se estou fazendo algo flagrantemente errado.
Percebo que o data_space_id do esquema de partição não corresponde ao data_space_id dos índices da tabela.
Aqui está meu comando para o banco de dados GRASS GIS (driver SQL Lite usado):
db.execute sql="UPDATE streams_order SET factor=next_stream WHERE number IS NOT NULL AND next_stream IN (SELECT number FROM streams_order)"
Mas eu quero
db.execute sql="UPDATE streams_order SET factor=next_stream WHERE number IS NOT NULL AND next_stream NOT IN (SELECT number FROM streams_order)"
E o resultado deve ser:
+---------+--------------+--------+---------+
| stream | next_stream factor | number |
+-------------------------------------------+
370 -1
372 370 370 372
374 440
376 372 376
380 374 374 380
.............................................
não funciona sem nenhum erro: a coluna "fator" fica vazia após executar o comando. Se eu colocar IN, funciona bem. Os tipos de coluna são todos INT.
Sandbox com dados reais está aqui https://dbfiddle.uk/zg8_xJUz
Acabei de instalar o PostegreSql 15.1
Anterior Instalei e desinstalei várias vezes
Após esta última instalação, se eu tentar via PgAdmin ver as tabelas PostegreSql "padrão", a lista fica vazia (ver imagem)
Tentei instalar (também versão 16.rc1) e desinstalá-lo várias vezes mas não consigo ver a "tabela padrão"
Eu tento fazer uma consulta com junção interna do Grass Gis (mas naquela comunidade essa questão era considerada offtopic, então parece se referir apenas ao SQL Lite):
db.execute sql="UPDATE A SET A.next2=B.next_stream
FROM stream_order2 AS A
INNER JOIN stream_order2 AS B ON A.factor=B.stream"
Tenho que fazer isso porque gostaria de definir os valores de next2 como valores do próximo fluxo da tabela correspondente aos números de fluxo iguais ao valor do fator. db.execute gera um erro.
Então atualizei o comando e removi a instrução A.. Agora o erro é:
Error in sqlite3_prepare():
near "FROM": syntax error
Tentei remover A. depois de ON, mas não adiantou, não acho que seja o problema.
Antecedentes e Observações:
Eu tenho um cluster de 3 nós em execução em produção (versão 3.11). Para a migração, tentei primeiro criar 1 novo nó com a versão cassandra 4.1.2 e adicionei esses nós ao cluster existente. Para adicionar esses nós, tive que executar -Dcassandra.skip_schema_check=trueo comando, caso contrário, o novo nó falharia na inicialização. Depois que consegui adicionar esses nós ao cluster existente, observei que os dados não estão sendo transmitidos para o novo nó da versão 3 para a versão 4. A ideia aqui era que, uma vez que os dados fossem replicados para os nós da versão 4, pudéssemos desligar os nós da versão 3 um por um e isso seria uma migração tranquila.
O documento para migração de 3.x para 4.x aqui sugere que a migração deve ser feita nó por nó e eu deveria primeiro derrubar um nó e então configurar o cassandra 4 nesse nó e então usar os mesmos arquivos de dados para executar o cassandra 4 e faça o mesmo para todos os nós.
Pergunta:
Minha pergunta é que, se eu prosseguir com a abordagem mencionada no documento datastax, chegará um momento em que a versão 4 e a versão 3 coexistirão enquanto minha carga de leitura/gravação ainda chegará ao cluster. Durante esse período, a transferência de dados entre 2 nós com versões diferentes não acontecerá, portanto, a solicitação de gravação indo para o nó da versão 4 não será replicada para o nó da versão 3 e vice-versa. Isso causará inconsistência de dados até que todos os nós sejam migrados e comecem a se comunicar entre si. Presumimos que os dados serão consistentes eventualmente aqui, mas se houver algum problema durante esse processo, não teremos como resolver os dados inconsistentes na produção. Então, quais etapas posso seguir para garantir que não haja inconsistência de dados e, se algo der errado, haja uma maneira mais fácil de corrigir os dados. E também queria entender por que a primeira abordagem mencionada acima não era suportada pelo cassandra, pois parece uma abordagem mais fácil para um desenvolvedor do ponto de vista da migração.
Estou criando uma tabela no Postgresql-11, e preciso criar uma chave primária para ela ao mesmo tempo, para evitar que dados duplicados sejam inseridos antes da criação do PK, então quero que essas duas operações sejam realizadas dentro de uma mesma transação.
Eu sei que isso pode dar certo:
CREATE TABLE IF NOT EXISTS my_tab (
my_key INT8 NOT NULL,
PRIMARY KEY ( my_key ) );
Mas também quero definir um nome para este PK, em vez do nome padrão, para facilitar a manutenção.
Se eu fizer da seguinte maneira:
CREATE TABLE IF NOT EXISTS my_tab ( my_key INT8 NOT NULL );
ALTER TABLE my_tab ADD CONSTRAINT custom_pk_name_my_tab PRIMARY KEY ( my_key );
Estou preocupado que essas duas declarações sejam feitas em duas transações diferentes. ou seja, existe alguma probabilidade de alguns dados duplicados serem inseridos antes da criação da PK?
E ainda mais, que tal se a mesa já existisse? Se a tabe já existir, a segunda instrução falhará?
O SQL acima é executado em meu programa C++, que é um serviço daemon de longa data. Não quero que ele trave sem a participação humana por causa de uma falha de SQL.
Como conseguir isso? Obrigado!
Digamos que eu tenha uma mesa:
CREATE TABLE transactions (
id NUMERIC(20, 0) PRIMARY_KEY,
account_id VARCHAR(512),
...
transaction_date TIMESTAMP
);
Assim, com o SQL Server, um índice:
CREATE NONCLUSTERED INDEX my_index ON transactions (account_id, transaction_date, id);
e uma consulta:
SELECT id FROM transactions
WHERE account_id = '123'
AND transaction_date > '2023-01-01'
realiza uma busca de índice, ou seja, a consulta é atendida a partir do índice, não fazendo referência à tabela, pois todos os dados necessários estão presentes na tabela. Se meu índice fosse:
CREATE NONCLUSTERED INDEX my_index ON transactions (account_id, transaction_date);
a consulta iria para a tabela para atender a consulta (Index Scan). Qual dos seguintes bancos de dados:
- Oráculo
- MySQL
- PostgreSQL
apoiar o comportamento acima?
Estou analisando um aplicativo legado que gerencia objetos armazenados em um banco de dados PostgreSQL.
Cada objeto possui vários conjuntos de propriedades que são armazenados como objetos JSONB. Cada um desses conjuntos de propriedades descreve um aspecto diferente do objeto (pode haver de 1 a 10 conjuntos de propriedades por objeto).
Em relação a isso, diferentes departamentos geralmente se preocupam apenas com alguns desses conjuntos de propriedades (aspectos), portanto o número de conjuntos de propriedades varia dependendo de quem está envolvido durante o ciclo de vida de cada objeto.
Cada vez que algo muda em uma propriedade definida pelo aplicativo front-end (que está além do meu controle), ele é enviado de volta ao banco de dados como um novo documento JSON.
No momento, a tabela (para efeito de argumentação) está estruturada da seguinte forma:
TABLE x (
object_id INTEGER,
aspect_id INTEGER,
doc_ts TIMESTAMP,
doc JOSNB,
PRIMARY KEY (object_id, aspect_id, doc_ts)
)
A entrada de dados é tratada por um procedimento, que armazena uma cópia do documento em uma tabela, e tem a seguinte aparência:
CREATE OR REPLACE PROCEDURE ingest.generic_object(IN in_object_id integer, IN in_aspect_id integer, IN in_doc_ts TIMESTAMP, IN in_doc JSONB DEFAULT NULL::JSONB)
LANGUAGE plpgsql
AS $procedure$
BEGIN
INSERT INTO ingest.x ( object_id, aspect_id, doc_ts, doc)
VALUES (in_object_id, in_aspect_id, in_doc_ts, in_doc)
;
END;
$procedure$;
Agora vamos passar para o problema que estou tentando resolver. Esta tabela continua crescendo com o tempo e pode ficar muito grande, muito rapidamente. O processo de manutenção mantém APENAS um registro para cada combinação de object_id e aspecto_id (ou seja, apenas aquele com o valor doc_ts mais recente) e leva muito tempo para ser executado.
Estou pensando em dividir os dados em duas tabelas. Como:
TABLE ingest.x (
object_id INTEGER,
aspect_id INTEGER,
doc_ts TIMESTAMPZ,
doc JOSNB,
PRIMARY KEY (object_id, aspect_id, doc_ts)
);
TABLE ingest.x_history (
object_id INTEGER,
aspect_id INTEGER,
doc_ts TIMESTAMP,
doc JOSNB,
PRIMARY KEY (object_id, aspect_id, doc_ts)
);
E então altere a função de ingestão para algo parecido com:
CREATE OR REPLACE PROCEDURE ingest.generic_object(IN in_object_id integer, IN in_aspect_id integer, IN in_doc_ts TIMESTAMP, IN in_doc JSONB DEFAULT NULL::JSONB)
LANGUAGE plpgsql
AS $procedure$
BEGIN
WITH
dd AS (
DELETE FROM ingest.x
WHERE object_id= in_object_id
AND aspect_id = in_aspect_id
RETURNING *
),
di AS (
INSERT INTO ingest.x_history ( object_id, aspect_id, doc_ts, doc)
SELECT object_id, aspect_id, doc_ts, doc FROM dd
)
INSERT INTO ingest.x ( object_id, aspect_id, doc_ts, doc)
VALUES (in_object_id, in_aspect_id, in_doc_ts, in_doc)
;
END;
$procedure$;
Isso me permitiria simplificar SIGNIFICATIVAMENTE o processo de limpeza, até:
TRUNCATE TABLE ingest.x_history;
Minhas perguntas são as seguintes:
Considerando a alteração acima, o AUTOVACUUM levará a alguma reutilização do espaço ocupado pelos registros excluídos em
ingest.x?Quais parâmetros de tabela
ingest.xdevo ajustar para melhorar a reutilização do espaço liberado pelos registros excluídos? - Supondo que a resposta para 1 seja SIM. Tenho em mente o FILL FACTOR juntamente com limites de AUTOVACUUM mais direcionados.Você consegue ver uma abordagem alternativa para alcançar um processo de limpeza mais fácil e eficaz?
Observação:
- Tudo isso está rodando no PostgreSQL v15
- Os registros de documentos podem ser redigidos dezenas de vezes durante a fase de criação – primeiros dias. Depois, uma vez a cada dois dias/semanas durante o período de revisão. Mudanças podem acontecer depois disso, mas são muito raras.
- Os dados brutos podem envelhecer muito rapidamente, e é por isso que TRUNCAR o histórico não é um problema.
Edição 1: Os documentos JSON variam entre 100kb e 2MB. Acredito que sejam direcionados ao TOAST. Além disso, o banco de dados está em um sistema de arquivos ZFS e, como tal, a compactação PostgreSQL está desativada, aproveitando a compactação ZFS.
Atenciosamente
Para um projeto .Net maduro que apoio, estamos atualmente explorando opções para remover o Entity Framework Core do projeto, mantendo algumas das funcionalidades do EF nas quais confiamos.
No topo desta lista está a nossa capacidade de acompanhar exatamente quais valores foram alterados como resultado de uma solicitação de atualização que um sistema externo nos envia - não temos controle sobre esse sistema e não é incomum recebermos atualizações solicitações que contêm dados idênticos várias vezes.
Atualmente, usamos o rastreador de alterações da EF para verificar se a atualização que estamos processando realmente faz alguma alteração em um conjunto de colunas específicas, para que possamos saber se devemos ou não informar nossos usuários sobre essas alterações.
Analisar como poderíamos conseguir isso sem ter o EF e sua sobrecarga envolvidos me levou à cláusula OUTPUT do SQL Server , que teoricamente nos permitiria realizar uma atualização em uma tabela e retornar uma visão do estado anterior e atualizado das colunas-chave que use para gatilhos de notificações.
Até aí tudo bem, porém, há um aviso na seção Paralelismo desse documento que diz que "[uma] OUTPUTcláusula que retorna resultados ao cliente, ou variável de tabela, sempre usará um plano serial". Receio que meu conhecimento de SQL não seja forte o suficiente neste momento para saber se isso é um problema ou não.
Isso deveria me preocupar do ponto de vista de desempenho ou confiabilidade? Cada atualização que realizamos é codificada em um conjunto de colunas que formam (em quase todos os casos) uma chave composta exclusiva, portanto, mesmo que a parte da consulta da atualização seja executada em série, haveria um impacto perceptível?
Tomemos como exemplo o seguinte esquema:
CREATE TABLE user_profile
(
[id] INT IDENTITY (1,1) NOT NULL PRIMARY KEY
[username] NVARCHAR(100) NOT NULL,
[tenancy] NVARCHAR(20) NOT NULL,
[city] NVARCHAR(50) NULL,
[state] NVARCHAR(50) NULL,
[first_name] NVARCHAR(50) NULL,
[last_name] NVARCHAR(50) NULL,
[external_system_access_key] NVARCHAR(200) NULL,
CONSTRAINT [UX_user] UNIQUE ([username], [tenancy])
)
Neste exemplo, um usuário gerencia seus próprios valores city, statee , mas um sistema externo gerencia por meio de uma solicitação ao nosso serviço first_name, comolast_nameexternal_system_access_key
POST /{tenancyId}/user/{username}/profile/external
{
"accessKey": "1224567890"
}
Se recebermos a mesma atualização várias vezes sem que o valor seja accessKeyalterado, queremos saber se o valor difere antes e depois da execução da atualização, para sabermos se devemos ou não informar ao usuário que a chave foi alterada. Cada solicitação resultaria em uma atualização como esta:
DECLARE @accessKey NVARCHAR(200) = '1234567890';
DECLARE @username NVARCHAR(100) = 'username';
DECLARE @tenancy NVARCHAR(20) = 'tenancy';
UPDATE [user_profile]
SET [remote_system_access_key] = @accessKey
OUTPUT INSERTED.id, DELETED.[remote_system_access_key] AS OLD_remote_system_access_key, INSERTED.[remote_system_access_key] AS NEW_remote_system_access_key
WHERE
[username] = @username AND [tenancy] = @tenancy;
No caso em que a solicitação nos fornecesse um novo valor para essa coluna, haveria valores diferentes para cada uma das colunas de saída OLD_e NEW_, se for uma solicitação que tivemos anteriormente, eles corresponderão, permitindo-nos avaliar quaisquer alterações após a solicitação. a inserção está concluída.
Mas a documentação do SQL Server diz que isso sempre resultará em um plano de execução serial. O que preciso saber é: isso é um problema? Qualquer assistência que eu pudesse obter para entender isso e seus impactos potenciais seria muito apreciada.
Geralmente, cada atualização atingirá apenas uma linha por vez, pois sua cláusula where usa uma chave composta exclusiva. Estamos apenas tentando evitar o que o EF faz e exigir a consulta dos dados primeiro - em vez disso, como o SQL Server já fornece um mecanismo para saber qual era o estado antes e depois da atualização, gostaríamos de recuperar esses dados depois se isso não causar problemas de desempenho.
O exemplo que usei acima é bastante simplista comparado aos nossos casos reais, onde atualizaremos um grande número de colunas em cada instrução - todas em uma tabela, mas múltiplas colunas em cada uma. Seria proibitivamente complexo tentar cobrir todas as permutações possíveis do que poderia ser atualizado em cada solicitação.