All perguntas(dba)

Tenho lido artigo após artigo sobre a diferença entre um backup de banco de dados e um instantâneo e eles simplesmente não fazem sentido, então, por favor, ajude-me a entender

"Um instantâneo é uma imagem do seu sistema/volume em um momento específico ."

"Um backup é uma cópia de todo o seu sistema/volume no momento em que o backup foi realizado ."

1. Tudo é feito em um determinado momento. É assim que a física funciona. A menos que você viva em um buraco negro onde o tempo não existe ou algo assim. Essa frase simplesmente não faz sentido para mim. O backup é feito no momento em que foi feito. Sim. Dã. O que isso significa?
2. Não tenho ideia do que deveria ser uma "imagem" de um banco de dados. Essa analogia não significa nada para mim. Eles significam apenas uma "cópia"? Um backup também é uma cópia do seu banco de dados. Então, novamente, ambos são iguais para mim.

"Um snapshot mantém apenas as alterações do seu banco de dados desde o último snapshot"

4. Mas nunca fiz um instantâneo ainda. Este será o primeiro. Então, qual será o instantâneo? Não há alterações desde o último instantâneo, pois não há último instantâneo. Será apenas... exatamente a mesma coisa que um backup?

"Um instantâneo é rápido de fazer e tem um tamanho pequeno"

5. Novamente, este é meu primeiro instantâneo. Como será magicamente mais rápido e menor que um backup? Ou isso é apenas uma mentira?

Editar: Fontes: (Todos os principais resultados do Google de Backup vs Snapshot)

https://phoenixnap.com/kb/snapshot-vs-backup

Um instantâneo é uma imagem do seu sistema/volume em um momento específico.

Um backup é uma cópia de todo o seu sistema/volume no momento em que o backup foi executado.

https://www.sqlshack.com/understanding-database-snapshots-vs-database-backups-in-sql-server/

Os snapshots do banco de dados são como uma visualização de um banco de dados como ele era em um determinado momento.

Outro uso para backups de instantâneos é que vários instantâneos podem ser criados para um banco de dados e podem ser obtidos em diferentes momentos.

Os backups podem ser criados a qualquer momento. Um snapshot é uma cópia “point-in-time” de um banco de dados.

https://simplebackups.com/blog/backups-vs-snapshots-with-differences-and-examples/#what-is-a-server-or-a-file-backup

Os instantâneos são pequenos e podem ser feitos de forma rápida e fácil, sem causar muito efeito no servidor.

é possível projetar um banco de dados com uma estrutura de árvore clássica (sem nested-set), forçando apenas 2 níveis?

a tabela que pensei que deveria ser:

A terceira linha não deveria ser possível.
Posso conseguir isso sem gatilho ou sem qualquer linguagem de programação?

Parece que o postgres trata a string 'now()'da mesma forma que uma chamada para a now()função.

Por que o postgres permite isso?

select 'now'::timestamp;

ou isto?

select 'now()'::timestamp;

ou mesmo isso?

select '  (  (  ))) now)('::timestamp;

Ele não fornece esse tratamento "uma string é igual a uma função" para outras funções, como clock_timestamp().

violino de banco de dados

Supondo que eu tenha a seguinte consulta PostgreSQL:

SELECT (
        SELECT SUM (t.customers) 
        FILTER (
            WHERE id = 1
            AND date 
            BETWEEN %(start)s AND %(stop)s
        ) + 
        SELECT SUM (t.employees) 
        FILTER (
            WHERE id = 1
            AND date 
            BETWEEN %(start)s AND %(stop)s
        )
FROM table t;

e quero duplicar o resultado para que a tabela retornada tenha três colunas. Devo copiar a subconsulta três vezes, separadas por vírgula? Essa parece uma maneira confusa de fazer isso e não é a ideal, pois a consulta seria realizada três vezes (?). Prefiro dar um alias, digamos eaters, à consulta e escrever uma nova consulta retornando o alias três vezes:

-- The SELECT above AS eaters and then:
SELECT (
    SELECT * FROM eaters, SELECT * FROM eaters, SELECT * FROM eaters
);

Isso deve estar ok também em termos de desempenho, eu acho. Existe alguma outra maneira eficaz de duplicar os ntempos de resultado dentro da consulta principal?

Consulto os dados do restaurante escolar divididos em três partes: resultado total, resultado sem bebidas e apenas as bebidas. O número de consumidores (= clientes + funcionários) será apresentado em cada tabela de resultados e é sempre o mesmo para as três colunas. Obviamente existe o mesmo número de clientes, independentemente da parte considerada. Então preciso do mesmo valor três vezes. É claro que eu poderia substituir os seguintes valores por texto, 'igual ao total' etc., e isso seria entendido. Mas prefiro aprender sobre isso e apresentar os números.

EDIT: usando CTEs eu criaria esse tipo de consulta:

WITH customers AS (
    SELECT SUM (customers)
    FROM table
    WHERE id = 1
    AND date 
    BETWEEN %(start)s AND %(stop)s
), employees AS (
    SELECT SUM (employees)
    FROM table
    WHERE id = 1
    AND date 
    BETWEEN %(start)s AND %(stop)s
);
SELECT (
    (SELECT * FROM customers) + (SELECT * FROM employees)
) AS eaters;
SELECT (
    SELECT * FROM eaters, SELECT * FROM eaters, SELECT * FROM eaters
);

Em nossos computadores o Db2 v11.5.8.0 Linux/x86-64 está instalado. Gostaria de instalar novas correções como atualizações regulares, especialmente para implantar correções de segurança.

Algumas semanas atrás, o novo fixpack 11.5.9.0 foi lançado. Mas agora vejo que o Cumulative Special Build também está listado na página Download do fixpack do Db2 . Analisando detalhadamente a página do CSB , há informações: "Os CSB são cumulativos, cada CSB contém todas as correções entregues no CSB anterior." Se bem entendi, o CSB não deve ser instalado sobre a v11.5.9.0, mas sobre o CSB anterior (se estiver instalado no servidor Db2). Isso está correto?

Qual é o propósito do CSB em primeiro lugar? Para conter apenas correções de segurança e falhas sem novos recursos? Qual é o lançamento do Db2 após a aplicação do CSB?

Obrigado

Temos uma tabela Ecom.McProductToVendorProductCodeMap que possui um PK de vários campos, conforme mostrado:

Em seguida, uma visualização agrupa essa tabela para calcular uma métrica e é agrupada pelos dois primeiros campos dessa PK:

ALTER view ECom.McProductToVendorProductMd5SourceView
as
select ClientAppPrivateLabelId,
       BrandId, 
       convert(nvarchar(32), HashBytes('MD5', 
              string_agg(
                  convert(varchar(max), MaterialNumber + ',' + VendorProductCode + ',' + convert(varchar(30), VendorProductStatusId)),    -- sense any MaterialNumber/VendorProductCode/Status changes
                  ',') within group (order by MaterialNumber)
          ), 2) as Md5,
       Count(*) as Count,
       max(ModifiedUtc) as ModifiedUtc
  from ECom.McProductToVendorProductCodeMap 
 group by ClientAppPrivateLabelId, BrandId

Agora, se selecionarmos na visualização usando esses 2 campos como predicados diretamente, ocorrerá uma busca de índice usando esses 2 campos (19 mil linhas e a dica de ferramenta mostra "Seek Predicate" nos 2 campos):

select * from ECom.McProductToVendorProductMd5SourceView
where ClientAppPrivateLabelId = 101 and BRandId = 3  

No entanto, ao tentar ingressar na mesma visualização usando os mesmos 2 predicados, ele busca apenas ClientAppPrivateLabelId e não BrandId . A dica de junção de loop não ajudou e substituir a junção por uma aplicação cruzada também não ajudou.

select IsNull(convert(smallint, Value), 0) as BrandId 
  into #Brands 
  from string_split('2,3', ',');    
    
select ClientAppPrivateLabelId, b.BrandId, Md5, Count, ModifiedUtc
  from #Brands b
 inner loop join ECom.McProductToVendorProductMd5SourceView m
    on m.BrandId = b.BrandId
   and m.ClientAppPrivateLabelId = 101;

A visualização é simples, exceto pelo cálculo de janelas:

ALTER view ECom.McProductToVendorProductMd5SourceView
as
select ClientAppPrivateLabelId,
       BrandId, 
       convert(nvarchar(32), HashBytes('MD5', 
              string_agg(
                  convert(varchar(max), MaterialNumber + ',' + VendorProductCode + ',' + convert(varchar(30), VendorProductStatusId)),    -- sense any MaterialNumber/VendorProductCode/Status changes
                  ',') within group (order by MaterialNumber)
          ), 2) as Md5,
       Count(*) as Count,
       max(ModifiedUtc) as ModifiedUtc
  from ECom.McProductToVendorProductCodeMap 
 group by ClientAppPrivateLabelId, BrandId

Por que não usa BrandId? A tabela original define BrandId como um smallint não anulável.

Cole o plano: https://www.brentozar.com/pastetheplan/?id=ryZWp86Hp

Atualização nº 1 (05/12/2023)

Converteu a visualização em uma função com valor de tabela (TVF):

alter function ECom.McProductToVendorProductMd5(
   @pBrandId smallint,
   @pClientAppPrivateLabelId smallint
)
returns table as 
return
select ClientAppPrivateLabelId,
       BrandId, 
       convert(nvarchar(32), HashBytes('MD5', 
              string_agg(
                  -- Sense any MaterialNumber/VendorProductCode/Status changes
                  convert(varchar(max), MaterialNumber + ',' + VendorProductCode + ',' + convert(varchar(30), VendorProductStatusId)),    
                  ',') within group (order by MaterialNumber)
          ), 2) as Md5,
       Count(*) as Count,
       max(ModifiedUtc) as ModifiedUtc
  from ECom.McProductToVendorProductCodeMap m
 where m.BrandId = @pBrandId
   and m.ClientAppPrivateLabelId = @pClientAppPrivateLabelId
 group by ClientAppPrivateLabelId, BrandId

e ajustou a consulta para usá-la via aplicação cruzada:

select ClientAppPrivateLabelId, b.BrandId, Md5, Count, ModifiedUtc
  from #Brands b
 cross apply ECom.McProductToVendorProductMd5(b.BrandId, @pCaplId) m;

Mesmo problema: https://www.brentozar.com/pastetheplan/?id=SJnRODaBT

Ele está usando uma junção de mesclagem e não buscando no BrandId

Estou planejando e testando uma nova instalação do SQL Server 2022 para migrar de um banco de dados antigo de 2014. Notei durante os testes de desempenho algumas discrepâncias importantes com algumas consultas volumosas.

Aqui está uma consulta que uso para teste:

INSERT INTO @volume
SELECT     max(SUBSTRING(dbo.CLEACUM.TRADE_DATE, 1, 4)) AS TRADEYEAR,                              
                       sum(CASE [CANCEL] WHEN '1' THEN - cast(abs([TOT_QTY]) as bigint)
                      ELSE cast(abs([TOT_QTY]) as bigint) END) AS TOT_QTY,0
                      
FROM         dbo.CLEACUM LEFT OUTER JOIN
                      dbo.IBM_SECMASTER ON dbo.CLEACUM.TDE_SYMBOL = dbo.IBM_SECMASTER.DCS_CUSIP LEFT OUTER JOIN
                      dbo.VOL_IBM_CODES_IDA ON dbo.IBM_SECMASTER.SEC_CLASS >= dbo.VOL_IBM_CODES_IDA.NUMMIN AND 
                      dbo.IBM_SECMASTER.SEC_CLASS <= dbo.VOL_IBM_CODES_IDA.NUMMAX AND dbo.IBM_SECMASTER.SEC_TYPE >= dbo.VOL_IBM_CODES_IDA.TYPEMIN AND 
                      dbo.IBM_SECMASTER.SEC_TYPE <= dbo.VOL_IBM_CODES_IDA.TYPEMAX AND dbo.VOL_IBM_CODES_IDA.DATEMAX >= ABS(CONVERT(float, DATEDIFF(day, 
                      dbo.CLEACUM.MATURITY_DATE, dbo.CLEACUM.TRADE_DATE) / 365.25)) AND dbo.VOL_IBM_CODES_IDA.DATEMIN <= ABS(CONVERT(float, DATEDIFF(day, 
                      dbo.CLEACUM.MATURITY_DATE, dbo.CLEACUM.TRADE_DATE) / 365.25)) LEFT OUTER JOIN
                      dbo.VOL_CUSIPEquivalence ON SUBSTRING(dbo.CLEACUM.TDE_SYMBOL, 1, 6) = dbo.VOL_CUSIPEquivalence.CUSIP LEFT OUTER JOIN
                      dbo.VOL_MaturityLabels ON dbo.VOL_MaturityLabels.DATEMAX >= ABS(CONVERT(float, DATEDIFF(day, dbo.CLEACUM.MATURITY_DATE, dbo.CLEACUM.TRADE_DATE)
                       / 365.25)) AND dbo.VOL_MaturityLabels.DATEMIN <= ABS(CONVERT(float, DATEDIFF(day, dbo.CLEACUM.MATURITY_DATE, dbo.CLEACUM.TRADE_DATE) / 365.25))
                                     LEFT OUTER JOIN VOL_BusinessDaysPerYear on left(CLEACUM.TRADE_DATE,4)=[VOL_BusinessDaysPerYear].YEAR 
WHERE     (dbo.CLEACUM.ACCT_NO LIKE '10%') AND (dbo.CLEACUM.SEC_TYPE < 300) AND (dbo.CLEACUM.ACCT_NO NOT IN
                          (SELECT     ACCOUNT_NO
                            FROM          dbo.VOL_ExcludedAccounts)) AND (SUBSTRING(dbo.CLEACUM.TRADE_DATE, 1, 4) > datepart(yyyy,getdate())-5)
                                                and (cast(TRADE_DATE as date)<= VOLUME_SAME_PERIOD_DAY)
                                                group by SUBSTRING(dbo.CLEACUM.TRADE_DATE, 1, 4) 

A mesa CLEACUM é bastante grande. Cerca de 17 milhões de linhas em 3,2 GB de espaço em disco. Nada insano, mas ainda assim grande para tal consulta examinar toda a tabela.

Quando executo em 2014, começo do zero ou vivo por dias, a consulta é concluída em no máximo 30 segundos. Quando executo em 2022, leva mais de 50 minutos para ser concluído. A próxima execução será concluída em 30 segundos. O DBCC DROPCLEANBUFFERScomando também fará com que ele fique lento novamente, sem reiniciar ou esperar muito.

Na solução de problemas, posso ver o IO carregando a tabela do disco (lendo ~ 1 MB do arquivo mdf), o que presumo ser o atraso e a execução subsequente usará dados do cache. Eu estou bem com isso, mas...

Como 2014 não está fazendo a mesma coisa? Se eu executar a mesma consulta em 2014 após a reinicialização da máquina, ela ainda será executada em 30 segundos ou menos! Mas em 2022 ele precisará carregá-lo do disco antes de poder usar o cache. Ambos me fornecem as mesmas estatísticas quando medidos:

Table '#B59594BD'. Scan count 0, logical reads 5, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'VOL_MaturityLabels'. Scan count 1, logical reads 192958, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 1746, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 14, logical reads 2872, physical reads 338, read-ahead reads 2534, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'VOL_CUSIPEquivalence'. Scan count 1, logical reads 8, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'VOL_IBM_CODES_IDA'. Scan count 1, logical reads 1736622, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'IBM_SECMASTER'. Scan count 1, logical reads 65, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'VOL_ExcludedAccounts'. Scan count 1, logical reads 195636, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'CLEACUM'. Scan count 1, logical reads 1040096, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'VOL_BusinessDaysPerYear'. Scan count 1, logical reads 1, physical reads 1, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 24008 ms,  elapsed time = 28572 ms.

Table '#AAEDD858'. Scan count 0, logical reads 5, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'VOL_MaturityLabels'. Scan count 1, logical reads 192958, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, page server reads 0, read-ahead reads 1746, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'Workfile'. Scan count 14, logical reads 2872, physical reads 338, page server reads 0, read-ahead reads 2534, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'VOL_CUSIPEquivalence'. Scan count 1, logical reads 8, physical reads 5, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'VOL_IBM_CODES_IDA'. Scan count 1, logical reads 1736622, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'IBM_SECMASTER'. Scan count 1, logical reads 65, physical reads 0, page server reads 0, read-ahead reads 88, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'VOL_ExcludedAccounts'. Scan count 1, logical reads 195636, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'CLEACUM'. Scan count 1, logical reads 1040096, physical reads 17904, page server reads 0, read-ahead reads 305712, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.
Table 'VOL_BusinessDaysPerYear'. Scan count 1, logical reads 1, physical reads 0, page server reads 0, read-ahead reads 0, page server read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob page server reads 0, lob read-ahead reads 0, lob page server read-ahead reads 0.

 SQL Server Execution Times:
   CPU time = 40063 ms,  elapsed time = 3041555 ms.

Para fins de contexto, ambos são executados essencialmente no mesmo hipervisor/armazenamento com ambas as VMs configuradas com recursos idênticos. O servidor original não tinha nenhum tipo de índice e o OLTP não existia em 2014 (nem está habilitado em 2022). O recurso HA está configurado em 2022, mas o banco de dados em questão ainda não foi replicado. Tornei ambos tão idênticos quanto possível para limitar as variáveis.

A única diferença que notei é que 2014 alocará todo o máximo de memória (16 GB) para SQL imediatamente no lançamento, enquanto 2022 parece ser mais dinâmico dependendo das consultas.

Sei que a consulta não é a ideal, mas meu trabalho é apenas migrar tudo para um servidor mais recente.

O que estou perdendo, não entendendo? Como posso alcançar o mesmo nível de desempenho em 2022 que o atual 2014?

Plano de execução 2014 e 2022

As estatísticas de espera da sessão são todas PAGEIOLATCH_SH(minha interpretação está aguardando o IO para que os dados continuem, o que corresponde às estatísticas do IO).

Eu configurei a reserva de memória na VM e reiniciei. Ainda nenhuma mudança, nem mesmo um segundo de diferença.

Estou usando PostgreSQL e tenho uma tabela com números de série. O número de série é assim O número de série é assim zHOb55Klast, quero fazer assim ZhoB55kLAST. Como eu posso fazer isso?

Planejamos migrar os dados (8 PDBS com pelo menos 50 TB de dados) do nosso antigo servidor oracle 19c para o novo (mesma versão) e devemos fazer esta tarefa com mínimo ou nenhum tempo de inatividade . Por esse motivo, não podemos usar o backup simples de desconectar/conectar PDB ou TRANSPORTABLE RMAN como opção, devido ao alto tempo de inatividade.

Estamos procurando as opções disponíveis e a única opção que encontrei com tempo de inatividade muito baixo é Relocating a PDB (do site oficial da Oracle).

Realocação do APO

Alguém conhece outra opção?

Atualização 1- (12h00 - 05.12.23):

• Temos um cluster Oracle Exadata Rac (2 servidores - um online e outro offline e sincroniza dados com dataguard)
• O novo servidor é um servidor Oracle Rac (2 servidores - ambos online - sincronizar dados com ASM)
• Todos os PDBs estão no mesmo CDB
• O novo servidor NÃO está na mesma plataforma.

Atualização 2- (13h00 - 05.12.23):

• O Servidor Exadata é o Oracle Linux e o novo Servidor Redhat e possuem diferentes servidores de armazenamento.

Quero obter o mínimo de user_id para um tenant_id.

mecanismo mysql - innodb

mesa -users(id, tenant_id, is_deleted, creation_date)

pacote(id)

sk(tenant_id, creation_date)

consulta1select min(id) from users where tenant_id = 123;

consulta2 select id from users where tenant_id = 123 order by id limit 1;

Observei que a consulta1 é mais rápida que a consulta2. Além disso, se eu forçar o índice na consulta2, ele usará o filesort além de usar o índice. Quero saber por que a consulta1 é mais rápida e na consulta2 por que o filesort está sendo usado, pois o innodb adiciona pk no final do sk.