All perguntas(dba)

Tenho uma consulta que roda como parte de uma ferramenta na qual trabalho. Ela tem rodado bem há anos, mas recentemente (não sei exatamente quando, mas provavelmente foi na semana passada) está falhando com um erro de sintaxe.

A pergunta é:

SELECT sys.fn_PhysLocFormatter(%%physloc%%) FROM dbo.Categories

e o erro é:

Alguém tem ideia do porquê isso está gerando um erro de sintaxe, quando meus colegas não têm esse problema ao executar a mesma consulta, alguns dos quais estão usando a mesma versão do SQL Server?

O servidor em que ele está sendo executado é o SQL Server 2019 Developer Edition. Era o RTM, mas ao tentar resolver esse erro, atualizei-o para o CU32 mais recente. O erro ainda acontece. Tentei na mesma versão do SQL Server em um contêiner e não deu erro.

Não é a mesma instância ou conta, mas a conta é um adminusuário em ambos. O que é mais confuso é que estava funcionando na minha máquina algumas semanas atrás e agora não funciona mais.

Correndo:

SELECT @@VERSION;

SELECT [compatibility_level] 
FROM sys.databases WHERE database_id = DB_ID();

SELECT [object_id], [type_desc] 
FROM sys.all_objects 
WHERE [object_id] = OBJECT_ID(N'sys.fn_PhysLocFormatter');

No servidor onde não está funcionando, a saída é:

Em um servidor onde está funcionando, a saída é:

Não tenho outro servidor SQL 2019 disponível além de um contêiner, então sei que um é Windows e o outro é Linux.

Digamos que temos a tabela abaixo conosco:

 id |     entry_time      |  state  
----+---------------------+---------
 d1 | 2024-09-20 12:01:01 | Open
 d1 | 2024-09-20 12:01:20 | EnRoute
 d1 | 2024-09-20 12:02:40 | OnTrip
 d1 | 2024-09-20 12:04:10 | Open

E queremos uma visualização final que ficará como abaixo (saída esperada):

| id | start_minute        | open_time | enroute_time | ontrip_time |
|----|---------------------|-----------|--------------|-------------|
| d1 | 2024-09-20 12:01:00 | 19        | 40           | 0           |
| d1 | 2024-09-20 12:02:00 | 0         | 40           | 20          |
| d1 | 2024-09-20 12:03:00 | 0         | 0            | 60          |
| d1 | 2024-09-20 12:04:00 | 50        | 0            | 10          |

Para calcular a visualização (para a primeira linha)

• open_time é 19 porque o driver permaneceu em estado aberto de 12:01:01 a 12:01:20
• enroute_time é 40 porque o motorista permaneceu no estado enroute de 12:01:20 a 12:02:00 (e permaneceu até 2024-09-20 12:02:40, marcador do próximo minuto)

Eu estava tentando calcular o mesmo, mas não tinha 100% de certeza de como prosseguir:

• Estou um pouco preso tentando descobrir como dividir o campo de registro de data e hora em rastreador de minutos

  • Eu estava lendo mais sobre funções de agregação e data e hora e date_trunc pode ser usado para conseguir isso para agrupar os registros

• Estou tentando descobrir como fazer algo como uma tabela dinâmica que pode ser útil para nos ajudar a chegar à resposta final (no meu entendimento limitado)

OU:

• Precisamos encontrar a proporção para cada intervalo de minuto dado o estado, para que possamos conseguir isso calculando o marcador de tempo inicial e final para cada estado após explodir a visualização para o marcador de minuto da tabela atual. Essa é uma boa ideia ou pode haver uma abordagem melhor?

Minha tentativa:

select 
    id,
    state,
    date_trunc('minute', entry_time + interval '30 second') AS trunc_min,
    entry_time as curr_time,
    date_trunc('minute', entry_time + interval '60 second') AS ceil_min,
    LEAD(entry_time) over (PARTITION by id order by entry_time) as next_time,
    extract(epoch from (lead(entry_time) over (partition by id order by entry_time) - entry_time)) as duration
from (
    values 
    ('d1', '2024-09-20 12:01:01'::timestamp, 'Open'),
    ('d1', '2024-09-20 12:01:20'::timestamp, 'EnRoute'), 
    ('d1', '2024-09-20 12:02:40'::timestamp, 'OnTrip'),
    ('d1', '2024-09-20 12:04:10'::timestamp, 'Open')
) t("id", "entry_time", "state");

Saída:

 id |  state  |      trunc_min      |      curr_time      |      ceil_min       |      next_time      | duration  
----+---------+---------------------+---------------------+---------------------+---------------------+-----------
 d1 | Open    | 2024-09-20 12:01:00 | 2024-09-20 12:01:01 | 2024-09-20 12:02:00 | 2024-09-20 12:01:20 | 19.000000
 d1 | EnRoute | 2024-09-20 12:01:00 | 2024-09-20 12:01:20 | 2024-09-20 12:02:00 | 2024-09-20 12:02:40 | 80.000000
 d1 | OnTrip  | 2024-09-20 12:03:00 | 2024-09-20 12:02:40 | 2024-09-20 12:03:00 | 2024-09-20 12:04:10 | 90.000000
 d1 | Open    | 2024-09-20 12:04:00 | 2024-09-20 12:04:10 | 2024-09-20 12:05:00 |                     |          

Como prosseguir a partir daqui?

Não sou especialista em PostgreSQL, mas recentemente me deparei com um código PostgreSQL durante uma revisão de código que cria e remove tabelas temporárias de uma maneira que parece consistente com a maneira típica como fazemos isso no SQL Server. Ou seja, no SQL Server faríamos:

DROP TABLE IF EXISTS #temp_data;
CREATE TABLE #temp_data
(
    i int NOT NULL
);

A revisão do código mostrou este código:

BEGIN;
DROP TABLE IF EXISTS temp_data;
COMMIT;

BEGIN;
CREATE TEMP TABLE IF NOT EXISTS temp_data(
    i int NOT NULL
);
COMMIT;

Esta resposta no Stack Overflow afirma que você não deve remover e recriar tabelas temporárias com frequência por causa do pg_attributeinchaço.

O ChatGPT (ah!) tem isso a dizer sobre pg_attributeinchaço:

No PostgreSQL, criar tabelas temporárias com frequência pode causar inchaço em pg_attribute, pois cada nova tabela temporária adiciona metadados que persistem nos catálogos do sistema mesmo depois que a tabela é descartada. Para evitar inchaço excessivo, considere estas práticas recomendadas:

1. Use ON COMMIT DELETE ROWSem vez de descartar tabelas:

CREATE TEMP TABLE temp_data (
   i int NOT NULL
) ON COMMIT DELETE ROWS;

2. Use pg_tempSchema para tabelas temporárias em nível de sessão

CREATE TEMP TABLE pg_temp.temp_data (
    id SERIAL PRIMARY KEY,
    value TEXT
);

Já que tenho muitas dúvidas sobre a veracidade de quaisquer alegações feitas por qualquer modelo de linguagem grande, qual abordagem devo escolher? De fato, qualquer uma das abordagens é válida?

Há muitas maneiras de ver um procedimento criptografado.

Exemplo de um procedimento criptografado no SSMS:

Há uma pergunta muito boa: Como visualizar uma exibição criptografada ou um procedimento armazenado, onde você pode ver muitas maneiras de visualizar o código do seu procedimento criptografado, usando ferramentas de terceiros , a Conexão de Administrador Dedicada , revertendo a cifra de fluxo RC4 , só para mencionar algumas, mas há outras boas respostas lá.

Aqui está outra maneira espetacular de ver o código de um procedimento armazenado criptografado usando o DAC e um servidor vinculado.

Como então posso implantar procedimentos armazenados criptografados nos bancos de dados dos meus clientes, para que eles não consigam descriptografar e ver o código?

No passado, eles usaram nosso código em seus próprios procedimentos armazenados e quebraram a integridade dos dados em muitos aspectos e áreas. Não queremos que isso aconteça novamente; se eles precisarem de alguma mudança ou melhoria, eles podem passar pelo suporte e nós podemos providenciar isso.

Eles hospedam os bancos de dados e têm total acesso/controle e responsabilidade por backups, manutenção, etc. Não posso dar mais detalhes, talvez os DBAs deles estejam lendo isso agora ;)

Eu estava pensando que talvez eu pudesse adicionar ou anexar a descriptografia a uma senha...?

Eu também consideraria ferramentas de terceiros. Por favor, mencione se você tem uma experiência positiva com qualquer uma dessas ferramentas, mas eu preferiria fazer isso via SQL Server.

Pergunta: Existe uma maneira de implantar procedimentos armazenados criptografados que não podem ser descriptografados?

Ao executar um arquivo \copy(pgadmin ou aws_s3.table_import_from_s3) de 1,6 GB em um banco de dados compatível com o AWS Aurora Postgres, recebo o seguinte erro:

ERROR:  invalid byte sequence for encoding "UTF8": 0xdc 0x36
CONTEXT:  COPY staging, line 99779: "L24000403170365 ACTIVEZONE LLC                                                                      ..."

EDIT: Aqui está o que eu consegui extrair para a definição da tabela (mas me avise se quiser mais):

EDIT: Também tentei alterar a coluna, mas byteanão obtive efeito.

A fonte deveria ser ASCII, mas recebo o mesmo erro com codificações explícitas como utf8, latin1, win1251, e win1252. EDIT: Conforme solicitado em uma resposta, aqui estão mais informações sobre os comandos de importação. No pgadmin4, estou importando com o botão direito do mouse na tabela que mostra o seguinte sob as capas:

--command " "\\copy public.staging (\"raw\") FROM 'C:/data.txt' DELIMITER '|' ENCODING 'UTF8';""

Eu também uso o pgadmin4 para acionar a importação da tabela s3 chamando a consulta:

SELECT aws_s3.table_import_from_s3(
   'staging',
   '', 
   '(DELIMITER ''|'')',
   aws_commons.create_s3_uri('data', 'data.txt', 'us-east-1')
);

Debaixo das cobertas, table_import_from_s3chama o comando:

copy staging from '/rdsdbdata/extensions/aws_s3/{{internal filename}}' with (DELIMITER '|')

A resposta para perguntas semelhantes é limpar os dados de origem, então eu abri o python e tentei encontrar o caractere ofensivo. Não consegui encontrar nenhuma evidência de um caractere incomum na linha referenciada ou ao redor dela. Para fins de argumentação, acredito que o seguinte escaneará o arquivo inteiro (e você pode ver os resultados em linha):

>>> def charinfile(filename, bytechar):
...     with open(filename, 'rb') as file:
...         byteline = file.readline()
...         while byteline:  # readline returns empty string at EOF
...             if byteline.find(bytechar) != -1:
...                 print("found!")
...                 return byteline
...             byteline = file.readline()
...         else:
...             print("not found")
...
>>> charinfile(filename, b'\xdc')
not found
>>> charinfile(filename, b'\xdc36')
not found
>>> charinfile(filename, b'6') # make sure the code is working
found!

Também tentei versões em que uso strings em vez de bytes com os mesmos resultados. Posso confirmar que não há linhas em branco antes do EOF (usei contadores de linha para verificar se cheguei a ~1m de linhas).

O que estou perdendo?

Tentando entender quando o Apache Cassandra começou a oferecer suporte à arquitetura ARM-64. Especificamente, AWS Graviton. Encontrei várias documentações comparando o desempenho do C* no Intel vs. ARM. Mas, sem detalhes da versão. Exemplo, https://community.arm.com/arm-community-blogs/b/servers-and-cloud-computing-blog/posts/increase-price_2d00_performance-by-deploying-cassandra-on-aws-graviton2

Minhas perguntas são...

1. O C* começou a oferecer suporte ao ARM64 como o AWS Graviton desde a versão 4.0?
2. Não há um download binário separado para a versão ARM64 do C*?

Obrigado

Tenho uma situação parecida com essa da imagem:

2 servidores sql1 e sql2 que estão em um grupo de disponibilidade e um terceiro servidor que é basicamente um servidor de relatórios.

Preciso criar uma replicação transacional, o publicador está no grupo de disponibilidade, o assinante no servidor cliente.

o que eu estava planejando fazer é:

1. cliente também é distribuidor
2. a publicação reside em um ouvinte , então o distribuidor não sabe se é sql1 ou sql2 que está ativo
3. em caso de failover ou failback, os trabalhos de replicação ficam ativos apenas no nó primário.

O ideal seria que outro servidor ou grupo de disponibilidade fosse apenas o distribuidor, mas isso não é possível.

isso pode funcionar ou há alguma ponte que não posso cruzar nessa topologia?

depois de habilitar o TF 1448 ?

existe alguma maneira de aumentar o número de construção de índices secundários simultaneamente? se tivermos um nó que cai repentinamente e após o bootstrap vemos que algum índice "Enviando para construção" em debug.log (reconstruir para consertar), o cassandra fará isso em um thread, outros índices (se tivermos outro) permanecem em estado pendente. PS a versão do cassandra é 4.0.1

Alguns SGBDs têm uma pi()função para dar o valor de π. Não consigo encontrar o equivalente para Db2.

Posso usar radians(180), suponho, mas há algo mais direto?

Estamos tendo uma situação estranha em que, quando executamos nossos trabalhos de manutenção de índice, ele enche o servidor com sessões HADR_SYNC_COMMIT, onde todas as outras sessões dos aplicativos travam, aguardando a conclusão:

Estamos medindo a velocidade dos servidores, mas estamos quase próximos do limite de velocidade entre 2 ec2.

isso é algo que precisa ser corrigido externamente ao SQL?

temos 1 réplica de sincronização e uma assíncrona (4 nós com dr).