All perguntas(dba)

Criei um procedimento armazenado no ServerA (SQL Server 2019) que insere várias linhas em uma tabela local.

Quando chamo o procedimento armazenado usando OPENQUERY do ServerB (SQL Server 2012), o procedimento é executado, mas as linhas não são inseridas.

Executar a mesma inserção do ServerB com OPENQUERY retorna um erro 7357 (a mensagem de erro real está em francês, informando que o provedor OLE DB "SQLNCLI11" relata que o objeto não possui colunas ou o usuário não tem acesso ao objeto).

Estou usando um servidor vinculado no ServerB com autenticação SQL. O RPC está desabilitado no ServerA, daí o uso de OPENQUERY.

Se eu usar a mesma instrução para inserir usando OPENQUERY em uma sessão SSMS diretamente no ServerA usando as mesmas credenciais do servidor vinculado, funciona - eu havia concedido INSERT a esse usuário na tabela em questão antes de iniciar meus testes.

Realizei atualizações na mesma tabela do servidor vinculado por muitos meses sem problemas.

Na verdade, um INSERT no ServerB usando um nome de 4 partes para a tabela funciona.

Preciso de uma permissão extra para realizar inserções remotamente?

Estou tentando configurar a segurança em nível de linha em um banco de dados Amazon RDS (Postgres 15) para alimentar um projeto Django.

O usuário que passo para o Django não é superusuário e não herdou BYPASSRLSnenhuma de suas funções. Eu sei disso a partir desta consulta:

SELECT
    rolname,
    rolsuper,
    rolbypassrls
FROM
    pg_roles
WHERE
    oid in (
        WITH RECURSIVE cte AS (
            SELECT
                oid
            FROM
                pg_roles
            WHERE
                rolname = current_user
            UNION
            ALL
            SELECT
                m.roleid
            FROM
                cte
                JOIN pg_auth_members m ON m.member = cte.oid
        )
        SELECT
            oid
        FROM
            cte
    )

O usuário possui o banco de dados, o esquema e a tabela, mas quando adicionei a política também executei:

ALTER TABLE certain_table ENABLE ROW LEVEL SECURITY;
ALTER TABLE certain_table FORCE ROW LEVEL SECURITY;

Em um Postgres local (Docker) e na mesma configuração, executando SELECT row_security_active('certain_table')return True. No RDS ele retorna False.

Estou faltando algum outro critério para ignorar a segurança em nível de linha?

Como parte de um programa de correção herdado, migramos os bancos de dados do aplicativo de uma instância antiga do SQL Server 2000 em execução no Windows 2003 para uma nova instância do SQL Server 2022 em execução no Windows 2022. A camada do aplicativo tem vários servidores Web usando IIS 6.0 no Windows 2003 e quando tentam testar a conexão com o novo SQL Server, obtêm o erro de segurança SSL abaixo. Alguma ideia do que poderia ser o problema está aqui, é provável que seja o driver (a captura de tela abaixo mostra os drivers instalados nos servidores web)? Ou é provável que esteja relacionado a quais versões de SSL/TLS estão habilitadas em ambos os lados?

Tenho duas tabelas, #customer e #abbr. A tabela #customer consiste em duas colunas: 'id' e 'name', enquanto a tabela #abbr inclui entradas para abreviações e seus correspondentes formulários completos. Meu objetivo é substituir todas as abreviações nos nomes dos clientes pelos respectivos formulários completos. Por exemplo, se o nome de um cliente for 'Object ME CT', espero que o resultado seja 'Object Medical Control'. No entanto, com minha consulta atual, ela produz duas linhas: 'Object ME Control' e 'Object Medical CT'. Meu objetivo é uma única linha por 'id', onde todas as abreviações sejam substituídas por seus formulários completos da tabela #abbr. Como posso conseguir isso? Obrigado!

create table #customer
(
id int identity(1,1)
,cname varchar(100)
)

create table #abbr
(
abbr varchar(100),
fname varchar(100)
)

insert into #customer values('Assign ME CT'),('Assign ME'),('Assign CT')
insert into #abbr values ('ME','Medical'),('CT','Control'),('MMT','Metro')

select *, REPLACE(c.cname, a.abbr,a.fname)
  from #customer c
  join #abbr a
  on c.cname like '%'+a.abbr+'%'
 where id = 1

Quando eu executo isso:

DROP TABLE IF EXISTS #QueryHashes;
CREATE TABLE #QueryHashes (query_hash BINARY(8) NOT NULL PRIMARY KEY);

PRINT CAST(0x0169857CCD5BBBE4E AS BINARY(8)); -- just testing that the value is a legitimate BINARY(8)

/* Insert your query_hash values inside the outer parenthesis below, 
   each wrapped in parenthesis, comma-separated (for example, "(0x89E35F2D4C638298), (0x89E35F2D4C638298)") 
*/
INSERT INTO #QueryHashes (query_hash)
VALUES (0x0169857CCD5BBBE4E);

PRINT CAST(0x0169857CCD5BBBE4E AS BINARY(8)); -- just testing that the value is a legitimate BINARY(8)

Eu recebo este erro:

0x00169857CCD5BBBE Msg 2628, Nível 16, Estado 1, Linha 9 String ou dados binários seriam truncados na tabela 'tempdb.dbo.#QueryHashes______________________________________________________________________________________________________________000000000D06', coluna 'query_hash'. Valor truncado: ''. A instrução foi encerrada. 0x00169857CCD5BBBE

Observe que o valor na mensagem de erro parece ser uma string vazia.

Claramente, a inserção está falhando, enquanto as conversões funcionam. Alguém pode me ajudar a entender o que há de errado com a inserção ou definição da tabela? Mesmo se eu remover a "NOT NULL PRIMARY KEY", ainda recebo o mesmo erro.

(A intenção final é inserir alguns valores na tabela e juntá-los em uma grande consulta.)

Gostaria de saber qual a diferença entre CREATE INDEX e CREATE INDEX CONCURRENTLY (se houver) após a criação do índice ter sido construído. Tenho discutido com um colega sobre como eles funcionam.

Meu entendimento é que CREATE INDEX exige um bloqueio completo na tabela para construir o índice rapidamente, causando tempo de inatividade, mas para CREATE INDEX CONCURRENTLY apenas um bloqueio parcial é obtido na tabela. Isso significa que os índices são calculados para cada nova transação/inserção à medida que a tabela contém gravações e, sempre que não há transações/inserções acontecendo, ela está "preenchendo" ou processando os índices para os dados que já estavam lá. Depois que esse processo de "preenchimento" for concluído, não haverá diferença estrita entre CREATE INDEX e CREATE INDEX CONCURRENTLY.

O entendimento do meu colega é que CREATE INDEX CONCURRENTLY se comporta de maneira diferente e que, mesmo após a conclusão do "processo de preenchimento", CREATE INDEX CONCURRENTLY continua sendo menos intensivo em carga nas gravações.

Alguém pode nos fornecer uma visão melhor de como funciona a criação de índices? Quando podemos dizer que um índice foi criado? O que acontece depois que o índice termina de ser criado sempre que você insere dados? E se há diferença no cálculo do índice após a conclusão da construção ao usar CONCURRENTEMENTE ou não?

Preciso criar uma tabela para cache no banco de dados postgresql. As transações devem ser o mais rápidas possível, então pensei em criar uma tabela não registrada e ter um disco RAM como espaço de tabela.

Há um aviso na documentação oficial do postgresql :

Colocar um espaço de tabela em um sistema de arquivos temporário, como um disco RAM, coloca em risco a confiabilidade de todo o cluster.

Eu sei que as tabelas não registradas não são replicadas para o modo de espera e não há problema em armazenar dados não persistentes nessa tabela. Então, em caso de acidente, estou bem em perdê-lo. Aqui está uma pergunta:

1. Afinal, é seguro colocar um espaço de tabela no disco RAM nesta configuração? (não registrado + espaço de tabela do disco RAM + dados não persistentes)
2. Se for uma opção segura, devo criar um disco RAM em uma réplica também, já que a criação do espaço de tabela será armazenada em algum lugar no wal?

Estou usando o EDB 13.9.13 com replicação de streaming. Se isso funcionar, farei o mesmo para o Postgresql v14.7

Estou trabalhando com PostgreSQL e tenho uma preocupação com o inchaço da tabela ao adicionar uma nova coluna a uma tabela existente. Entendo que o PostgreSQL usa Multi-Version Concurrency Control (MVCC) e autovacuum para recuperar espaço de linhas antigas.

Aqui está o cenário:

Digamos que eu tenha uma tabela nomeada example_tablecom dados existentes e decido adicionar uma nova coluna, por exemplo, new_columnde um tipo de dados maior:

ALTER TABLE example_table ADD COLUMN new_column VARCHAR(255);

Além disso, atualizarei a nova coluna com novos valores:

UPDATE example_table SET new_column = 'some_value';

Pelo que entendi, após esta operação, as linhas antigas são marcadas como mortas e o autovacuum eventualmente recuperará o espaço. No entanto, as linhas antigas eram de tamanho menor em comparação com as novas linhas com a coluna adicionada.

Tenho as seguintes perguntas:

• Como o PostgreSQL (especificamente, Autovacuum) lida com o espaço recuperado de linhas antigas, considerando a diferença de tamanho entre as linhas antigas e as novas?
• Esse processo levará potencialmente ao inchaço da tabela, já que as tuplas mortas não podem ser reutilizadas devido à diferença de tamanho?
• É necessário executar um VACUUM FULL para recuperar espaço com eficiência em tal cenário, ou o autovacuum lidará com isso de forma adequada?

Acabei de começar a aprender PostgreSQL. Tentei criar uma tabela:

create table diagnosis(
    mkb10 char(5),
    opis varchar(100) not null,
    constraint pk_diagnosis primary key (mkb10)
);

Mas eu recebo este erro:

ERRO: erro de sintaxe em ou próximo a "char"

Tenho lido sobre o particionamento de tabelas no mariadb.

Eu sei que isso não proporcionará nenhum ganho direto de desempenho. Mas e as tabelas de índice? Eles também são particionados?

Digamos que uma tabela seja particionada, user_identão todos os dados relacionados a um usuário estarão na mesma partição da tabela. Em uma sessão de usuário, cada consulta irá, portanto, buscar dados apenas de uma única partição de tabela

Minha pergunta é: as tabelas de índices também serão particionadas de acordo? Quando uma consulta é executada, ela pesquisa apenas na tabela de índices particionados e não em todos os índices = less para pesquisar