All perguntas(dba)

Via pg_proctab(), posso ver que as conexões da nossa aplicação podem usar até 800 MB de RAM por conexão no postgres. Geralmente até 400 MB. (Atualização para esclarecer após um comentário: essas conexões são de pools de conexões, na maioria das vezes ficam inativas, com consultas entre elas. Os 400 MB são medidos quando a conexão está inativa.)

Gostaria de investigar em que consistem esses 400 MB. Por que 400 MB e não apenas 40 MB, por exemplo? Já olhei os objetos de conexão jdbc no lado da aplicação e não encontrei nada fora do comum.

Meu palpite (maluco) seria que o alto uso de RAM vem do fato de termos muitas partições em nossas tabelas.

O postgres fornece uma maneira de examinar a RAM dos processos de conexões? Estamos no AWS RDS, então o melhor caso seria uma forma em que eu não precisasse de acesso ao servidor.

Alguém pode me ajudar a entender o que está acontecendo aqui?

SELECT
    jsonb_array_length(to_jsonb("gi"."colors_distilled")) "gi_colors_distilled_jsonb_len"

FROM
    "general_inventories" "gi"

WHERE
    "gi_colors_distilled_jsonb_len" > 1;

Falha com:

-- ERROR:  column "gi_colors_distilled_jsonb_len" does not exist
-- LINE 6:     "gi_colors_distilled_jsonb_len" > 1;

Isso funciona (implementando a expressão diretamente na condição), no entanto:

SELECT
    jsonb_array_length(to_jsonb("gi"."colors_distilled")) "gi_colors_distilled_jsonb_len"

FROM
    "general_inventories" "gi"

WHERE
    jsonb_array_length(to_jsonb("gi"."colors_distilled")) > 1;

Parece que devo estar perdendo algo óbvio, mas há tão pouco aí que devo estar errando em uma suposição sobre como/quando os aliases são avaliados.

Gostaria de extrair algumas estatísticas básicas sobre como as tabelas são preenchidas em um determinado esquema do PostgreSQL 16, como o número absoluto e a porcentagem de valores nulos para cada coluna em todas as tabelas desse esquema.

Atualmente, estou buscando/computando esses valores usando Python/psycopg2, mas estou me perguntando se posso armazenar algum tipo de função dentro do próprio PostgreSQL que eu possa chamar sempre que quiser obter essas estatísticas.

Estou tentando me conectar a um banco de dados MySQL remoto para replicação.

O banco de dados está em uma máquina que faz parte de uma rede segura, portanto, depois de abrir a segurança o suficiente para permitir o acesso do meu destino de replicação à porta 3306, eu queria me conectar através da ferramenta CLI para verificar a conexão.

No entanto, não importa como eu tente me conectar, recebo a seguinte resposta:

ERROR 1045 (28000): Access denied for user '{user}'@'{IP}' (using password: NO)

Apesar do que esta mensagem diz, o usuário com quem estou tentando me conectar tem uma senha definida e eu a forneço para a CLI.

Tentei passar a senha de forma interativa, inline e por meio de um arquivo .cnf

Verifiquei se a senha está correta e se espera que o usuário venha do endereço IP da máquina que hospeda o destino da replicação.

Alterei as permissões do usuário para ALL caso houvesse uma permissão negando acesso.

Certifiquei-me de que o servidor de destino da replicação não tenha nenhum usuário que possa fazer login com uma senha, caso isso esteja afetando o comportamento padrão.

Nenhum deles mudou o comportamento e, infelizmente, os únicos recursos que posso encontrar on-line são como fazer login se alguém esqueceu a senha de root ou como definir a senha de root após fazer uma nova instalação.

EDIT: Estes são os comandos que usei para tentar passar a senha para a CLI:

Interactively:

mysql --host={destination IP} --protocol=tcp -u remote_user -p

Inline:

mysql --host={destination IP} --protocol=tcp -u remote_user -p{password}

mysql --host={destination IP} --protocol=tcp --user=remote_user --password={password}

Configuration file:

(Config file {user}@{host}.cnf)
[client]
host={host}
user={user}
password={password}
protocol=tcp

(Command)
mysql --defaults-extra-file=/{user}@{host}.cnf

EDIT 2: A usertabela do banco de dados ao qual pretendo me conectar contém esta linha relevante:

| Host                  | User             | Password          | Select_priv | Insert_priv | Update_priv | Delete_priv | Create_priv | Drop_priv | Reload_priv | Shutdown_priv | Process_priv | File_priv | Grant_priv | References_priv | Index_priv | Alter_priv | Show_db_priv | Super_priv | Create_tmp_table_priv | Lock_tables_priv | Execute_priv | Repl_slave_priv | Repl_client_priv | Create_view_priv | Show_view_priv | Create_routine_priv | Alter_routine_priv | Create_user_priv | Event_priv | Trigger_priv | ssl_type | ssl_cipher | x509_issuer | x509_subject | max_questions | max_updates | max_connections | max_user_connections |
| {-IP address-}        | azure_user       | {-password_hash-} | Y           | Y           | Y           | Y           | Y           | Y         | Y           | Y             | Y            | Y         | N          | Y               | Y          | Y          | Y            | Y          | Y                     | Y                | Y            | Y               | Y                | Y                | Y              | Y                   | Y                  | Y                | Y          | Y            |          |            |             |              |             0 |           0 |               0 |                    0 |

Infelizmente, este banco de dados está executando o MySQL v.5.1 e, portanto, não contém todos os campos solicitados. As informações de identificação foram removidas, mas o IP está correto para a máquina da qual estou tentando acessar o banco de dados, assim como o nome de usuário. O hash da senha foi definido usando ALTER USER 'azure_user'@'{-IP address-}' IDENTIFIED BY '{password}'.

Suponha que eu tenha dois bancos de dados no mesmo servidor RCSI_Yese RSCI_No. No primeiro, o RCSI está habilitado. No segundo, não é. Como o SQL Server decide qual nível de isolamento de transação deve ser usado quando escrevo uma consulta que atinge os dois bancos de dados? Faz diferença em quais bancos de dados eu executo minha consulta?

Com o MariaDB versão 10.1, estamos tentando converter um número inteiro em uma string, por exemplo, varchar(300). Consulte o exemplo de SQL abaixo para obter um exemplo minimizado.

A convert()função pode converter o número inteiro em um tipo de dados de comprimento fixo char(300), mas ocorre um erro reclamando da sintaxe se tentar converter para um tipo de dados de comprimento variável varchar(300).

A cast()função parece ter o mesmo comportamento.

Nossa pergunta:

Por que a função falha na conversão para varchar(300)? Se possível, como fazemos isso funcionar?

select version()
;
-- OK
-- 10.1.12-MariaDB

set @i = cast(1 as int);
-- OK

select @i
;
-- OK
-- 1

select convert(@i, char(300)   ) as col
;
-- OK
-- 1

select convert(@i, varchar(300)) as col
;
-- Error
/* SQL Error [1064] [42000]: (conn=284164) You have an 
error in your SQL syntax; check the manual that corresponds 
to your MariaDB server version for the right syntax to use 
near 'varchar(300)) as col
*/

select cast(@i as char(300)   ) as col
;
-- OK
-- 1

select cast(@i as varchar(300)) as col
;
-- Error
/* SQL Error [1064] [42000]: (conn=284164) You have an 
error in your SQL syntax; check the manual that corresponds 
to your MariaDB server version for the right syntax to use 
near 'varchar(300)) as col
*/

Estou tentando criar um código que conte o número de dígitos em um campo. neste caso são passaportes. Quero ter certeza de que possuem dígitos e caracteres válidos.

select  p.passport_nbr,
        CASE WHEN Number = 0 THEN 1
               ELSE FLOOR(LOG10(ABS(p.passport_nbr))) + 1 AS NDigits

, existe um código diferente que eu possa usar. Eu uso Oracle SQL

Eu tenho um cluster de 2 nós que usa Always on AG, com vários AGs e bancos de dados. Todos os AGs têm as mesmas propriedades:

• Conexões na função principal : permitir todas as conexões
• Secundário legível : não

Eu me pergunto por que o secundário legível está definido como no ? Eu sei que esta é a configuração padrão, mas existe uma prática recomendada em relação a isso? É melhor lê- lo ?

Tivemos alguns problemas com logins e jobs, com falhas de conexão, quando o nó fazia failover para secundário, e me pergunto se isso tem alguma coisa a ver com isso. Tudo funciona bem quando está no nó primário.

Assumi esta posição sem nenhuma informação sobre a configuração e sou novo na função de DBA.

Disseram-me que ao verificar a existência de uma linha em uma tabela, isso funcionará:

EXISTS(SELECT 1 FROM....)

mas que uma maneira "melhor" em relação ao desempenho rápido da consulta seria usar isto:

EXISTS(SELECT TOP(1) NULL FROM......)

Pesquisei on-line por qualquer coisa que faça referência a essa comparação e a única informação que encontrei diz que essa é uma preferência pessoal e que, na verdade, não há ganho de desempenho de um em relação ao outro. Sempre existe o aspecto "caso a caso" em uma pergunta como essa, mas, em geral, há algum ganho de desempenho com o uso da segunda implementação EXISTS()em vez da primeira?

Tentei mover o arquivo de uma pasta local para o OneDrive (nuvem). Então, eu tenho que usar a tarefa Premium File Transfer da KingswaySoft (Free Developer License). Então criei o pacote SSIS e executei-o a partir do código do VisualStudio, ele foi executado com sucesso. Porém, sempre que tento executar o pacote SSIS a partir do trabalho SQLServer, ele mostra a seguinte mensagem de erro.

Alguém pode me dar algumas sugestões para resolver esse problema?

Executado como usuário: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility versão 16.0.1000.6 para 64 bits Copyright (C) 2022 Microsoft. Todos os direitos reservados. Iniciado: 19:39:00 Erro: 2024-03-07 19:39:01.28 Código: 0xC0016016 Fonte: Pacote
Descrição: Falha ao descriptografar o nó XML protegido "TokenFilePassword" com erro 0x8009000B "Chave não válida para uso no estado especificado." . Você pode não estar autorizado a acessar essa informação. Este erro ocorre quando há um erro de criptografia. Verifique se a chave correta está disponível.
Erro final DTExec: A execução do pacote retornou DTSER_SUCCESS (0). Iniciado: 19:39:00 Finalizado: 19:39:02 Decorrido: 1,719 segundos.
O pacote foi executado com sucesso. A etapa foi bem-sucedida.