All perguntas(dba)

Estamos fazendo uma replicação lógica nativa do Postgres entre dois bancos de dados.

Agora, estamos recebendo um erro ao tentar atualizar do editor uma das mil tabelas que temos.

Quando tentamos atualizar a tabela ele retorna este erro:

ERRO: Lista de colunas utilizada pela publicação não cobre a identidade da réplica. Não é possível atualizar a tabela "etiquetas_j".

ERRO: não é possível atualizar a tabela "etiquetas_j" Estado SQL: 42P10 Detalle: A lista de colunas utilizada pela publicação não cobre a identidade da réplica.

A definição da tabela, tipos de dados, índices e pkeys são os mesmos no editor e no assinante

Veja aqui:

Editora :

    CREATE TABLE IF NOT EXISTS public.etiquetas_j (
    etiqueta_id integer NOT NULL,
    fecha timestamp without time zone,
    j_id integer NOT NULL,
    usuario_del_id integer,
    usuario_mod_id integer,
    organigrama_mod character varying(2) COLLATE pg_catalog."default",
    id integer NOT NULL DEFAULT nextval('etiquetas_j_id_seq1'::regclass),
    CONSTRAINT etiquetas_j_pkey PRIMARY KEY (id))
TABLESPACE pg_default; ALTER TABLE IF EXISTS public.etiquetas_j
    OWNER to postgres;


CREATE INDEX IF NOT EXISTS etiquetas_j_etiqueta_id_idx
    ON public.etiquetas_j USING btree
    (etiqueta_id ASC NULLS LAST)
    TABLESPACE pg_default;

CREATE INDEX IF NOT EXISTS etiquetas_j_id_idx
    ON public.etiquetas_j USING btree
    (j_id ASC NULLS LAST)
    TABLESPACE pg_default;

Assinante :

CREATE TABLE IF NOT EXISTS public.etiquetas_j
(
    etiqueta_id integer NOT NULL,
    fecha timestamp without time zone,
    j_id integer NOT NULL,
    usuario_del_id integer,
    usuario_mod_id integer,
    organigrama_mod character varying(2) COLLATE pg_catalog."default",
    id integer NOT NULL DEFAULT nextval('etiquetas_j_id_seq1'::regclass),
    CONSTRAINT etiquetas_j_pkey PRIMARY KEY (id)
)

TABLESPACE pg_default;

ALTER TABLE IF EXISTS public.etiquetas_j
    OWNER to postgres;

CREATE INDEX IF NOT EXISTS etiquetas_j_etiqueta_id_idx
    ON public.etiquetas_j USING btree
    (etiqueta_id ASC NULLS LAST)
    TABLESPACE pg_default;

CREATE INDEX IF NOT EXISTS etiquetas_j_id_idx
    ON public.etiquetas_j USING btree
    (j_id ASC NULLS LAST)
    TABLESPACE pg_default;

A publicação é definida da seguinte forma:

CREATE PUBLICATION publication_visor FOR TABLE etiquetas_j(
    etiqueta_id,
    fecha,
    j_id,
    usuario_del_id,
    usuario_mod_id ,
    organigrama_mod,
    id)

O erro ocorre quando executamos no provedor: update etiquetas_j set organigrama_mod = '02' where id = 3;

Obrigado e desculpe pelo mau inglês!

Já verificamos:

1. Veja quais são os índices.
2. Veja o que difere nos dois esquemas.
3. Veja o que o editor estava enviando na criação da publicação.
4. Aplicado ALTER TABLE etiquetas_j REPLICA IDENTITY FULL;

Eu tenho uma tabela particionada user_stayque possui muitos INSERTs e UPDATEs.

db=> \d user_stay;
                                     Partitioned table "public.user_stay"
      Column      |            Type             | Collation | Nullable |                Default
------------------+-----------------------------+-----------+----------+---------------------------------------
 id               | bigint                      |           | not null | nextval('user_stay_id_seq'::regclass)
 last_update_date | date                        |           | not null | CURRENT_DATE
 custom_place_id  | bigint                      |           |          |

Foreign-key constraints:
    "user_stay_custom_place_id_fkey" FOREIGN KEY (custom_place_id) REFERENCES user_custom_place(id) ON DELETE CASCADE

A partição é por last_update_date. Quando tento anexar a nova tabela de partições para a data futura, ocorre o erro.

Por exemplo, hoje é 30/08 e tento criar a tabela para 02/09:

CREATE TABLE user_stay_partition_2023_09_02 
    (LIKE user_stay INCLUDING DEFAULTS INCLUDING CONSTRAINTS);

ALTER TABLE user_stay_partition_2023_09_02 ADD CONSTRAINT "2023_09_02"
    CHECK ( last_update_date >= DATE '2023_09_02' AND
            last_update_date <  DATE '2023_09_03' );

ALTER TABLE user_stay ATTACH PARTITION user_stay_partition_2023_09_02
    FOR VALUES FROM ('2023_09_02') to ('2023_09_03');

O erro é:

[7396]:ERROR: deadlock detected at character 13
[7396]:DETAIL: Process 7396 waits for RowExclusiveLock on relation 594728 of database 18604; blocked by process 31245.
Process 31245 waits for ShareRowExclusiveLock on relation 594672 of database 18604; blocked by process 7396.
Process 7396: INSERT INTO user_stay (last_update_date, ...) VALUES ('2023-08-30'::date, ...) ON CONFLICT DO NOTHING RETURNING user_stay.id
Process 31245: ALTER TABLE user_stay ATTACH PARTITION user_stay_partition_2023_09_02
FOR VALUES FROM ('2023_09_02') to ('2023_09_03');

Atualização 1

Acho que o motivo são os dois SQLs a seguir:

1. INSERIR EM user_stay
2. ALTER TABLE user_stay ANEXAR PARTIÇÃO

Ambos requerem o bloqueio de user_stay& user_custom_place. Se o SQL 1 obtiver o bloqueio user_stayprimeiro e o SQL 2 obtiver o bloqueio user_custom_placeprimeiro, então será um impasse e ambos os SQLs não serão concluídos.

Atualização 2

Corrija o impasse bloqueando manualmente a tabela com a mesma ordem, para que o impasse desapareça:

BEGIN;
LOCK TABLE user_custom_place IN SHARE ROW EXCLUSIVE MODE;
ALTER TABLE user_stay ATTACH PARTITION user_stay_partition_2023_09_02
    FOR VALUES FROM ('2023_09_02') to ('2023_09_03');
COMMIT;

Eu tenho uma tabela que possui 483 colunas.

A date not null, a char(6) not nulle então 481 x float sparse null.

Pelas minhas contas, mesmo que todo float esparso não seja nulo, a linha ainda deve ser apenas:

date: 3 bytes
char(6): 6 bytes
sparse float: 12 bytes x 481
sparse update overhead: 2 bytes x 483
= 6747 bytes and way below the limit of 8060 
    (even allowing lots for other random overheads)

Na verdade, a linha real que causa o problema ainda tem 133 colunas flutuantes como nulas e o SQL Server afirma que essa linha tem um tamanho de linha de 8108 (e é muito grande).

Qual é o fantasma que está ocupando meu espaço na fila?

No SQL Server existe alguma maneira de obter informações sobre quando as colunas são criadas e quais colunas são novas? Além disso, preciso encontrar qualquer alteração nas colunas, por exemplo, quais tipos de dados das colunas foram alterados. Consigo obter a data de criação e última modificação das tabelas, mas para colunas não encontrei nenhuma consulta para fazer isso. Tentei usar trigger, audit e outras consultas que encontrei em fóruns, mas não obtive o resultado que desejo. Se alguém souber a solução, ajude por favor. Ferramentas de terceiros também são aceitáveis. Desde já, obrigado. Este é o meu código de gatilho:

DROP TABLE IF EXISTS ColumnChanges
CREATE TABLE ColumnChanges (
Id INT IDENTITY(1,1) PRIMARY KEY,
DatabaseName NVARCHAR(100),
TableName NVARCHAR(100),
ColumnName NVARCHAR(100),
ActionType NVARCHAR(50),
OldDataType NVARCHAR(50),
NewDataType NVARCHAR(50),
Add_Modify_Date DATETIME
)


CREATE TRIGGER trg_ColumnChange_AfterAlter
ON DATABASE
FOR ALTER_TABLE
AS
BEGIN
DECLARE @EventData XML
SET @EventData = EVENTDATA()

DECLARE @DatabaseName NVARCHAR(100)
DECLARE @TableName NVARCHAR(100)
DECLARE @ActionType NVARCHAR(50)
DECLARE @NewDataType NVARCHAR(100)
DECLARE @Add_Modify_Date DATETIME

SET @DatabaseName = @EventData.value('(/EVENT_INSTANCE/DatabaseName)[1]', 'NVARCHAR(100)')
SET @TableName = @EventData.value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(100)')
SET @ActionType = 'ADDED/MODIFIED'
SET @NewDataType = @EventData.value('(/EVENT_INSTANCE/AlterTableActionList/Alter/Columns/Column/DataTypeWithCollation)[1]', 'NVARCHAR(100)')
SET @Add_Modify_Date = GETDATE()

DECLARE @ColumnName NVARCHAR(100)
    SELECT @ColumnName = COLUMN_NAME    
        FROM INFORMATION_SCHEMA.COLUMNS 
        WHERE TABLE_NAME = @TableName

DECLARE @OldDataType NVARCHAR(100)
        SELECT @OldDataType = DATA_TYPE 
        FROM INFORMATION_SCHEMA.COLUMNS 
        WHERE COLUMN_NAME = @ColumnName


INSERT INTO ColumnChanges (DatabaseName, TableName, ColumnName, ActionType,OldDataType,NewDataType, Add_Modify_Date)
VALUES (@DatabaseName, @TableName, @ColumnName, @ActionType, @OldDataType, @NewDataType, @Add_Modify_Date)
  END

Estou tentando fazer uma consulta em loop para o agente Sql que verifica os dados dos usuários e se os critérios forem atendidos a recompensa é enviada, após isso excluiria os registros da tabela reiniciando o loop. O problema é que não consigo fazer o loop funcionar.

Minha mesa fica assim:

ID | login_id | price     |    date    |
1      user1      -100       01/01/1999   

O que eu tentei:

DECLARE @retVal int
SELECT  @retVal = COUNT(*)
select x.login_id, x.price
FROM Table as x inner join Table as b on x.login_id=b.login_id 
where x.price='-100'
order by x.login_id

IF (@retVal >= 3)
BEGIN

DELETE TOP (3) x 
FROM point_log_pitty as x 
inner join point_log_pitty as b on x.login_id=b.login_id 
where b.login_id=x.login_id and @retVal = 3 and x.price='-100';
End

O primeiro problema é que ele conta todos os registros para condições definidas (vários usuários), não por usuário. Exemplo do que tenho (não se limita a apenas 1 usuário):

ID | login_id | price     |    date    |
1      user1      -100       01/01/1999   
2      user2      -100       01/01/1999   
3      user3      -100       01/01/1999   

Eu tentei este também:

SELECT login_id, COUNT(login_id) AS username_count
FROM point_log_pitty
where price='-100'
GROUP BY login_id

O que conta corretamente os registros, mas não posso usar os resultados de username_count para excluir a consulta.

Objetivo: seria mais ou menos assim: Quando seu usuário x atingir 3'-100' de correspondência de preços, a consulta será executada e selecionará os registros do histórico do usuário que correspondem aos critérios e excluirá esses registros, reiniciando o loop.

Esses dados estão sendo buscados e excluídos.

ID | login_id | price     |    date    |
1      user1      -100       01/01/1999   
2      user1      -100       01/01/1999   
3      user1      -100       01/01/1999   

Dado um tipo enum (por exemplo, letter).

Qual é a sintaxe para converter um array existente para o tipo enum? Os valores existentes são válidos para o enum. Por exemplo, como eu converteria letter_dataem:

create table sample (
 letter_data text[];
);

Para o letterenum?

Eu tenho um sistema legado que usa Posgresql 9.6e Ubuntu 16.04. Tudo estava bem há vários dias, mesmo com as configurações padrão do Postgresql. Descartei um banco de dados com a opção de compactação (nível máximo de compactação -Z 9) para ter um tamanho menor ( pg_dump --compress=9 database_name > database_name.sql). Depois disso tive muitos problemas. Algumas consultas para determinadas tabelas passaram a ser executadas de forma muito lenta. Consultas para outras tabelas funcionam bem.

Aqui estão as tabelas com as quais tenho problemas.

isbns:
id (integer)
value (string), index b-tree
type (string)



books:
id (integer)
isbn (string), index b-tree
...
(total 32 columns)



isbns_statistics:
id (integer)
average_price (float)
average_rating (integer)
isbn_id (foreign key)
...
(total 17 columns)

Essas tabelas contêm 1.400.000 linhas cada.

Basicamente usei a seguinte consulta e funcionou bem:

(1) SELECT * FROM ISBNS JOIN BOOKS ON BOOKS.ISBN = ISBN.VALUE JOIN ISBNS_STATISTICS ON ISBNS_STATISTICS.ISBN_ID = ISBNS.ID ORDER BY ISBNS.VALUE LIMIT 100;

Mas depois que fiz o dump ele começou a ser executado de forma extremamente lenta. Não tenho certeza se é por causa do despejo, mas antes do despejo tudo funcionava bem. Esta consulta também funciona bem:

SELECT * FROM ISBNS JOIN BOOKS ON BOOKS.ISBN = ISBN.VALUE JOIN ISBNS_STATISTICS ON ISBNS_STATISTICS.ISBN_ID = ISBNS.ID LIMIT 100;

Esta consulta também é executada rapidamente:

SELECT * FROM ISBNS JOIN BOOKS ON BOOKS.ISBN = ISBN.VALUE ORDER BY ISBNS.VALUE LIMIT 100;

Alterei as configurações de desempenho (por exemplo, aumentei shared_buffer), mas isso não aumentou muito a velocidade.

Eu li que consultas contendo LIMIT e ORDER BY funcionam muito lentamente, mas se eu fizer essas consultas em outras tabelas, funciona bem.

Aqui está o plano de consulta para consulta (1):

                                                                         QUERY PLAN                                                                          
-------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=1048379.37..1048428.33 rows=100 width=498) (actual time=5264.193..5264.444 rows=100 loops=1)
   Buffers: shared hit=40250 read=332472, temp read=16699 written=28392
   ->  Merge Join  (cost=1048379.37..2291557.51 rows=2539360 width=498) (actual time=5264.191..5264.436 rows=100 loops=1)
         Merge Cond: ((books.isbn)::text = (isbns.value)::text)
         Buffers: shared hit=40250 read=332472, temp read=16699 written=28392
         ->  Index Scan using books_isbn_key on books  (cost=0.43..1205494.88 rows=1386114 width=333) (actual time=0.020..0.150 rows=100 loops=1)
               Buffers: shared hit=103
         ->  Materialize  (cost=1042333.77..1055199.75 rows=2573197 width=155) (actual time=5263.901..5263.960 rows=100 loops=1)
               Buffers: shared hit=40147 read=332472, temp read=16699 written=28392
               ->  Sort  (cost=1042333.77..1048766.76 rows=2573197 width=155) (actual time=5263.895..5263.949 rows=100 loops=1)
                     Sort Key: isbns.value
                     Sort Method: external merge  Disk: 136864kB
                     Buffers: shared hit=40147 read=332472, temp read=16699 written=28392
                     ->  Hash Join  (cost=55734.14..566061.44 rows=2573197 width=155) (actual time=403.962..1994.884 rows=1404582 loops=1)
                           Hash Cond: (isbns_statistics.isbn_id = isbns.id)
                           Buffers: shared hit=40147 read=332472, temp read=11281 written=11279
                           ->  Seq Scan on isbns_statistics  (cost=0.00..385193.97 rows=2573197 width=120) (actual time=0.024..779.717 rows=1404582 loops=1)
                                 Buffers: shared hit=26990 read=332472
                           ->  Hash  (cost=27202.84..27202.84 rows=1404584 width=35) (actual time=402.431..402.431 rows=1404584 loops=1)
                                 Buckets: 1048576  Batches: 2  Memory Usage: 51393kB
                                 Buffers: shared hit=13157, temp written=4363
                                 ->  Seq Scan on isbns  (cost=0.00..27202.84 rows=1404584 width=35) (actual time=0.027..152.568 rows=1404584 loops=1)
                                       Buffers: shared hit=13157
 Planning time: 1.160 ms
 Execution time: 5279.983 ms
(25 rows)

Então, as perguntas são:

1. Por que tudo funcionou bem e começou a funcionar lentamente?
2. Por que consultas semelhantes a outras tabelas ainda são executadas rapidamente?

Em uma instância do SSRS com um banco de dados ReportServer remoto, onde é feito o processamento? A instância SSRS vm deve obter cpus e memória adicionais ou a instância sql onde está o banco de dados ReportServer? As instâncias SQL de destino dos relatórios são boas em termos de CPU e memória. Obrigado!

Tenho uma dúvida teórica sobre o cluster MariaDB Galera. Digamos que um nó quebra e sai do cluster. Qual é o tempo máximo ou tamanho do log, o nó pode voltar ao cluster e começar a sincronizar antes que o nó navegue, o cluster está muito à frente e não consegue acompanhar as informações mais relevantes?

Um exemplo "estúpido": digamos que o cluster esteja na posição logarítmica 1.000. O Node3 sai neste ponto. O cluster se move um, atinge a posição de log 1.000.000, portanto está bem distante. Existe um ponto em que o Node3, ao voltar, dirá que não consegue encontrar todos os logs necessários para alcançar o cluster porque os logs avançaram muito. Tipo, nos servidores de cluster as posições entre 1.000 e 100.000 desaparecem para sempre, assim o Node3 pode obter os logs de 100.001 a 1.000.000, mas faltando os logs de 1.001 a 99.999. Este é um cenário real e, em caso afirmativo, como posso ajustar as configurações?

Depois de não usar muito o Microsoft Access por cerca de três anos, descobri que não consigo arrastar e soltar para reordenar grupos no Painel de Navegação enquanto estiver na visualização 'Personalizada'.

o que estou perdendo? Eles removeram isso? Quebrá-lo? Atualização ruim? Uma configuração que esqueci?

Isto é para o Access 365 instalado localmente na minha unidade C:.

A última versão do Access que usei foi 2007. Usei-o extensivamente até 2020 e vivi e respirei isso todos os dias. Em meu banco de dados principal "Workbench", eu tinha mais de 2.000 objetos e mais de 100 grupos para mantê-los organizados. Se a MS removesse o recurso de reordenação, acho que minha cabeça poderia explodir.