All perguntas(dba)

Tenho vários bancos de dados em uma instância do SQL Server hospedada localmente em um servidor, por exemplo, na unidade C.

A intenção é migrar uma pequena parte disso para um provedor de nuvem, a AWS.

Então, digamos que eu tenha 2 bancos de dados na instância. db_junk e db_migrate.

Um agente de TI -- para executar a migração -- quer que eu mova "db_migrate" da unidade C no servidor para a unidade D. Porque eles querem migrar a unidade inteira, e NÃO migrar db_junk (custa, e é lixo).

É possível fazer isso? ... Existe uma maneira mais fácil de fazer isso? Eu acho que talvez haja uma maneira mais fácil de levantar e deslocar um banco de dados específico do SQL Server --- do local para o SQL Server hospedado na AWS (mesma versão) -- sem fazer isso.

Mas, independentemente disso, como isso pode ser alcançado?

EDIT: O objetivo final é migrar o db_migrate da unidade C para a AWS.

No entanto, fui encarregado de implementar uma parte específica --- da unidade C para a unidade D no local, na mesma máquina, na verdade, pois acredito que a próxima pessoa prefere migrar "uma unidade inteira" para a AWS, como em sua área de atuação. ... Isso não é possível com a unidade C porque ela contém inchaço e outros componentes que não devem ser migrados.

No Postgres 16, notei o seguinte comportamento "errado" de uso de índice:

Tenho uma tabela (350000 registros) com uma chave primária composta:

CREATE TABLE IF NOT EXISTS public.mytable
(
    arflgart integer NOT NULL,
    arkeyart character varying(10) COLLATE pg_catalog."default" NOT NULL,
    ...
    CONSTRAINT pk_mytable PRIMARY KEY (arflgart, arkeyart),
    ... 

idx_keyart_flgartHá também um índice BTREE (arkeyart,arflgart)e um índice gist

CREATE INDEX IF NOT EXISTS idx_arkeyart ON public.mytable 
USING gist (arkeyart COLLATE pg_catalog."default" gist_trgm_ops);

Quando fiz consultas em outra tabela com um LEFT JOINto mytablenas duas chaves primárias:

SELECT *
FROM another_table tab2
LEFT JOIN mytable ON tab2.field1=arflgart AND tab2.field2 = arkeyart
WHERE tab2.field3 > 0

A execução da consulta demora muito porque NÃO usa o índice da chave primária ou o idx_keyart_flgart, mas usa o índice gist idx_arkeyart?!?

...
Index Scan using idx_arkeyart on mytable
Index Cond: ((arkeyart)::text = (another_table.field2)::text)
Filter: (arflgart = another_table.field1)
Buffers: shared hit=14,224,232
...

Se eu remover o índice gist, a consulta será imediata.

*** Por que o Postgres não reconhece o índice correto a ser usado?

Este é o plano de execução completo:

"Gather  (cost=1000.71..36112.85 rows=59828 width=56) (actual time=6.490..34806.715 rows=60758 loops=1)"
"  Workers mytable: 3"
"  Workers Launched: 3"
"  Buffers: shared hit=14416778"
"  ->  Nested Loop Left Join  (cost=0.71..29130.05 rows=19299 width=56) (actual time=9.918..34723.521 rows=15190 loops=4)"
"        Buffers: shared hit=14416778"
"        ->  Nested Loop Left Join  (cost=0.42..22483.10 rows=19299 width=49) (actual time=0.408..236.928 rows=15190 loops=4)"
"              Buffers: shared hit=192546"
"              ->  Parallel Seq Scan on ba_salart001 ba_salart  (cost=0.00..12263.89 rows=19299 width=49) (actual time=0.029..80.870 rows=15190 loops=4)"
"                    Filter: (saqtagia <> '0'::numeric)"
"                    Rows Removed by Filter: 108773"
"                    Buffers: shared hit=10258"
"              ->  Index Only Scan using pk_another_table001 on another_table001 another_table  (cost=0.42..0.53 rows=1 width=26) (actual time=0.009..0.009 rows=1 loops=60758)"
"                    Index Cond: ((ulcodkey = (ba_salart.saunilog)::text) AND (field1 = ba_salart.saflgart) AND (field2 = (ba_salart.sakeyart)::text))"
"                    Heap Fetches: 7"
"                    Buffers: shared hit=182288"
"        ->  Index Scan using idx_arkeyart on mytable001 mytable  (cost=0.28..0.33 rows=1 width=22) (actual time=2.268..2.268 rows=1 loops=60758)"
"              Index Cond: ((arkeyart)::text = (another_table.field2)::text)"
"              Filter: (arflgart = another_table.field1)"
"              Buffers: shared hit=14224232"
"Planning:"
"  Buffers: shared hit=890"
"Planning Time: 14.776 ms"
"Execution Time: 34813.134 ms"

Estou executando o PG10 (em breve para mudar para o PG13) e estou tendo problemas de desempenho com uma consulta específica. Também testei no PG13 e obtive resultados semelhantes. A maioria das junções nesta consulta maior são selecionadas para Nested Joins, mas parece que um Hash Join seria mais apropriado para a maioria.

Vejo que os primeiros nós unidos podem estar direcionando as estatísticas de junções posteriores, onde as estimativas de linha são bem baixas. As primeiras junções são as seguintes: https://explain.dalibo.com/plan/b5045eb7cffdf0dh

SELECT * from workflowable_resource where sample_type_id in (SELECT resource_id from resource where name = 'Test Order')

Embora essa consulta menor seja bem rápida, vejo muitos exemplos em que Nested Loop é selecionado incorretamente, onde um Hash Join pode ter um desempenho melhor. (A estimativa de linha é 1, ou próximo de 1, mas as linhas reais são ordens de magnitude maiores)

Quais são algumas técnicas gerais para melhorar estimativas de linha nesses casos? Tentei aumentar default_statistics_target para 10000 e analisar todas as tabelas novamente, mas não vi nenhuma melhoria nas estimativas de linha.

Na consulta maior, no banco de dados ampliado, há um nó tomando todo o tempo. Há uma varredura de índice na tabela, mas ela é realizada em um loop aninhado, pois o lado esquerdo é estimado em 1 linha, mas neste ponto está sendo executado com 178.000 linhas. Parece que erros de estimativas de linhas anteriores estão sendo levados adiante.

Atualmente, estou trabalhando na integração do GridDB com o Oracle 19c para um aplicativo com uso intensivo de dados. O objetivo é armazenar alguns dados de séries temporais no GridDB enquanto realizo processos e consultas ETL complexos no Oracle. Uma das tabelas do Oracle é particionada e contém mais de 500 milhões de registros. O desempenho da consulta é significativamente mais lento do que o esperado, mesmo com indexação e particionamento.

Aqui está uma versão simplificada da consulta que estou executando no Oracle 19c que também extrai dados do GridDB por meio de uma API:

SELECT t1.customer_name, t2.product_name, SUM(t1.amount), gdb.stock_price FROM transactions t1 JOIN products t2 ON t1.product_id = t2.product_id JOIN (SELECT * FROM TABLE(griddb_stock_price_api())) gdb ON t1.product_id = gdb.product_id WHERE t1.transaction_date BETWEEN TO_DATE('2023-01-01', 'YYYY-MM-DD') AND TO_DATE('2023-12-31', 'YYYY-MM-DD') GROUP BY t1.customer_name, t2.product_name, gdb.stock_price;

Detalhes dos dados: transações (Oracle):

customer_name: Nome do cliente que está realizando a transação.

product_id: O ID do produto que está sendo comprado.

valor: O valor da transação.

transaction_date: A data em que a transação foi feita (particionada por data).

produtos (Oracle):Detalhes dos dados:

transações (Oracle):

customer_name : Nome do cliente que está realizando a transação.

product_id: O ID do produto que está sendo comprado.

valor : O valor da transação.

transaction_date: A data em que a transação foi feita (particionada por data).

produtos (Oracle):

product_id: O ID do produto.

product_name: O nome do produto.

griddb_stock_price_api() (GridDB): Esta função de API recupera dados de preços de ações em tempo real do GridDB.

product_id: O ID do produto vinculado ao preço das ações.

stock_price: O preço atual das ações do produto.

product_id: O ID do produto.

product_name: O nome do produto.

griddb_stock_price_api() (GridDB): Esta função de API recupera dados de preços de ações em tempo real do GridDB.

product_id: O ID do produto vinculado ao preço das ações.

stock_price: O preço atual das ações do produto.

• Pelo que li sobre o WAL, é um arquivo somente de acréscimo, onde todas as operações no banco de dados são gravadas antes que as operações sejam realmente executadas nos dados.
• Há também o conceito de "ponto de verificação", que é quando o banco de dados realmente grava os dados no disco a partir da memória e acrescenta uma entrada de ponto de verificação especial no final do WAL.
• Agora, se o banco de dados travar em algum momento, ele poderá ler o WAL a partir da última entrada do ponto de verificação e refazer todas as operações subsequentes.
• Mas como o BD garante que a entrada do WAL no ponto de verificação e a liberação real dos dados no disco aconteçam de forma transacional?
• E se os dados forem liberados, mas o banco de dados travar antes que a entrada do ponto de verificação seja feita no WAL?
• Por outro lado, se o WAL for modificado primeiro, o que acontece se o banco de dados travar após a entrada do ponto de verificação, mas antes que os dados sejam realmente liberados?

Por exemplo, considere o seguinte caso:

• Temos uma tabela fictícia Person(name, age, salary).
• Tem uma entrada John, 25, 100.
• No momento T1, uma nova transação chega UPDATE Person SET salary += 100 WHERE name='John'.
• Suponha que antes do T1, todos os dados foram liberados e a entrada do ponto de verificação foi anexada ao WAL.
• Agora, após essa transação, o BD primeiro anexará o log com a instrução de transação exata UPDATE Person SET salary += 100 WHERE name='John'.
• Agora os dados se tornam John, 25, 200.
• Então, depois de algum tempo, digamos que o banco de dados decida liberar os dados para o disco no momento T2.
• Então, no momento T3 (logo após T2), o BD tenta gravar a entrada do ponto de verificação no WAL.
• Entretanto, antes que pudesse terminar, houve uma queda de energia entre T2 e T3.
• Agora, quando o banco de dados for reiniciado e tentar se recuperar, ele notará que há uma transação após o último ponto de verificação e tentará executá-la:UPDATE Person SET salary += 100 WHERE name='John'
• Mas como a transação já foi executada antes da queda, desta vez o salário assumirá o valor 300, embora devesse ser 200.

Como o banco de dados evita essas atualizações redundantes durante a recuperação?

Adicionando uma chave estrangeira entre esquemas:

ALTER TABLE "editedArticles"
  ADD CONSTRAINT "editedArticles_articles_foreign"
  FOREIGN KEY("originalArticleId") REFERENCES "private".articles("id");

falha com:

ERROR:  42501: permission denied for table articles

mesmo após executar com sucesso:

GRANT USAGE ON SCHEMA private TO postgres;
GRANT SELECT, REFERENCES ON TABLE private."articles" TO postgres;

Parece que tenho o mesmo problema perguntado nesta pergunta sem resposta .

Para registro:

• SELECT current_user;retornapostgres
• \du+ postgresretornaCreate role, Create DB, Replication, Bypass RLS

e finalmente:

postgres=> \dn+ private
                       List of schemas
  Name   |  Owner   |     Access privileges     | Description 
---------+----------+---------------------------+-------------
 private | postgres | postgres=UC/postgres     +| 
         |          | digest=UC/postgres       +| 
         |          | supabase_admin=U/postgres | 
(1 row)

postgres=> \z private.articles
                                     Access privileges
 Schema  |   Name   | Type  |       Access privileges       | Column privileges | Policies 
---------+----------+-------+-------------------------------+-------------------+----------
 private | articles | table | digest=arwdDxt/digest        +|                   | 
         |          |       | supabase_admin=arwdDxt/digest+|                   | 
         |          |       | postgres=r/digest             |                   | 
(1 row)

Note que postgres=r/digestsó tem a rpermissão (read) naquela tabela, não as x(references). Mas por quê? Eu executei GRANT REFERENCES(como mencionado acima).

Analisando a documentação da Microsoft para aplicar um patch SQL em um AG .

é feita referência à redução/minimização do tempo de inatividade e perda de dados e não à prevenção total do tempo de inatividade. Posso esperar conseguir aplicar um patch sem nenhum tempo de inatividade?

Por favor, eu apreciaria sua opinião.

Obrigado

Vou lhe dar algum contexto e então fazer minha pergunta. Estou construindo um modelo de banco de dados para um aplicativo de e-commerce. Este aplicativo precisa se comunicar com outro sistema (sistema ERP) para obter produtos, marcas, categorias e outras informações que sejam relevantes para o e-commerce. Atualmente, o modelo de banco de dados de e-commerce é projetado de forma idêntica aos tipos de dados que o sistema externo oferece.

Vou compartilhar com vocês algumas das tabelas de comércio eletrônico:

aikon_artigo

CREATE TABLE `aikon_articulo` (
  `aik_ar_codigo` varchar(24) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ar_publicarweb` varchar(1) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `aik_ar_descri` varchar(200) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ar_memo` varchar(4000) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ar_alto` double NOT NULL,
  `aik_ar_ancho` double NOT NULL,
  `aik_ar_profundo` double NOT NULL,
  `aik_ar_color` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ar_peso` double NOT NULL,
  `aik_ar_descria` varchar(200) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ar_mesesgarantia` double NOT NULL,
  `aik_ar_cosnet` decimal(15,2) NOT NULL,
  `aik_ap_utilidad` decimal(6,2) NOT NULL,
  `aik_ap_impuesto_interno` decimal(6,2) NOT NULL,
  `aik_iva_porcen` decimal(6,2) NOT NULL,
  `aik_stock_total` smallint unsigned NOT NULL,
  `aik_ap_precio_iva` decimal(15,2) NOT NULL,
  `aik_ar_fechamodif` bigint unsigned DEFAULT NULL,
  `aik_ar_fecha_alta` bigint unsigned DEFAULT NULL,
  `aik_fa_codigo` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ma_codigo` varchar(4) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_re1_codigo` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_re2_codigo` varchar(5) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_esa_codigo` varchar(2) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`aik_ar_codigo`),
  KEY `aikon_articulo_aik_fa_codigo_fkey` (`aik_fa_codigo`),
  KEY `aikon_articulo_aik_ma_codigo_fkey` (`aik_ma_codigo`),
  KEY `aikon_articulo_aik_re1_codigo_fkey` (`aik_re1_codigo`),
  KEY `aikon_articulo_aik_re2_codigo_fkey` (`aik_re2_codigo`),
  KEY `aikon_articulo_aik_esa_codigo_fkey` (`aik_esa_codigo`),
  CONSTRAINT `aikon_articulo_aik_esa_codigo_fkey` FOREIGN KEY (`aik_esa_codigo`) REFERENCES `aikon_estado_articulo` (`aik_esa_codigo`) ON DELETE RESTRICT ON UPDATE CASCADE,
  CONSTRAINT `aikon_articulo_aik_fa_codigo_fkey` FOREIGN KEY (`aik_fa_codigo`) REFERENCES `aikon_familia` (`aik_fa_codigo`) ON DELETE RESTRICT ON UPDATE CASCADE,
  CONSTRAINT `aikon_articulo_aik_ma_codigo_fkey` FOREIGN KEY (`aik_ma_codigo`) REFERENCES `aikon_marca` (`aik_ma_codigo`) ON DELETE RESTRICT ON UPDATE CASCADE,
  CONSTRAINT `aikon_articulo_aik_re1_codigo_fkey` FOREIGN KEY (`aik_re1_codigo`) REFERENCES `aikon_referencia01` (`aik_re1_codigo`) ON DELETE RESTRICT ON UPDATE CASCADE,
  CONSTRAINT `aikon_articulo_aik_re2_codigo_fkey` FOREIGN KEY (`aik_re2_codigo`) REFERENCES `aikon_referencia02` (`aik_re2_codigo`) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

aikon_estado_artigo

CREATE TABLE `aikon_estado_articulo` (
  `aik_esa_codigo` varchar(2) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_esa_descri` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`aik_esa_codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

aikon_marca

CREATE TABLE `aikon_marca` (
  `aik_ma_codigo` varchar(4) COLLATE utf8mb4_unicode_ci NOT NULL,
  `aik_ma_descri` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
  PRIMARY KEY (`aik_ma_codigo`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Só quero que você preste atenção especial aos tipos de dados que a chave primária tem em cada tabela. Eles são todos strings com comprimentos diferentes. Ou seja, o sistema externo tem padrões nos valores das chaves primárias, dependendo da tabela.

Além disso, ouvi dizer que os melhores tipos de dados para chaves primárias são unsigned bigint. Estou preocupado se manter tipos de dados de string para cada chave primária é uma boa ideia ou não.

Devo deixar os tipos de dados como estão ou devo alterar os tipos de dados da chave primária para unsigned bigint?

Na verdade, não sei o quanto esse banco de dados pode crescer, mas não quero ter surpresas no futuro, como não poder INSERTporque ficamos sem valores de id. Este banco de dados está atualmente em fase de desenvolvimento, então, não há problema em alterar os esquemas.

Existe alguma versão do DSE 6.x que suporte o formato C* 4.x sstable (-nb-)? Quero carregar dados do apache C* 4.x usando sstableloader no DSE 6.x. Qual seria o melhor caminho de atualização recomendado (compatível) para importar sstables C* 4.x no DSE 6.x?

• DSE 6.x - protocolo DSE_V2 - (formato sstable -bb-)
• C* 4.x - protocolo v5 - (formato sstable -nb-)

Usando Apache Cassandra 4.x sstableloader -> O cliente não consegue negociar um protocolo mesmo após adicionar application.conf( v4) EXTRA_CLASSPATHconforme doc . O erro permanece o mesmo independentemente de qualquer driver compatível fornecido:

com.datastax.driver.core.exceptions.UnsupportedProtocolVersionException: \
  [/10.x.x.x:9042] Host does not support protocol version V6 but V5. 

Usando DSE 6.8.x sstableloader -> Importação de -nb-sstables de 4.x concluída sem erros, mas não há arquivos no caminho /data do cluster DSE e SELECT * from TABLEretorna 0 linhas. Usar nodetool refreshand nodetool importnão parece ajudar.

Não há informações claras sobre a compatibilidade do C* 4.x com o DSE na documentação do Datastax. Quaisquer links ou informações sobre isso seriam úteis. Obrigado!

Estou usando o Microsoft SQL Server Profiler para capturar dados de rastreamento de produção para reprodução em um servidor de desenvolvimento para testar alterações de indexação. Capturar o rastreamento não é problema: estou usando um modelo de rastreamento "TSQL_Replay" com o evento "Showplan XML Statistics Profile" adicionado. Na captura original, posso ver o plano de execução nos dados de rastreamento.

O problema é quando eu reproduzo esses dados de rastreamento no servidor de desenvolvimento. Não vejo nenhuma opção para configurar as opções de rastreamento de reprodução. Posso verificar "Exibir tempo de execução" e obter tempos para consultas individuais, mas não consigo ver os planos de execução que são executados quando o rastreamento é reproduzido. Isso é crítico para determinar como os novos índices estão sendo usados. Tentei executar um rastreamento paralelo separado no servidor de desenvolvimento enquanto reproduzo o rastreamento original, mas os replays não parecem ser captados.

Alguma dica sobre como medir resultados ao reproduzir um rastreamento?

Tentei usar o RML Utilities e o Database Experimentation Assistant, mas não descobri como fazer nenhum deles funcionar para esse caso de uso.