All perguntas(dba)

Posso estabelecer um túnel SSH usando ssh -L 2222:<RDS-Endpoint>:5432 ec2-user@<EC2-IP> -i ~/.ssh/key.peme depois conectar-me ao meu RDS usandopsql "host=localhost port=2222 user=postgres password=<pw>

Essas mesmas configurações no pgAdmin 4 parecem não funcionar.

• Nome do host na guia de conexão =<RDS-Endpoint>
• Host do túnel =<EC2-IP>
• Porta na guia de conexão = 5432
• Porta na guia túnel SSH = 2222
• Nome de usuário na aba de conexão = postgres
• Nome de usuário na guia do túnel ssh = ec2-user
• Senha na aba de conexão =<pw>
• E arquivo de identidade na guia do túnel ssh = ~/.ssh/key.pem

Depois de tentar por um tempo, o pgAdmin 4 falha com:unable to connect to server: Failed to create the SSH Tunnel. Error: Could not establish session to SSH gateway

cat ~/.pgadmin/pgadmin4.logApenas me dá:

ERROR   pgadmin:    Could not establish session to SSH gateway
Traceback (most recent call last):
  File "/usr/pgadmin4/web/pgadmin/utils/driver/psycopg3/server_manager.py", line 610, in create_ssh_tunnel
    self.tunnel_object.start()
  File "/usr/pgadmin4/venv/lib/python3.10/site-packages/sshtunnel.py", line 1331, in start
    self._raise(BaseSSHTunnelForwarderError,
  File "/usr/pgadmin4/venv/lib/python3.10/site-packages/sshtunnel.py", line 1174, in _raise
    raise exception(reason)
sshtunnel.BaseSSHTunnelForwarderError: Could not establish session to SSH gateway

Estou realmente perdido em como proceder, já que funciona através do terminal. Claramente, não é um problema de grupo de segurança do lado da AWS. Tentei excluir ~/.pgadmine tentar novamente, mas mesmo resultado. Qualquer ajuda será apreciada, obrigado.

Caso isso ajude:

lsb_release -a
No LSB modules are available.
Distributor ID: Pop
Description:    Pop!_OS 22.04 LTS
Release:    22.04
Codename:   jammy

Eu tenho uma consulta que faz uma declaração semelhante em uma coluna que armazena locais de caminho completo de arquivos em um computador.

Exemplo

select * 
from table 
where fullpath like '%hi.exe'

Que nunca parece usar um índice e é muito lento comparado a fazer fullpath = 'value' (obviamente)

Mas minha pergunta é: existe alguma maneira ou ideia de como acelerar os resultados da consulta ou fazer com que ela use índices?

Não vejo a mesma lentidão se o like estiver no lado direito (ex select * from table where fullpath like 'hi%'

EDITAR: Microsoft SQL Server 2017 Standard Edition

Em uma das instâncias do SQL Server não consigo executar nenhuma consulta. Achei que fosse devido a alguma carga pesada, então tento executar sp_execeute whoisactivee obter:

]

Ontem à noite, o DBA realizou a atualização para o SQL Server 2022 CU5 e me disse que há um problema que foi resolvido com o CU7. Então, a atualização para CU7 foi realizada, mas nada mudou.

O DBA me enviou isto:

e depois disso:

mas não tenho certeza do que está acontecendo. O DBA interrompeu o armazenamento de consultas e todas as sessões de eventos estendidas, mas nada mudou. Agora, o DBA acha que o problema é causado por isso , mas deve ser corrigido no CU4 e causa problemas durante a atualização, não depois dela.

O DBA abriu ticket para MS, mas gostaria de saber se alguém sabe o que pode estar causando isso?

Vou anexar os dados de rastreamento. Um pouco mais de informação - temos uma instância do SQL Server 2022 CU5 e outra executando as réplicas com CU7.

O outro DBA acredita que o problema está nas réplicas sempre ativas, então elas são interrompidas - as réplicas travavam constantemente.

Em um banco de dados PostgreSQL, tenho uma tabela com campo numérico, entre outros

Nesse campo são armazenados alguns números naturais que representam o número de ocorrências de algo

assim, aproximadamente

record1....3
record2....5
record3....1
record4....2

Gostaria de criar uma visualização que tenha 3 registros criados a partir do registro1, 5 registros criados a partir do registro2, um registro criado a partir do reocord3 e 2 registros criados a partir do registro4

Isso é possível ?

Como eu conseguiria isso?

Espero que alguém possa me ajudar a esclarecer algumas dúvidas sobre esta questão.

Eu tenho uma tabela com este esquema:

CREATE TABLE IF NOT EXISTS `entities` (
      `id` int(6) unsigned NOT NULL,
      `external_vendor_id` varchar(200) NOT NULL,
      PRIMARY KEY (`id`)
    ) DEFAULT CHARSET=utf8;

Então insiro um registro nesta tabela:

INSERT INTO `entities` 
    (`id`, `external_vendor_id`) 
    VALUES 
    ('1', '64835_122334');

Quando seleciono um registro com a instrução a seguir, esse registro é selecionado, mesmo que o external_vendor_idin da WHEREcláusula não corresponda ao external_vendor_idque foi inserido por meio da INSERTinstrução.

select id, external_vendor_id 
from `entities` 
where `external_vendor_id` = 64835;

Isso está acontecendo no MySQL 5.7.12.

Questões

• Alguém sabe se esse é um resultado esperado? (se sim, por que?)
• Ou isso é um bug nesta versão do MySQL?

Qualquer ajuda será muito apreciada. E uma modificação da consulta para evitar esse resultado será muito útil para entender o que está acontecendo.

Estou aprendendo SQL, então peço desculpas se esta for uma pergunta muito básica. Não consigo descobrir como usar uma cláusula WHERE depois de GROUP BY um campo.

Por exemplo, como eu filtraria os resultados usando uma cláusula WHERE para ver apenas os países onde a contagem de pedidos é maior que 100?

Obrigado

Sou professor e estou questionando uma solução dada pela nossa banca examinadora. A pergunta é mostrada abaixo e gostaria de pedir ajuda para entender por que minha solução não seria aceitável.

Aqui está a pergunta/cenário original:

Aqui está minha solução:

A Solução, dada pela nossa banca examinadora, é mostrada abaixo. Como você verá, eles indicam a necessidade de uma entidade ‘AssignedSeat’. Entendo que eles estão resolvendo um relacionamento muitos-para-muitos aqui, mas pergunto se minha solução (em azul) seria igualmente válida usando apenas essas 2 entidades?

Esquema de Marca Padrão

Estou tendo o Cassandra Community Edition 3.11.13 em execução em uma sub-rede privada na AWS. Estou tentando criar um túnel para o cassandra usando os comandos abaixo.

ssh -vvv -N -L 9042:cass-ip:9042 username@jumphost-ip
ssh -vvv -N -L 9160:cass-ip:9160 username@jumphost-ip

Agora, com o comando nc, posso ver que a conexão está boa.

nc -dvzw50 localhost 9160
Connection to localhost 9160 port [tcp/*] succeeded!

nc -dvzw50 localhost 9042
Connection to localhost 9042 port [tcp/*] succeeded!

Mas quando tento executar o cqlsh localhost, a operação expirou. Abaixo está a saída quando executo o comando ssh tunnel.

debug2: channel 2: chan_shutdown_write: shutdown() failed for fd 7: Transport endpoint is not connected

Qualquer ajuda é apreciada

Após a depuração, restrinja-se à parte de armazenamento. Estou montando o volume como diretório de dados. Se eu desmontá-lo e definir data_directory para o local padrão, ele estará funcionando, mas não com a partição de montagem. Posso ver que todas as permissões na partição de montagem são exatamente iguais ao local padrão.

A instrução SELECT para preencher meu CURSOR do Sql Server pode (frequentemente) retornar zero linhas.

É aconselhável incluí-lo em uma verificação IF para que o CURSOR não seja Declarado, Aberto, Fechado e Desalocado?

Ou o RDMS saberá automaticamente que não deve criar o CURSOR e/ou um IF baseado exatamente no mesmo SELECT inferirá o processamento da consulta duas vezes?

Detalhes do ENV:

1. GKE (cluster do Google Kubernetes)
2. Delator da nuvem do Google. https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/architecture/archSnitchGoogle.html
3. 140 nós com 4 RACKs (4 statefulsets em 4 AZs em uma região)
4. Cada tamanho de nó é 5 TB e o tamanho do cluster é 700 TB.

Procedimento seguido para restaurar o banco de dados: restaurei um tamanho de banco de dados de 450 TB no cassandra K8s da origem ao destino usando a atualização do nodetool copiando sstables. Cada nó possui cerca de 5 a 6 TB de dados. A abordagem que tomei:

1. Crie um novo cluster com o mesmo número de nós, como 140 nós de origem.
2. Criou novos discos a partir de instantâneos de disco de origem (nuvem) e anexou esses discos a novos nós.
3. Tabelas de sistema limpas.
4. C* iniciado como um cluster de destino.
5. Tabelas criadas manualmente que correspondem ao cluster de origem
6. Estábulos copiados de tabelas antigas para tabelas recém-criadas (UUID). 7 Executei a atualização do nodetool

Observação: status do Nodetool mostrando o mesmo tamanho da origem para cada nó, cfstats também correspondendo ao tamanho das tabelas no destino e na origem.

Problema pós-migração:

1. Para reduzir o tamanho do cluster, comecei a descomissionar um dos nós e ele foi concluído em 10 minutos. Esperando ver pelo menos 8 horas com base na manutenção anterior do cluster de origem.

2. Como não se esperava que a desativação fosse executada apenas por 10 minutos, tentei adicionar um novo nó ao cluster, que deveria copiar dados de aproximadamente 5 a 6 TB, mas copiou apenas 2 TB.

3. Como outra verificação, tentei "limpeza do Nodetool" em outro nó que faz parte do cluster de destino e reduziu os dados de 6 TB para 2 TB. A mesma limpeza não reduz quaisquer dados no nó de origem.

4. Após a restauração, todo o cluster é reparado no destino usando a ferramenta Reaper e não há problemas com o reparo, mas o problema é a desativação, a limpeza e a inicialização.