LetMeSOThat4U's questions

Eu preciso escrever um script que encontre a instalação do Sybase em um sistema, se houver.

Para testar, instalei o ASE 16 no sistema CentOS, mas o instalador aparentemente é baseado em InstallAnywhere (Java).

Este é um dos métodos de instalação aparentemente, não tenho certeza se existem mais maneiras de instalar o ASE como instalar o pacote RPM.

De qualquer forma, existe este SYBASE.shscript para fornecer variáveis ​​de ambiente na instalação do ASE que contém o diretório inicial. Obviamente, é uma situação catch-22: para encontrar esse script, preciso conhecer o diretório inicial do ASE para começar.

Sim, posso fazer check-in nos locais habituais como /sysdbaou /opt/sap. O instalador interativo obviamente permite que o ASE seja instalado em qualquer lugar, é claro, então isso não é bom o suficiente.

Qual é a melhor maneira de encontrá-lo? Estou disposto a fazer coisas como rastrear processos em execução para seus executáveis ​​etc., qualquer coisa que me ajude a encontrar onde o ASE está instalado. Por razões que eu não vou nem encontrá-lo apenas quando ele está funcionando seria bom.

Eu posso executar o script como root ou administrador, sem problemas com isso.

Eu preciso de um grande banco de dados como 10TB-15TB no Postgresql para benchmarking.

Eu criei um banco de dados de amostra menor de ~ 100 GB com pgbenchassim:

pgbench -i -s 7000 --no-vacuum exampledb

No entanto, não observo nenhuma aceleração ao fazer a restauração paralela do customformato (criado com pg_dump -F c ...). Incluindo a restauração do .sqldump também:

time psql -d pgbench7000 < pgbench7000.sql

SET
SET
SET
SET
SET

set_config
------------
(1 row)

SET
SET
SET
SET
SET
SET

CREATE TABLE
ALTER TABLE

CREATE TABLE
ALTER TABLE

CREATE TABLE
ALTER TABLE

CREATE TABLE
ALTER TABLE

COPY 700000000
COPY 7000
COPY 0
COPY 70000

ALTER TABLE
ALTER TABLE
ALTER TABLE

real        32m1.539s
user        3m28.575s
sys         1m40.125s

####################

time pg_restore -d pgbench7000 pgbench7000.custom
real         20m7.504s
user         2m35.556s
sys          0m35.750s

####################

time pg_restore -j 16 -d pgbench7000 pgbench7000.custom

real         20m56.565s
user         2m57.547s
sys          0m40.096s

Eu dei recursos generosos ao servidor Postgresql:

max_connections = 1000              
shared_buffers = 94GB  # 25% of system's memory                
work_mem = 512MB                      
maintenance_work_mem = 12GB
effective_io_concurrency = 500
max_worker_processes = 50     
max_parallel_maintenance_workers = 10   
max_parallel_workers_per_gather = 10   
max_parallel_workers = 50

A caixa é realmente poderosa, possui 374 GB de RAM, 72 vCPUs e armazenamento NAS rápido montado em NFS (é onde reside o diretório de dados PG).

pgbenchcria um banco de dados bastante simples, existem quatro tabelas e apenas uma tabela é grande e ocupa a maior parte do espaço. Isso pode ser o motivo da falta de aceleração?

Alguém sabe dizer onde está o gargalo? Ou é apenas estrutura db?

Ambiente: Centos 7.9 (é o que tenho que usar), Postgres 11 instalado a partir do repositório do projeto.

Nesta resposta ( https://stackoverflow.com/questions/517579/strings-as-primary-keys-in-sql-database ) uma única observação chamou minha atenção:

Lembre-se também de que geralmente há uma diferença muito grande entre um CHAR e um VARCHAR ao fazer comparações de índice

Isso se aplica/ainda se aplica ao Postgres?

Encontrei páginas no Oracle alegando que CHARé mais ou menos um alias para VARCHARe, portanto, o desempenho do índice é o mesmo, mas não encontrei nada definitivo no Postgres.

Eu ouvi o administrador do MySQL afirmar que ALTER na tabela MySQL cria uma cópia intermediária da tabela durante a operação (não sei se o tipo de tabela envolvida deveria ser MyISAM ou InnoDB), o que é um problema ao trabalhar em grandes tabelas.

Isso se aplica a ALTER em tabelas de banco de dados PG e tabelas de banco de dados Oracle, respectivamente?

Quais são os mecanismos de alto nível de ALTER (estou especialmente interessado em PG) que podem afetar o banco de dados para tabelas enormes (um banco de dados Postgres herdado que herdei tem uma tabela que pesa quase 400 GB ..., o banco de dados inteiro tem ~ 1 TB)?

Tenho 2 dúvidas assim:

SELECT c.id FROM component c, base_vee bv
    WHERE
        c.id IN (SELECT component_id FROM registry_row WHERE registry_id = 199) 
        AND
        c.id = bv.component_id
        AND 
        (bv.affidavit IS NULL OR bv.affidavit = '')


SELECT c.id FROM component c, base_vee bv
    WHERE
        c.id IN (SELECT component_id FROM registry_row WHERE registry_id = 199) 
        AND
        c.id = bv.component_id
        AND 
        (bv.affidavit IS NOT NULL AND bv.affidavit != '')

O que preciso obter é uma lista de IDs de componentes com False se bv.affidavitestiver vazio ou True se não estiver vazio.

No momento, obviamente, estou obtendo duas listas de IDs de componentes para cada caso.

Funciona, mas uma consulta como a descrita acima seria melhor.

Eu apoio o Postgres DB 9.1 usando o seguinte comando:

pg_basebackup -h 127.0.0.1 -U replicationuser -D /storage/test_backup -Ft -z -P

No postgresql.conf eu tenho este conjunto:

wal_level = hot_standby              

No entanto, no final da pg_basebackupexecução, recebo este aviso:

AVISO: O arquivamento WAL não está ativado; você deve garantir que todos os segmentos WAL necessários sejam copiados por outros meios para concluir o backup

Eu me preocupo pg_basebackupapenas com o backup dos dados desde o início (posso pagar um pouco de tempo de inatividade durante a noite, então desligo o servidor de aplicativos que está usando esta instância PG como banco de dados de back-end e, em seguida, inicio o backup). Não preciso nem pretendo ter "backup contínuo".

Pergunta: Eu realmente tenho que copiar o WAL para ter backup completo desde o momento de iniciar o pg_basebackupcomando? Ou esse aviso foi projetado estritamente com o objetivo de obter a funcionalidade de "arquivo contínuo"?