All perguntas(dba)

esquema:

{
  time_utc: "milliseconds",
  city: "string",
  age: "integer"
}

índice:

{
  time_utc: 1,
  city: 1,
  age: 1
}

consulta de exemplo:

col.aggregate([
  {
    $match: { time_utc: { $exists: true }  city: "new york", age: { $gt: 18 } }
  },
  {
    $sort: { time_utc: -1 }
  }
])

Tenho certeza que o índice composto será utilizado nesta consulta, para que a classificação seja eficiente.

No entanto, a $matchetapa /filtragem de documentos não parece eficiente porque podemos assumir que time_utcé única em toda a coleção.

Suponhamos que haja 1 milhão de documentos no acervo e apenas 10 serão devolvidos. Suponhamos ainda que os 10 documentos estejam localizados na parte inferior da time_utcclassificação.

Neste cenário, a consulta deve varrer todo o valor de 1 milhão do índice para descobrir os 10 documentos. Isso equivale a uma varredura completa da coleção.

Vamos supor o contrário, que existam apenas 2 valores únicos em time_utc. Neste cenário, parece que o índice para os campos citye agepode de fato ser eficaz.

Meu raciocínio está correto?

Digamos que eu tenha uma tabela de compras parecida com esta:

Purchases
---------
Item_ID
Purchase_Date
Customer_ID

Como eu conseguiria obter o conjunto de compras, a partir da primeira compra, para cada cliente que esteja pelo menos X dias após a última compra? Por exemplo, se tivermos os dados abaixo e x=10:

Item_ID    PurchaseDate    Customer_ID    
123        07/29/23        1000
123        08/04/23        1000
123        08/16/23        1000
563        07/03/23        7785
563        07/05/23        7785
788        08/17/23        2489

A consulta deve retornar:

Item_ID    PurchaseDate    Customer_ID    
123        07/29/23        1000
123        08/11/23        1000
563        07/03/23        7785
788        08/17/23        2489

Então, para o cliente 1000, a primeira compra conta, porque é uma nova compra. A segunda compra ocorre há menos de 10 dias da última compra, por isso é descartada. A terceira compra deste cliente conta porque é superior ou igual a 10 dias após a última compra. Para o cliente 7785, apenas a primeira conta porque a segunda compra ocorre menos de 10 dias após a última compra e, finalmente, para o cliente 2489, ele tem apenas uma nova compra, então conta apenas como a nova compra. )

Eu estava pensando em usar a função lag

SELECT
    t.Item_ID,
    t.PurchaseDate,
    t.Customer_ID
FROM (
    SELECT
        p.Item_ID,
        p.PurchaseDate,
        p.Customer_ID,        
        LAG OVER(PARTITION BY Customer_ID ORDER BY PurchaseDate) next_purchase
        ROW_NUMBER() OVER(PARTITION BY Customer_ID ORDER BY PurchaseDate) rownum


        
    FROM
        PurchaseTable p
) t
WHERE
    DATEDIFF(DAY, t.PurchaseDate, t.next) >= 10) or rownum=1
       

EDIT: Desculpas, a descrição estava incorreta. Mudei a pergunta e o exemplo para os detalhes corretos.

O banco de dados é PostgreSQL15.

Estou escrevendo uma consulta que retornará uma lista de partições de tabela que preciso cortar. Minhas partições são nomeadas da seguinte forma: table_YYYYDOY, onde YYYY é o ano e DOY é o dia do ano. Por exemplo, a partição de hoje será denominada mytable_2023283.

Na consulta, gostaria de filtrar todas as partições com mais de 2 dias para poder removê-las. Recebo a lista de tabelas e depois entro nessa lista para selecionar aquelas que são partições da minha tabela principal. A configuração de amostra está incluída no db-fiddle neste link:

https://www.db-fiddle.com/#&togetherjs=QLQyTaPQkO

A consulta é a seguinte:

select  t.table_schema as schema_name,
        t.table_name,
        right(t.table_name, 7)::int8 as partition_postfix,
        (date_part('year', now()) * 1000 + date_part('doy', now() - interval '2 days'))::int8 as threshold,
        right(t.table_name, 7)::int8 - (date_part('year', now()) * 1000 + date_part('doy', now() - interval '2 days'))::int8 as diff
    from information_schema.tables t
    join pg_inherits i on i.inhrelid = (t.table_schema || '.' || t.table_name)::regclass
    where t.table_schema = 'public'
--      and right(t.table_name, 7)::int8 < (date_part('year', now()) * 1000 + date_part('doy', now() - interval '2 days'))::int8;

Tudo parece estar bem - mas quando tento incluir qualquer forma desse cálculo na cláusula WHERE, a consulta falha com Query Error: error: invalid input sintaxe for type bigint: "ref_sys" .

Parece que as tabelas do sistema que não estão particionadas são incluídas na lista assim que houver um WHERE. Tentei colocar isso em um CTE e operar no campo "diff" depois - também não funcionou.

Alguém pode me explicar o que está acontecendo aqui?

Vou criar um sistema de exame baseado em múltipla escolha. Sou novo no design de banco de dados e quero sua ajuda para responder algumas perguntas. Como modelar perguntas e categorias de perguntas?

Contexto: Existem vários assuntos (por exemplo: física, química, matemática, etc.). Cada assunto tem seções e cada seção tem capítulos. Por exemplo: Química tem seções: físico-química, química orgânica e química inorgânica. Cada seção tem capítulo relacionado.

E há perguntas e cada pergunta cai em um dos capítulos. Pelo contexto acima, fica claro que cada capítulo pertence a uma seção única de um assunto único. Agora, como devo continuar projetando o banco de dados para isso?

Opção 1:

questions:
question_text varchar,
...
chapter_id int foreign_key

chapters:
chapter_name varchar,
section_id int foreign_key

section:
section_name varchar,
subject_id int foreign_key

subject:
id int primary_key,
subject_name varchar,

Mas acho que isso levará a consultas complexas quando eu quiser encontrar perguntas por assunto e seções. Primeiro preciso encontrar todas as seções e depois todos os capítulos e depois encontrar as questões que pertencem a determinadas questões.

opção 2:

questions:
question_text varchar
subject_id int foreign_key,
section_id int foreign_key,
chapter_id int foreign_key,

subjects:
subject_id int primary_key,
subject_name varchar

sections:
section_id int primary_key,
section_name varchar

chapters:
chapter_id int primary_key,
chapter_name varchar

Neste caso, não haverá relação entre assuntos, seções e capítulos.

Eu adoraria ouvir algumas idéias.

Estamos em processo de migração do Microsoft SQL Server para Oracle. No SQL Server temos 60 bancos de dados (como XMLDB_1, XMLDB_2, XMLDB_3, ......, XMLDB_60) para inserir dados após ler 60 arquivos XML ao mesmo tempo. O SSIS lerá 60 arquivos XML por vez e inserirá dados nesses 60 bancos de dados. Cada um dos 60 bancos de dados contém 10 tabelas com a mesma estrutura. Da próxima vez, o SSIS lerá os próximos 60 arquivos XML e inserirá dados nos mesmos 60 bancos de dados. Cada vez antes de escolher os arquivos XML, todas as tabelas dentro de cada banco de dados (XMLDB) serão truncadas após enviar os dados para outro banco de dados (por exemplo, DocumentDB).

O que eu entendo é isso ou o que ouvi de outras pessoas - ter muitos serviços de banco de dados dentro de uma única instância de banco de dados Oracle pode criar problemas de desempenho devido à maior utilização de recursos. Por outro lado, no SQL Server, ter muitos bancos de dados não é grande coisa.

Estou procurando uma abordagem de design melhor aqui,

1. Precisamos prosseguir criando 60 serviços de banco de dados XML (XMLDB_1,XMLDB_2,XMLDB_3,......,XMLDB_60) em uma única instância de banco de dados Oracle? Ou,
2. Precisamos criar quantas tabelas forem necessárias para processar 60 arquivos XML por vez, mas em um único serviço de banco de dados. Neste caso precisaríamos criar 600 tabelas (10 tabelas dentro de cada XMLDB e temos 60 XMLDBs, portanto 60x10 = 600) em um único serviço de banco de dados.

Tenho um Grupo de Disponibilidade Distribuída em meu ambiente de produção que ocasionalmente atinge o tempo limite.

Quando isso acontece, recebo a seguinte mensagem em AlwaysOn_health no encaminhador:

Ocorreu um tempo limite de conexão ao tentar estabelecer uma conexão com a réplica de disponibilidade 'xxx' com id [xxx]. Existe um problema de rede ou de firewall ou o endereço do terminal fornecido para a réplica não é o terminal de espelhamento do banco de dados da instância do servidor host.

Eu queria tentar aumentar o tempo limite da conexão; atualmente está definido como padrão de 10 segundos. Eu tentei o seguinte no primário

USE [master]
GO
ALTER AVAILABILITY GROUP [xxx]
MODIFY REPLICA ON N'xxx' WITH (SESSION_TIMEOUT = 30)
GO

Como é distribuído, a réplica é o AG subjacente.

Ao executar isso, recebo o erro: Não é possível alterar o grupo de disponibilidade 'xxx', porque ele não existe ou você não tem permissão.

Eu também tentei no encaminhador, recebi o mesmo erro.

Sou administrador de sistemas e o AG distribuído aparece em sys.availability_groups, portanto ele existe e tenho permissão.

Como contornar esse erro e modificar o tempo limite da sessão em uma réplica de um Grupo de Disponibilidade Distribuída?

No Oracle, quero inserir dados em uma tabela em um serviço de banco de dados de outro serviço de banco de dados sem usar o link do banco de dados. Ambos os serviços de banco de dados estão na mesma instância de banco de dados.

insert into dm2m.iotCharge@BFDOCUMENTDATA(documentId, name, descr, quantity, balance_amount, total_amount) 
    select documentID, tariff, Description, quantity, amount, total_amount
    from dm2m.fn_getIotCharges_pkg.fn_getIotCharges(100);

Na dm2m.iotChargetabela de consulta acima está no BF_DocumentDataserviço de banco de dados. E o pacote dm2m.fn_getIotCharges_pkg.fn_getIotCharges(100)está no XMLDBserviço de banco de dados. Ambos os serviços de banco de dados estão na mesma instância de banco de dados. Temos um usuário nomeado dm2mem ambos os serviços de banco de dados.

a definição do pacote e do corpo do pacote é a seguinte,

create or replace PACKAGE dm2m.fn_getIotCharges_pkg
AS
   TYPE tt_fn_getIotCharges_type IS TABLE OF tt_fn_getIotCharges%ROWTYPE;
   FUNCTION fn_getIotCharges(v_documentID IN NUMBER) RETURN tt_fn_getIotCharges_type PIPELINED;
END;

create or replace PACKAGE BODY dm2m.fn_getIotCharges_pkg AS
    
      FUNCTION fn_getIotCharges(v_documentId IN NUMBER) RETURN tt_fn_getIotCharges_type PIPELINED
          AS
                v_temp   SYS_REFCURSOR;
                v_temp_1 tt_fn_getIotCharges%rowtype;
            BEGIN
              OPEN v_temp FOR
                SELECT v_documentId documentID, EVB.PROFILE_NAME AS Tariff,EVB.NAME AS Description,EVB.QUANTITY, EVB.AMOUNT, 
                    ET.AMOUNT AS TOTAL_AMOUNT FROM 
                    dm2m.AR_ITEMS_EVENTS_VFQ_BALANCE EVB
                    INNER JOIN 
                    dm2m.AR_ITEMS_EVENTS_TOTAL ET ON ET.EVENTS_ID = EVB.EVENTS_ID;

            LOOP
                FETCH v_temp INTO v_temp_1;
                EXIT WHEN v_temp%notfound;
                PIPE ROW ( v_temp_1 );
            END LOOP;

            RETURN;
      END fn_getIotCharges;

    END fn_getIotCharges_pkg;

A tabela (tt_fn_getIotCharges) possui as colunas abaixo,

Quando executei a consulta de inserção acima, recebo o erro abaixo.

ORA-22804: operações remotas não permitidas em tabelas de objetos ou colunas de tipo definido pelo usuário

Eu tenho algumas perguntas aqui,

1. Por que a consulta de inserção acima está gerando um erro aqui?
2. Como posso conseguir isso sem usar o link do banco de dados?
3. Usar o link do banco de dados causa algum problema de desempenho?

Tivemos uma falha em nosso SQL AAG, onde nosso banco de dados secundário acabou corrompido. O banco de dados primário está bom, ainda funcionando e não foi afetado de forma alguma.

Agora tento colocar o banco de dados primário de volta no grupo Banco de dados de disponibilidade AAG, seguindo as etapas normais; Limpeza da instância SQL secundária, removendo banco de dados, removendo arquivos, fazendo teste no WFCM, fazendo testes SQL para listener AAG e réplicas. Tudo no verde e pronto para ir. Antes que o assistente Adicionar banco de dados aceite o banco de dados, é necessário um backup completo, então já fiz isso.

Executar o assistente, o status é "Atende aos requisitos" e conectar-se à instância SQL secundária funciona bem, e se você escolher a propagação automática (preferencial) ou o banco de dados completo e backup de log, ele fornecerá o mesmo aviso:

Espaço livre insuficiente para dados e arquivos de log na instância do servidor que hospeda a réplica secundária <réplica/Instância>

É claro que posso clicar em Avançar, mas isso não torna o banco de dados compatível/íntegro na réplica secundária, portanto, não há ganho ao fazer isso.

Posso adicionar mais espaço em disco na réplica para as unidades relevantes, mas quanto espaço é necessário?

O tamanho do arquivo de banco de dados é 2,2 TB O tamanho do arquivo de log é 70 GB Executando o assistente Adicionar banco de dados, digamos que o tamanho é 2,4 TB

No servidor secundário, expandi o disco de dados para 5 TB e o disco de log para 1 TB, mas ainda vejo o aviso

Alguém tem alguma ideia do tamanho que esses discos precisam ter?

No passado, sempre pensei que era necessário um "duplo" ao adicionar/re-adicionar o banco de dados à réplica/servidor secundário, mas isso parece não ser mais o caso, ou o SQL Server lê outros tamanhos de disco, do que o explorador de arquivos

Detalhes: Ambos os servidores executando Windows Server 2019 com atualizações mais recentes, SQL Server 2019, CU 18 (devido a erros em compilações posteriores, não podemos usá-los ainda)

Olá @Sean Como já fiz essa operação algumas vezes nesta configuração, realmente garanti que os locais sejam os mesmos, mas todos os pontos positivos que deveria ter colocado aqui. Nenhum ponto de montagem usado. Espaço livre em disco do servidor primário - Servidor secundário - expandido para tentar executar o assistente AAG.

D   95329                           D   83481
F   261001 - LDF                    F   1651181 - LDF                   
G   196873                          G   204041
U   1054054 - MDF                   U   4619104 - MDF

Aqui estão os locais dos arquivos no primário

DBName  FileType    Location
master  ROWS    D:\Data\MSSQL15.instance_name\MSSQL\DATA\master.mdf
master  LOG     D:\Data\MSSQL15.instance_name\MSSQL\DATA\mastlog.ldf
tempdb  ROWS    G:\TempDB\instance_name\tempdb.mdf
tempdb  LOG     G:\TempDB\instance_name\templog.ldf
tempdb  ROWS    G:\TempDB\instance_name\tempdb_mssql_2.ndf
tempdb  ROWS    G:\TempDB\instance_name\tempdb_mssql_3.ndf
tempdb  ROWS    G:\TempDB\instance_name\tempdb_mssql_4.ndf
model   ROWS    D:\Data\MSSQL15.instance_name\MSSQL\DATA\model.mdf
model   LOG     D:\Data\MSSQL15.instance_name\MSSQL\DATA\modellog.ldf
msdb    ROWS    D:\Data\MSSQL15.instance_name\MSSQL\DATA\MSDBData.mdf
msdb    LOG     D:\Data\MSSQL15.instance_name\MSSQL\DATA\MSDBLog.ldf
UserDB  ROWS    U:\Unik-DB\Userdb.mdf
UserDB  LOG     F:\Logs\Userdb_log.ldf
UserDB  ROWS    U:\Unik-DB\user_ESDH.ndf

E secundário

master  ROWS    D:\Data\MSSQL15.instance_name\MSSQL\DATA\master.mdf
master  LOG     D:\Data\MSSQL15.instance_name\MSSQL\DATA\mastlog.ldf
tempdb  ROWS    G:\TempDB\instance_name\tempdb.mdf
tempdb  LOG     G:\TempDB\instance_name\templog.ldf
tempdb  ROWS    G:\TempDB\instance_name\tempdb_mssql_2.ndf
tempdb  ROWS    G:\TempDB\instance_name\tempdb_mssql_3.ndf
tempdb  ROWS    G:\TempDB\instance_name\tempdb_mssql_4.ndf
model   ROWS    D:\Data\MSSQL15.instance_name\MSSQL\DATA\model.mdf
model   LOG     D:\Data\MSSQL15.instance_name\MSSQL\DATA\modellog.ldf
msdb    ROWS    D:\Data\MSSQL15.instance_name\MSSQL\DATA\MSDBData.mdf
msdb    LOG     D:\Data\MSSQL15.instance_name\MSSQL\DATA\MSDBLog.ldf

Aqui o UserDB está faltando, pois eu o removi/excluí - mas as unidades U e F existem com quantidade adicional de espaço, pois o assistente continua reclamando de falta de espaço.

Agora iniciei uma restauração para a réplica secundária e tentarei ingressar apenas no assistente.

de

00:00:10,137000 ---> 10,137

Ao executar o PostgreSQL 13.12 (ocorre em várias versões do PG11/PG13) usando o SQLAlchemy 1.3, ocasionalmente encontramos problemas em que o aumento da simultaneidade deixa certas transações (e suas transações aninhadas) no estado "Idle in Transaction" com a consulta RELEASE SAVEPOINT ....

Olhando para as consultas em execução atualmente, não está claro por que as transações pararam de avançar. Também observei esse comportamento sem travas suspensas:

Alguma maneira de depurar isso? Essa chamada de API geralmente funciona, com a sessão sendo limpa e não falha de forma consistente. Estamos usando o pool de conexões do SQL Alchemy para gerenciar as conexões - sessões fechadas retornarão a conexão ao pool e emitirão um rollback para limpar a conexão (quando o commit deveria ter confirmado todas as outras instruções).