All perguntas(dba)

Estou construindo um SaaS que em um banco de dados terei uma meta grande (algo em torno de 50 milhões de linhas), e essa tabela servirá informações para todos os clientes do sistema.

Mas, esse SaaS será um software multilocatário/multibanco de dados, onde quando um cliente se cadastrar, provisionaremos seu próprio banco de dados para acessar E criaremos uma tabela estrangeira para aquela tabela grande fora do banco de dados...

Pergunta 1: Essa é a melhor abordagem? Criar uma tabela externa para cada cliente pode resultar em um grande uso de armazenamento do servidor?

Pergunta 2: A tabela original possui outros índices do tipo 10 (a maioria deles btree), e com a tabela estrangeira para os clientes, esses índices funcionarão corretamente?

Eu tenho uma tabela com dados como abaixo:

| ID(pk) | name | count |
|--------|------|-------|
| id1    | xyz  |    98 |
| id2    | ptr  |     5 |
| id3    | xyz  |     2 |
| id4    | de   |     1 |
| id5    | ptr  |     1 |

Quero primeiro ter a linha com contagem máxima e depois todas as linhas com o mesmo nome classificadas por contagem. Depois dessa próxima contagem máxima e todas as contagens com o mesmo nome. Algo como abaixo:

| ID(pk) | name | count |
|--------|------|-------|
| id1    | xyz  |    98 |
| id3    | xyz  |     2 |
| id2    | ptr  |     5 |
| id5    | ptr  |     1 |
| id4    | de   |     1 |

Algo assim é possível no Postgres?

Estou configurando a replicação transacional em meu servidor 2008R2 para o servidor de distribuição 2012 para o servidor Assinante 2012. Todos os três servidores estão em modo de recuperação COMPLETO. O backup do log é feito a cada 15 minutos e o backup completo é feito diariamente, todos os dias, em todos os três bancos de dados do servidor usados ​​na replicação. Queremos usar o assinante como servidor de relatórios. O Publisher é nosso principal banco de dados OLTP.

Como posso receber um alerta antes que o espaço t-log do meu editor esteja cheio devido a qualquer problema na replicação. Não quero que meu editor caia de forma alguma. Os t-logs são apoiados a cada 15 minutos no editor. Isso significaria que todos os VLFs que são lidos ativamente pelo leitor de log podem ser copiados quando o backup do log for feito? quais alertas devo usar para me informar que o espaço de log está ficando cheio no editor? Existe algum script que também possa interromper o agente de replicação/leitor de log quando o espaço de log estiver ficando perigosamente grande no editor?

Posso remover a replicação e restabelecer (com um novo instantâneo) quando a replicação estiver causando problemas e criando logs no meu editor. Mas não quero esperar que essa situação aconteça (o espaço de log está cheio no editor) e quero tomar medidas apenas antes - como remover a replicação antes apenas quando o espaço de log atingir uma determinada porcentagem. Como eu posso fazer isso?

Além disso, qual deveria ser minha estratégia para interromper e remover a replicação? Seguirei a documentação da Microsoft para remover a replicação, mas não estou claro se devo interromper o agente Log Reader e o agente de distribuição antes de remover a replicação.

Acabei de começar a estudar Oracle, preciso restaurar o backup do banco de dados. O arquivo de log diz que foi feito no Oracle Database 10g Enterprise. Eu tenho o Oracle XE 18, é possível fazer isso para a versão XE usando RMAN ou alguma outra ferramenta? Abaixo lista de arquivos que tenho em arquivo.

>   configFFH.ora
>   ffdacs-nfs-backup-2024-06-17.tar.gz 
>   initFFH.ora
>   ffhbackup
    >   arch_1_56543.arc
    >   arch_1_56544.arc
    >   arch_1_56545.arc
    >   arch_1_56546.arc
    >   arch_1_56547.arc
    >   arch_1_56548.arc
    >   arch_1_56549.arc
    >   arch_1_56550.arc
    >   arch_1_56551.arc
    >   arch_1_56552.arc
    >   arch_1_56553.arc
    >   control01.ctl
    >   dcomm.cache
    >   ffhactivity01.dbf
    >   ffhactivity_idx01.dbf
    >   ffhactivity_idx02.dbf
    >   ffhbackup2.log
    >   ffhconfig01.dbf
    >   ffhconfig02.dbf
    >   ffhconfig03.dbf
    >   ffhconfig04.dbf
    >   ffhdetail01.dbf
    >   ffhdetail_idx01.dbf
    >   ffhsummary01.dbf
    >   ffhsummary_idx01.dbf
    >   FFH_backup.log
    >   fsdump
    >   hot_db_files.lst
    >   sysaux01.dbf
    >   sysaux02.dbf
    >   system01.dbf
    >   temp01.dbf
    >   undo.dbf

Estou tentando atualizar meu cluster Cassandra de 3 nós da versão 3.11.13 para 4.1.5.

Depois de iniciar o nó de atualização, recebo este erro:

ERROR [main] 2024-06-20 08:48:23,708 CassandraDaemon.java:915 - Exception encountered during startup
java.lang.AssertionError: null
        at org.apache.cassandra.schema.TableMetadata$CompactTableMetadata.getCompactValueColumn(TableMetadata.java:1515)
        at org.apache.cassandra.schema.TableMetadata$CompactTableMetadata.<init>(TableMetadata.java:1350)
        at org.apache.cassandra.schema.TableMetadata$Builder.build(TableMetadata.java:747)
        at org.apache.cassandra.schema.SchemaKeyspace.fetchTable(SchemaKeyspace.java:943)
        at org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:898)
        at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:857)
        at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:848)
        at org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:836)
        at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:132)
        at org.apache.cassandra.schema.Schema.loadFromDisk(Schema.java:121)
        at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:285)
        at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:759)
        at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:893)

Encontrei este problema. A atualização do Cassandra 3.11.8 para 4.1.0 retorna "AssertionError: null" na inicialização ao carregar o esquema e o conselho era remover o COMPACT STORAGE.

Existe apenas um ARMAZENAMENTO COMPACTO no keyspace do sistema:

DESCRIBE TABLE system.hints

CREATE TABLE system.hints (
    target_id uuid,
    hint_id timeuuid,
    message_version int,
    mutation blob,
    PRIMARY KEY (target_id, hint_id, message_version)
) WITH COMPACT STORAGE
    AND CLUSTERING ORDER BY (hint_id ASC, message_version ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = '*DEPRECATED* hints awaiting delivery'
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'enabled': 'false', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.0
    AND default_time_to_live = 0
    AND gc_grace_seconds = 0
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 3600000
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

Infelizmente não posso abandoná-lo:

cqlsh> ALTER TABLE system.hints DROP COMPACT STORAGE;
Unauthorized: Error from server: code=2100 [Unauthorized] message="system keyspace is not user-modifiable."

Não consigo nem fazer o downgrade do nó para 3.11.13:

ERROR [main] 2024-06-20 08:38:07,157 CassandraDaemon.java:803 - Detected unreadable sstables /var/lib/cassandra/data/system/local/nb-244-big-Statistics.db,/var/lib/cassandra/data/system/local/nb-244-big-Data.db,/var/lib/cassandra/data/system/local/nb-244-big-Summary.db,/var/
lib/cassandra/data/system/local/nb-244-big-CompressionInfo.db,/var/lib/cassandra/data/system/local/nb-244-big-Index.db,/var/lib/cassandra/data/system/local/nb-244-big-Filter.db, please check NEWS.txt and ensure that you have upgraded through all required intermediate version
s, running upgradesstables

A tabela system.hints não está presente em meus outros clusters cassandra, onde a atualização ocorreu sem problemas.

Alguém tem alguma idéia de como sair dessa situação?

Atualizei meu postgres da versão 13.5 para 16.2 (e o RHEL de 7.5 para 8.9). O problema é que o python não foi atualizado.

Criei o procedimento pyver():

CREATE OR REPLACE FUNCTION pyver ()
RETURNS TEXT
AS $$
    import sys
    pyversion = sys.version
    return pyversion
$$ LANGUAGE 'plpython3u'; 

Para mostrar a versão python usada pelo Postgres.

Quando executo no Python 13.5, obtenho este resultado:

psql (13.5)
Type "help" for help.

postgres@database # select pyver();
                  pyver
-----------------------------------------
 3.6.8 (default, Aug 13 2020, 07:36:02) +
 [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
(1 řádka)

postgres@database #

E quando executo no banco de dados atualizado, obtenho este resultado:

psql (16.2)
Type "help" for help.

database=# select pyver();
                  pyver
-----------------------------------------
 3.6.8 (default, Jan  5 2024, 09:14:44) +
 [GCC 8.5.0 20210514 (Red Hat 8.5.0-20)]
(1 row)

database=#

No novo RedHat está o Python 3.9.18 instalado.

Como faço para que o postgres use uma versão mais recente do python?

A atualização foi feita desta forma:

• foi instalado novo servidor com RedHat 8.9 (Python 3.9)
• foi instalado os binários do Postgres (versão 13.5) e criado o usuário postgres
• então foi conectado o disco com bancos de dados Postgres (versão 13.5) do servidor antigo
• o banco de dados foi iniciado no novo servidor
• o próximo passo foi a instalação do Postgres 16.2
• então foi iniciado o upgrade dos bancos de dados para a nova versão do Postgres através deste comando:

time /usr/pgsql-16/bin/pg_upgrade --jobs=16 -d /postgres/pgsql/database/data13 -D /postgres/pgsql/database/data16 -b /usr/pgsql-13/bin/ -B /usr/pgsql-16/bin/ --link

• após a atualização executa o banco de dados na nova versão

E agora encontramos o problema com Python.

O banco de dados principal tem tamanho de 70 TB.

Obrigado Michal

Temos 9 servidores físicos, cada servidor possui 4 discos físicos, o que significa que temos um total de 36 discos físicos, cada um relacionado a um nó Cassandra.

Gostaríamos de ter uma replicação de 3 em todo o cluster, de uma forma que nos permitisse perder um servidor (4 discos físicos) sem perder dados.

Estávamos pensando em fazer três racks diferentes, cada rack com 3 de nossos servidores físicos. Meu entendimento é que, se eu tiver um keyspace com RF=3, um conjunto de dados deverá ser replicado 3 vezes no cluster.

Minha pergunta é: esses dados serão replicados 3 vezes dentro de cada rack ou serão replicados uma vez em cada rack (tendo 3 racks)? o que devo fazer/como devo configurar meu cluster e meu keyspace para que os dados sejam replicados exatamente uma vez para cada um de nossos três racks?

Adicionei este SP ao meu banco de dados e ele retorna resultados úteis. A parte que não tenho certeza são os números de uso. Sou novo no Azure SQL, mas os veteranos me disseram que o servidor nunca é reiniciado, então estou me perguntando por que o número de usos é tão baixo. Os números parecem cobrir apenas as últimas 24 horas, no máximo.

Alguém pode me explicar por que isso aconteceria? Eu adoraria obter os números de uso durante um período muito mais longo para ter uma ideia realmente completa de quais índices causam maior impacto.

Estou compactando tabelas particionadas.

antes das tabelas particionadas, tentei tabelas normais com as seguintes etapas:

DBMS_REDEFINITION.START_REDEF_TABLE(
    uname => 'USER',
    orig_table => 'ORIGINAL',
    int_table => 'INTERIM'
);




BEGIN
   DBMS_REDEFINITION.CAN_REDEF_TABLE('USER','ORIGINAL', DBMS_REDEFINITION.CONS_USE_ROWID);
END;
/



BEGIN
   DBMS_REDEFINITION.START_REDEF_TABLE(
      uname => 'USER',
      orig_table => 'ORIGINAL',
      int_table => 'INTERIM',
      options_flag => DBMS_REDEFINITION.CONS_USE_ROWID);
END;
/



DECLARE
   error_count pls_integer := 0;
BEGIN
   DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS('USER', 'ORIGINAL', 'INTERIM', dbms_redefinition.cons_orig_params, TRUE,TRUE,TRUE,FALSE, error_count);
   DBMS_OUTPUT.PUT_LINE('errors := ' || TO_CHAR(error_count));
END;
/


DECLARE
   error_count pls_integer := 0;
BEGIN
DBMS_REDEFINITION.COPY_TABLE_DEPENDENTS(
    uname => 'USER',
    orig_table => 'ORIGINAL',
    int_table => 'INTERIM',
    copy_indexes => DBMS_REDEFINITION.CONS_ORIG_PARAMS,
    copy_triggers => TRUE,
    copy_constraints => TRUE,
    copy_privileges => TRUE,
    ignore_errors => FALSE,
    num_errors => 0
);
END;
/

ALTER TABLE ORIGINAL MOVE ROW STORE COMPRESS ADVANCED;

Entretanto, para tabelas particionadas, isso não é possível.

alguém pode me dizer o procedimento para compactar tabelas particionadas no Oracle 19c ?

Tenho que tomar uma decisão (no trabalho) para escolher qual opção é mais viável usando o SQL Server 2019:

Opção 1: Backups completos enviados uma vez por semana e backups diferenciais enviados entre backups semanais. Opção 2: Backup completo enviado uma vez. Backups de log de transações enviados a cada 15 minutos. Backups completos adicionais e backs diferenciais enviados conforme necessário mediante solicitação.

Estou inclinado para a Opção 1 porque gerenciar logs de transações que acontecem a cada 15 minutos parece ser muito difícil de gerenciar.

Qual método faria mais sentido?

São pequenos dados provenientes de um terceiro fornecedor que armazenamos no SQL Server 2019 em VM. Após a ingestão dos dados, não haverá nada parecido com a distribuição para terceiros a partir do nosso SSMS. Não tenho certeza sobre "Recuperação pontual" nem RPO ou RTO. Ainda não entrei na parte do modo de recuperação completo ou simplesmente.