Este não será um cenário Always ON AG, será uma replicação direta. Sei que não preciso de uma nova chave de licenciamento devido ao novo Software Assurance que a Microsoft oferece.

Mas, novamente, não tenho certeza se devo usar a mesma chave de licença da produção ou apenas criar uma Developer Edition.

Por "standby", quero dizer que esse nó não será consultado e só estará lá como standby caso o primário fique inativo.

Estou tentando otimizar uma visualização do PostgreSQL que agrega dados de uma tabela e depois os une a várias outras tabelas com base em condições específicas. No entanto, o plano de execução não está funcionando tão eficientemente quanto eu esperava.

Criei um exemplo muito simplificado para mostrar esse problema específico.

Tabelas de configuração:

CREATE TABLE public.test_text (
    text_id int,
    part text,
    ordr int
);

CREATE INDEX test_text__text_id_erdr ON test_text(text_id, ordr);


CREATE TABLE public.test_section_selection (
    text_id int4,
    selection bool
);
CREATE INDEX test_section_selection__selection_text_id ON test_section_selection(selection, text_id);

Nota importante: não há relação de chave estrangeira entre tabelas, pois esses dados são originalmente preenchidos pelo processo ET de outro banco de dados

Gerar dados sintéticos

WITH RECURSIVE parts_generator AS (
    SELECT 
        1 as text_id,
        0 as ordr,
        md5(random()::text) as part
    UNION ALL
    SELECT 
        CASE WHEN text_id % 10 < ordr THEN text_id + 1 ELSE text_id END as text_id,
        CASE WHEN text_id % 10 >= ordr THEN ordr + 1 ELSE 0 END as ordr,
        md5(random()::text) as part
    FROM parts_generator
)
INSERT INTO public.test_text (text_id, ordr, part)
SELECT text_id, ordr, part FROM parts_generator
LIMIT 50000000;
VACUUM ANALYZE test_text;


INSERT INTO public.test_section_selection (text_id, selection)
SELECT DISTINCT text_id, FALSE FROM test_text;

UPDATE test_section_selection
SET selection = TRUE
WHERE text_id % 7777 = 0;
-- Updated Rows: 1168
VACUUM ANALYZE test_section_selection;

7777 é usado porque é um ajuste muito bom para representar dados de reel. Ele também garante que os dados sejam suficientemente espalhados pela tabela (exigindo io aleatório para ler) e fornece uma boa mistura de seções longas e curtas.

Parte de consulta

A consulta em si se parece com isto: a junção de seleção de seção está lá apenas para hs

EXPLAIN ANALYZE
WITH sections AS (
    SELECT
        tt.text_id,
        STRING_AGG(tt.part, '' ORDER BY tt.ordr) AS section_text
    FROM
        test_text tt
    GROUP BY
        tt.text_id
)
SELECT *
FROM sections
JOIN test_section_selection selection USING (text_id)
WHERE selection.selection = TRUE;

Isso resulta no seguinte plano de execução:

Merge Join  (cost=1.00..2636248.40 rows=55 width=37) (actual time=12.841..14405.822 rows=1168 loops=1)
  Merge Cond: (tt.text_id = selection.text_id)
  ->  GroupAggregate  (cost=0.56..2634847.53 rows=547881 width=36) (actual time=0.023..13924.681 rows=9083537 loops=1)
        Group Key: tt.text_id
        ->  Index Scan using test_text__text_id_erdr on test_text tt  (cost=0.56..2377998.86 rows=50000032 width=41) (actual time=0.016..7867.727 rows=49959451 loops=1)
  ->  Index Only Scan using test_section_selection__selection_text_id on test_section_selection selection  (cost=0.43..28.34 rows=909 width=5) (actual time=0.018..2.307 rows=1168 loops=1)
        Index Cond: (selection = true)
        Heap Fetches: 0
Planning Time: 1.679 ms
Execution Time: 14406.020 ms

Como podemos ver no plano de execução, o postgres estima corretamente o número de linhas que esperamos com selection = TRUE: (cost=0.43..28.34 rows=909 width=5) (actual time=0.018..2.307 rows=1168 loops=1). Mas em vez de aplicar o filtro text_id ao filtro test_text e então fazer uma agregação, ele carrega a tabela inteira, agrega todas as 50 mil linhas e somente então aplica o filtro.

Esta pergunta é bem parecida com esta , mas acho que o Postgres deve ser capaz de fazer isso de forma eficiente, pois se eu executar a consulta com um parâmetro em vez de JOIN, ela será executada corretamente:

EXPLAIN ANALYZE
WITH sections AS (
    SELECT
        tt.text_id,
        STRING_AGG(tt.part, '' ORDER BY tt.ordr) AS section_text
    FROM
        test_text tt
    GROUP BY
        tt.text_id
)
SELECT * FROM sections WHERE text_id IN (7777,15554,23331,...)

No plano de execução, podemos ver que o postgres aplica o filtro à tabela bruta e está usando um índice para isso:

GroupAggregate  (cost=0.56..173269.54 rows=93801 width=36) (actual time=0.040..4.708 rows=989 loops=1)
  Group Key: tt.text_id
  ->  Index Scan using test_text__text_id_erdr on test_text tt  (cost=0.56..171574.90 rows=104424 width=41) (actual time=0.027..3.892 rows=6433 loops=1)
        Index Cond: (text_id = ANY ('{7777,15554,23331,...}'::integer[]))
Planning Time: 0.313 ms
Execution Time: 4.767 ms

Sim, as estatísticas estão erradas. É assim no caso original também. Mas para testar, podemos aumentar as estatísticas com ALTER TABLE test_text ALTER COLUMN text_id SET STATISTICS 10000;e isso resolve o problema de estimativa, mas não afeta o problema central com a ordem de execução

GroupAggregate  (cost=0.56..17846.46 rows=7503 width=36) (actual time=0.036..4.654 rows=989 loops=1)
  Group Key: tt.text_id
  ->  Index Scan using test_text__text_id_erdr on test_text tt  (cost=0.56..17715.13 rows=7507 width=41) (actual time=0.023..3.852 rows=6433 loops=1)
        Index Cond: (text_id = ANY ('{7777,15554,23331,...}'::integer[]))
Planning Time: 0.517 ms
Execution Time: 4.712 ms

Então, o nível de desempenho que espero que seja possível é algo como esta consulta:

EXPLAIN ANALYZE
WITH sections AS (
    SELECT
        tt.text_id,
        STRING_AGG(tt.part, '' ORDER BY tt.ordr) AS section_text
    FROM
        test_text tt
    JOIN test_section_selection USING (text_id)
    WHERE selection = TRUE
    GROUP BY
        tt.text_id
)
SELECT *
FROM sections
JOIN test_section_selection selection USING (text_id)
WHERE selection.selection = TRUE;

Ou qualquer forma desta consulta. O plano de execução é

Merge Join  (cost=4.67..16478.31 rows=1 width=37) (actual time=0.133..7.554 rows=989 loops=1)
  Merge Cond: (tt.text_id = selection.text_id)
  ->  GroupAggregate  (cost=4.23..16437.99 rows=4999 width=36) (actual time=0.124..7.281 rows=989 loops=1)
        Group Key: tt.text_id
        ->  Incremental Sort  (cost=4.23..16350.51 rows=4999 width=41) (actual time=0.118..6.428 rows=6433 loops=1)
              Sort Key: tt.text_id, tt.ordr
              Presorted Key: tt.text_id
              Full-sort Groups: 198  Sort Method: quicksort  Average Memory: 27kB  Peak Memory: 27kB
              ->  Nested Loop  (cost=1.00..16125.56 rows=4999 width=41) (actual time=0.048..5.475 rows=6433 loops=1)
                    ->  Index Only Scan using test_section_selection__selection_text_id on test_section_selection  (cost=0.43..25.89 rows=769 width=4) (actual time=0.028..0.124 rows=989 loops=1)
                          Index Cond: (selection = true)
                          Heap Fetches: 0
                    ->  Index Scan using test_text__text_id_erdr on test_text tt  (cost=0.56..20.86 rows=8 width=41) (actual time=0.004..0.005 rows=7 loops=989)
                          Index Cond: (text_id = test_section_selection.text_id)
  ->  Index Only Scan using test_section_selection__selection_text_id on test_section_selection selection  (cost=0.43..25.89 rows=769 width=5) (actual time=0.007..0.088 rows=989 loops=1)
        Index Cond: (selection = true)
        Heap Fetches: 0
Planning Time: 0.294 ms
Execution Time: 7.638 ms

A execução em menos de 10 ms é ~1500 vezes mais rápida do que a consulta original feita na ordem errada. Então eu agradeceria muito sua ajuda com isso.

Infelizmente, como meu caso original é uma view, não posso alterá-lo facilmente para fazer uma junção dentro de uma subconsulta, pois não conheço o filtro de antemão. Até onde vejo, tenho a opção de executar uma versão modificada de uma consulta do lado do cliente como um CTE ou criar uma função Postgres para aplicar os filtros desde o início, mas não gosto de nenhuma das opções e preferiria fazê-la funcionar no cenário geral do caso.

Testado em postgres 16 e 17

O caso original envolve quatro tabelas com uma boa dúzia de colunas e dois níveis de agregação. Não acredito que eu possa juntar tudo e então agregar. Alterar o esquema também não é uma opção, pois é de uma dependência externa.

Atualizar:

Depois de escrever esta pergunta, comecei a questionar minhas suposições

O caso original envolve quatro tabelas com uma boa dúzia de colunas e dois níveis de agregação. Não acredito que eu possa juntar tudo e então agregar.

Eu nunca tinha testado isso antes, mas fiquei surpreso que ficou muito mais rápido depois que fiz isso. Se você estiver enfrentando um problema semelhante com agregação lenta, não tenha medo de juntar tudo antes da agregação.

Aqui está minha definição da visualização resultante, apenas como exemplo. E não é tão complicado quanto imaginei que seria.

aggreagation_layer_one AS (

    SELECT
        master_data_key,
        table_1.search_column_1,
        table_1.join_column_1,
        table_2.join_column_3,
        table_2.search_column_2,
        table_3.join_column_4,
        table_4."sequence",
        STRING_AGG(table_3.text1, '' ORDER BY table_3.ordr) AS section_text,
        GREATEST(
            ANY_VALUE(table_2.other_column_1),
            MAX(table_3.other_column_1)
        )                                                   AS other_column_1,
        GREATEST(
            ANY_VALUE(table_1.ingest_timestamp),
            ANY_VALUE(table_2.ingest_timestamp),
            ANY_VALUE(table_4.ingest_timestamp),
            MAX(table_3.ingest_timestamp)
        )                                                   AS ingest_timestamp,
        ANY_VALUE(table_1.other_column_2)                   AS other_column_2,
        ANY_VALUE(table_2.other_column_3)                   AS other_column_3,
        ANY_VALUE(table_2.other_column_4)                   AS other_column_4,
        ANY_VALUE(table_2.other_column_5)                   AS other_column_5,
        ANY_VALUE(table_2.other_column_6)                   AS other_column_6,
        ANY_VALUE(table_2.other_column_7)                   AS other_column_7
    FROM
        table_1
    JOIN table_2 USING (master_data_key, join_column_1, join_column_2)
    LEFT JOIN table_3 USING (master_data_key, join_column_3)
    LEFT JOIN table_4 USING (master_data_key, join_column_4)
    GROUP BY
        master_data_key,
        join_column_3,
        join_column_4,
        search_column_1,
        table_1.join_column_1,
        table_2.search_column_2,
        "sequence"

),

aggreagation_layer_two AS (

    SELECT 
        master_data_key                                     AS master_data_key,
        MAX(ingest_timestamp)                               AS revision_timestamp,
        join_column_1,                                      AS id_1,
        join_column_3                                       AS id_2,
        ANY_VALUE(other_column_2)                           AS other_column_2,
        search_column_1                                     AS search_column_1, 
        STRING_AGG(section_text, '\n' ORDER BY "sequence")  AS resulting_text,
        ANY_VALUE(other_column_3)                           AS other_column_3,
        ANY_VALUE(other_column_4)                           AS other_column_4,
        ANY_VALUE(other_column_5)                           AS other_column_5,
        search_column_2                                     AS search_column_2,
        MAX(other_column_1)                                 AS other_column_1,
        ANY_VALUE(other_column_6)                           AS other_column_6,
        ANY_VALUE(other_column_7)                           AS other_column_7
    FROM aggreagation_layer_one
    GROUP BY 
        master_data_key,
        join_column_3,
        search_column_1,
        join_column_1,
        search_column_2

)

SELECT * FROM aggreagation_layer_two

Observe que, se você quiser poder filtrar em uma coluna, essa coluna deve estar na GROUP BYinstrução e não no ANY_VALUE(). Caso contrário, o Postgres não poderá aplicar o filtro aos dados de origem e terá que recorrer à agregação de muito mais dados do que o necessário.

Migrei de um Oracle XE local para o Amazon RDS. Ele está sendo executado em um servidor T3.medium com armazenamento gp3 (200 GB/12000 IOPS).
Quase a cada cinco minutos o alert.log diz assim:

"Thread 1 cannot allocate new log, sequence 10209  
Checkpoint not complete"

3-4 segundos depois, ele registra outra mensagem:

"Thread 1 advanced to log sequence 10209 (LGWR switch),  current SCN: 472780758"

E imediatamente depois disso:

"ARC1 (PID:6427): Archived Log entry 10205 added for B-1189761742.T-1.S-10208 ID 0x7efecf3c1c4d LAD:1 [krse.c:4934]"

Assim:

Lendo sobre a primeira mensagem ("não é possível alocar novo log") parece uma mensagem "ruim". O conselho típico é aumentar o tamanho do arquivo de log de redo. Então adicionei 4 arquivos de log, cada um com 512 Mb. O conselho era remover os arquivos de log antigos (128 Mb cada), mas eles estão quase sempre "ATIVOS", então consegui remover apenas 1. Este é o status atual: ... e ainda recebo a mensagem de erro em alert.log.

O parâmetro archive_lag_target está definido como 300 (5 minutos), então acho que é por isso que ele alterna o arquivo de log a cada cinco minutos. (Não acho que posso alterar essa configuração no RDS.)

Observar as operações de disco na AWS não significa que o disco esteja sob carga muito pesada:

Devo me preocupar com a mensagem "Thread 1 cannot allocate new log..."?
Se sim: qual pode ser o motivo e o que posso fazer a respeito?

Atualização:
Quando emiti um ponto de verificação manual usando:

EXEC rdsadmin.rdsadmin_util.checkpoint;

... ele fez um checkpoint em menos de um segundo e todos os arquivos de log, exceto um, ficaram INATIVOS.
Parece que ele não faz checkpoints automáticos.

Eu estava enfrentando esse problema em uma instância de produção e tentei uma recriação local em pequena escala e consegui.

Eu tenho uma tabela de teste simples

CREATE TABLE `test` (
  `id` int unsigned NOT NULL AUTO_INCREMENT,
  `val` varchar(255) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `index2` (`val`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

Estou usando a versão Mysql 8.0.26com um innodbmecanismo de armazenamento

Preenchi esta tabela com cerca de 4 milhões de linhas aleatórias. Selecionar 5000 linhas desta tabela leva cerca de 50 ms. Em seguida, apaguei todas as linhas usandoDELETE FROM test;

Após excluir todas as linhas, se eu executar SELECT * FROM test LIMIT 5000;essa consulta, ela agora leva mais de 1 minuto para ser executada. Quando a consulta select finalmente termina de ser executada, ela retorna 0 linhas (como esperado).

Antes de prosseguir, quero esclarecer que entendo que executar um optimize tableresolverá o problema, mas estou interessado em entender o que realmente está acontecendo nos bastidores. Aqui estão alguns pensamentos que tive

1. Depois de cerca de uma hora, a consulta se torna instantânea novamente. Isso me leva a acreditar que algum tipo de coleta de lixo ou limpeza está acontecendo por baixo dos panos. Não consigo encontrar nada sobre isso nos documentos.
2. A consulta fica significativamente mais lenta após a exclusão. Como não estou usando nenhuma cláusula não indexada na minha consulta select, ela foi resolvida em cerca de 50 ms antes da exclusão, então, de alguma forma, é 1500x mais lenta após a exclusão.
3. Eu pesquisei o conceito de "registros fantasmas", no entanto, todos os resultados que consigo encontrar estão falando apenas sobre o SQL Server em vez do Mysql, o que me leva a acreditar que o conceito de "registros fantasmas" pode não ser uma coisa no Mysql. Não consigo encontrar nenhuma menção nos documentos do Mysql sobre isso.

Eu tentei o log de consulta lenta e esperava ver um monte de dados escaneados, mesmo que tivessem sido excluídos (registros fantasmas), mas além da duração, não consigo ver nada estranho ou inesperado lá

# Time: 2025-02-11T10:29:24.510606Z
# User@Host: root[root] @  [172.17.0.1]  Id: 20978
# Query_time: 69.680895  Lock_time: 0.000135 Rows_sent: 0  Rows_examined: 0 Thread_id: 20978 Errno: 0 Killed: 0 Bytes_received: 0 Bytes_sent: 130 Read_first: 1 Read_last: 0 Read_key: 1 Read_next: 0 Read_prev: 0 Read_rnd: 0 Read_rnd_next: 0 Sort_merge_passes: 0 Sort_range_count: 0 Sort_rows: 0 Sort_scan_count: 0 Created_tmp_disk_tables: 0 Created_tmp_tables: 0 Start: 2025-02-11T10:28:14.829711Z End: 2025-02-11T10:29:24.510606Z
SET timestamp=1739269694;
select * from test
LIMIT 0, 5000;

Alguém pode explicar em detalhes o que exatamente está acontecendo aqui? Idealmente, as duas coisas que eu adoraria saber, se possível, são:

1. O que está realmente acontecendo?
2. É possível ver/diagnosticar esse problema olhando algumas estatísticas internas do Mysql? Algo como o status/information_schema/performance_schema do mecanismo innodb, por exemplo. Basicamente, algo que eu poderia olhar e dizer que uma tabela está tendo esse problema sem saber que uma exclusão acabou de ser executada

Aqui está a explicação do select -SELECT * FROM test LIMIT 5000

Antes de excluir (rápido 50 ms)

id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
'1', 'SIMPLE', 'test', NULL, 'index', NULL, 'index2', '1022', NULL, '6958223', '100.00', 'Using index'

Após a exclusão (lento 69s) - Corri analyze table testpara atualizar as estatísticas antes de executar novamente a seleção e a explicação

id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows, filtered, Extra
'1', 'SIMPLE', 'test', NULL, 'index', NULL, 'index2', '1022', NULL, '1', '100.00', 'Using index'

Tenha paciência comigo, tenho muita preparação antes de chegar às perguntas.

SQL Server 2016, 13.0.7050.2 (mas isso também aconteceu em compilações anteriores). Acho que é o SQL Enterprise Edition (mas pode ser Standard). O servidor é o Windows 2016(?) com montes de RAM, um monte de núcleos e armazenamento SAN de alto desempenho (desculpe, não tenho todos os detalhes sobre isso, mas provavelmente não importa - não é limitado por recursos).

Banco de dados grande - mais de 1e12 bytes. A maior tabela tem mais de 1e9 linhas. DBCOMPAT é 130 e a estimativa de cardinalidade legada está ON. Este banco de dados foi atualizado há mais de um ano de uma versão anterior do SQL Server, provavelmente 2012 ou 2014.

Um processo ETL é executado - o aplicativo envia linhas para tabelas de preparação (via BulkCopyC#), então invoca um procedimento armazenado para enviar os dados para as tabelas de produção. As tabelas de preparação são limpas (via delete) antes de cada lote ser carregado. O tamanho do lote varia de zero linhas a vários milhões de linhas. Este procedimento armazenado tem quase 20 anos de uso, este banco de dados em particular está se aproximando dos 10 anos e teve bilhões de linhas inseridas e excluídas ao longo dos anos.

Alguns meses atrás, começamos a ter alguns lotes que demoravam muito para carregar - como horas para um lote de apenas algumas centenas de linhas. Os lotes imediatamente anteriores e imediatamente subsequentes tinham milhões de linhas cada e eram carregados normalmente.

Uma conclusão óbvia seria que esses lotes às vezes são executados com um plano ruim, devido a estimativas de cardinalidade, etc. Um rastreamento do SQL Profiler de um desses lotes lentos foi capturado e mostrou que uma consulta que foi executada por mais de uma hora, na verdade, foi executada em 6 segundos, com o restante do tempo sendo gasto na compilação da consulta (de acordo com os dados visíveis no arquivo XML .sqlplan).

Isso está em um ambiente de produção em uma grande instituição, então os experimentos estão em algum lugar entre difícil e impossível de fazer. Depois de muitas semanas de obstáculos, finalmente conseguimos obter uma cópia do banco de dados de produção em um ambiente de não produção onde poderíamos experimentar. Encontramos algumas coisas interessantes:

• Todas as consultas que tiveram tempos de execução ruins tinham uma tabela em comum - ItemStage(usada exatamente como o nome sugere - para preparar itens durante um lote ETL). As consultas em questão não são complexas - simples insert ... from ...com algumas junções (todas são pesquisas de chave em chaves primárias da tabela de destino).
• A tabela não tem chave primária ou índice clusterizado - é uma tabela heap.
• A tabela tem cerca de uma dúzia de relacionamentos de chave estrangeira de saída, mas todos eles são NOCHECK. Nenhuma dessas chaves estrangeiras faz referência a tabelas grandes - talvez 40.000 linhas no máximo.
• update statistics ItemStagecausou 500+ mb/s sustentados de E/S de banco de dados (em uma tabela de algumas 100 linhas). Nós paramos antes que terminasse.
• dbcc checkallocnão encontrei problemas
• dbcc checkcatalognão encontrei problemas
• dbcc checktable(ItemStage)nunca concluído. Paramos depois de mais de 15 minutos. A tabela neste ponto tinha 842 linhas.
• Tentamos adicionar uma chave primária agrupada, mas o tempo desta operação expirou. Não foi possível criar a chave primária.
• Nós descartamos a tabela e a recriamos com a definição que ela tinha o tempo todo - ainda uma pilha.
• O problema não é mais reproduzível: remover e recriar a tabela de preparação aparentemente resolveu o problema.

Então, perguntas...

• Esse problema vai reaparecer mais tarde? Em teoria, as operações que realizamos são um "no-op" lógico (mas, é claro, na prática, excluir e recriar a tabela fez com que sua alocação fosse liberada e então reconstruída, então não é um no-op no nível físico).
• Alguém já viu algo assim?
• Alguma teoria sobre o que realmente estava acontecendo?
• Alguma teoria sobre como evitar que isso aconteça novamente?

Tenho uma tabela com ids e nomes de jogadores. Para cada rodada, a tabela será embaralhada, dividida ao meio e colocada lado a lado. O tratamento de quantidades desiguais de linhas em cada grupo não é o escopo desta questão.

A única coisa que preciso alcançar é (metade superior + metade inferior) OU (tabela a + tabela b) lado a lado. Em detalhes, tabela a como está + ambas as colunas de b sem nenhuma referência uma à outra - linha por linha.

preparei um violino simples:

https://dbfiddle.uk/vkahsaFj

Português: https://dbfiddle.uk/ASM405Co

Algumas referências:

https://stackoverflow.com/questions/7983369/how-do-i-combine-a-mysql-query-and-subquery-when-theres-multiple-rows

O resultado deve ser este:

Tentei todos os tipos de junções, tabelas temporárias, agrupamentos e assim por diante, sem sucesso.

Tenho um banco de dados MariaDB na minha máquina de desenvolvimento e um no servidor do cliente.

Conforme estou desenvolvendo, estou atualizando o esquema do banco de dados (junto com o código). Quando atinjo um marco, quero atualizar os metadados do banco de dados no servidor.

Existe uma maneira de marcar o esquema atual e então produzir um sql para as alterações?

• Estou usando o XAMPP (phpMyAdmin) no meu PC
• Estou usando o Mysql workbench no servidor
• Ambos estão no Windows

Há uma pergunta semelhante aqui , mas

• tem 8 anos
• é para postgresql
• sua resposta é usar uma ferramenta que exponha o banco de dados do servidor para a web. Eu preferiria não fazer isso.

A documentação sobre os benefícios do particionamento lista o seguinte como o primeiro benefício de desempenho do particionamento de tabelas

o otimizador de consultas pode processar consultas de junção equivalente entre duas ou mais tabelas particionadas mais rapidamente quando as colunas de particionamento são as mesmas que as colunas nas quais as tabelas são unidas.

A mesma página fala um pouco mais sobre esse tópico mais adiante , mas não chega a nada além de dizer que unir tabelas particionadas que não são particionadas exatamente da mesma forma não obtém as mesmas otimizações que unir tabelas particionadas equivalentemente. Isso é, claro, irrelevante para o que a seção anterior alegou; qualquer comparação de desempenho entre duas formas de particionar tabelas não tem nada a ver com os benefícios do particionamento quando comparado a não particionar.

Isso me faz perguntar: unir tabelas particionadas equivalentemente é mais rápido do que unir duas tabelas com a mesma chave de índice clusterizado líder? Eu ficaria feliz com uma resposta experimental ou uma que usasse a teoria relevante para chegar a uma conclusão.

Eu li sobre os internos e li muitos white papers e blogs, mas acho que não vi isso abordado em lugar nenhum. Meu entendimento dos internos me leva a concluir que a abordagem particionada deve ser mais lenta do que a abordagem não particionada. Afinal, tudo o que o particionamento realmente faz é colocar outra chave de índice na frente da sua lista de chaves. Meus próprios experimentos descobriram o mesmo.

Tenho uma tabela de quase um milhão de linhas com duas colunas de datatype varbinary. Essas duas colunas armazenam dados binários que fazem o banco de dados crescer para 1 TB.

Como esse banco de dados também é restaurado em outros ambientes de controle de qualidade e em um ambiente de desenvolvimento, agora temos a tarefa de recuperar o máximo de espaço possível para economizar custos.

Após envolver o fornecedor, eles informaram que essas duas colunas podem ser descartadas, pois não estão mais em uso. A escrita do aplicativo para essas duas colunas foi modificada de acordo.

Eu segui duas opções para abordar a situação no meu ambiente de desenvolvimento, mas preciso de ajuda sobre a abordagem correta.

Opção 1

1. Solte as duas colunas binárias
2. Executar DBCC CLEANTABLE- Esta etapa levou quase 24 horas. Tive que pará-la porque não terei tanto tempo no ambiente de produção.
3. Encolher o sistema de arquivos - Estou um pouco relutante em fazer isso por causa da fragmentação.

Fiquei preso no número 2 acima e então tentei a segunda opção abaixo.

Opção 2

1. Solte as duas colunas binárias
2. Crie uma nova tabela e copie os dados usando o SSIS - Esta operação levou quase 12 horas para ser concluída (não terei tanto tempo em produção)
3. Crie um sistema de arquivos diferente e mova todas as tabelas e outros objetos para este novo sistema de arquivos de tabela, exceto a tabela antiga em questão, usando o CREATE INDEX…WITH DROP_EXISTING = ON, ONLINE = ONcomando
4. Solte a tabela antiga no sistema de arquivos primário
5. Encolher o sistema de arquivos primário - Espero que isso encolha mais rápido, pois não há muitos objetos nele.

O item 2 levou quase 12 horas para ser concluído. Alguém conhece uma abordagem melhor para se livrar dessas duas colunas e recuperar o espaço?

O ambiente de produção tem AOAG (Always On), o que significa que preciso estar em recuperação total.

O uso DBCC CLEANTABLEdemorou muito e meu log estava crescendo. Tive que parar para tentar a opção 2. Depois de correr por mais de 24 horas, parei. Demorou muito para finalmente parar. Foi nesse ponto que pensei que DBCC CLEANTABLEnão era uma boa opção para mim.

Notei que para uma tabela (ou visualização ou visualização materializada) no PostgreSQL, há uma linha em pg_depend vinculando a linha pg_class da tabela com a linha pg_namespace do seu esquema.

No entanto, estou pensando se há algum caso em que uma linha em pg_depend pode vincular a linha pg_class a uma linha pg_namespace de um esquema no qual ela não está.

Isso está no contexto de Como posso listar as tabelas em um esquema sem uma varredura sequencial de pg_class?, onde estou tentando encontrar uma consulta eficiente para encontrar as tabelas em um esquema e me pergunto se tenho que lidar com esse caso.