[comment]: # ({c4cea8a3-5b27abf6})
# 4 Preparazione della tabella auditlog per il partizionamento

[comment]: # ({/c4cea8a3-5b27abf6})

[comment]: # ({f697fbbd-9f4e8194})
#### Panoramica

Alcuni database (ad esempio MySQL) richiedono che la colonna di partizionamento faccia parte del vincolo univoco della tabella.
Pertanto, per partizionare la tabella `auditlog` in base al tempo, la chiave primaria deve essere modificata da `auditid` a una chiave composta `auditid` + `clock`.

Questa sezione fornisce istruzioni per modificare la chiave primaria della tabella `auditlog`.

[comment]: # ({/f697fbbd-9f4e8194})

[comment]: # ({496f4662-399f6b3f})
::: noteimportant
Le istruzioni fornite in questa pagina sono pensate per utenti avanzati.
Si noti che queste istruzioni potrebbero dover essere adattate alla configurazione specifica in uso.
La modifica della chiave primaria può inoltre essere incompatibile con future patch di aggiornamento, quindi potrebbe essere necessario gestire manualmente i futuri aggiornamenti.
<br><br>
La modifica della chiave primaria può essere un'operazione che richiede molte risorse e molto tempo, a seconda delle dimensioni della tabella `auditlog`.
Si consiglia di arrestare Zabbix server e di impostare Zabbix frontend in [modalità di manutenzione](/manual/web_interface/maintenance_mode) per la durata della modifica.
Tuttavia, se strettamente necessario, esiste un modo per modificare la chiave primaria senza tempi di inattività (vedere sotto).
:::

[comment]: # ({/496f4662-399f6b3f})

[comment]: # ({388a49dd-762f2fc8})
Il partizionamento della tabella `auditlog` può migliorare, ad esempio, l'housekeeping in configurazioni di grandi dimensioni.
Sebbene l'[housekeeping](/manual/web_interface/frontend_sections/administration/housekeeping) di Zabbix attualmente non possa sfruttare le tabelle partizionate (tranne che per TimescaleDB), è possibile disabilitare l'housekeeping di Zabbix ed eliminare le partizioni utilizzando script.

A partire da Zabbix 7.0, la tabella `auditlog` per TimescaleDB è stata convertita in una hypertable, il che consente al processo di housekeeping di eliminare i dati per chunk.
Per aggiornare la tabella `auditlog` esistente a una hypertable, vedere [Aggiornamento dello schema TimescaleDB](/manual/appendix/install/timescaledb#upgrading-timescaledb-schema).

[comment]: # ({/388a49dd-762f2fc8})

[comment]: # ({073b5bd5-271b9416})
#### MySQL

[comment]: # ({/073b5bd5-271b9416})

[comment]: # ({f576f708-e752da32})
##### Note importanti sulla ricostruzione degli indici {#important-notes-on-rebuilding-indexes-1}

MySQL ricostruisce automaticamente gli indici per la chiave primaria durante l'operazione `ALTER TABLE`.
Tuttavia, è fortemente consigliato ricostruire manualmente anche gli indici con l'istruzione `OPTIMIZE TABLE` per garantire prestazioni ottimali del database.

La ricostruzione degli indici può richiedere temporaneamente una quantità di spazio su disco aggiuntivo pari a quella utilizzata dalla tabella stessa.
Per ottenere le dimensioni correnti dei dati e degli indici, è possibile eseguire le seguenti istruzioni:

```sql
ANALYZE TABLE auditlog;
SHOW TABLE STATUS LIKE 'auditlog';
```

Se lo spazio disponibile su disco è un problema, seguire le istruzioni di [Alterare la chiave primaria senza downtime](#altering-primary-key-without-downtime-1).
Sono disponibili anche altre opzioni:

-   Aumentare il parametro MySQL [`sort_buffer_size`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) può aiutare a ridurre l'uso dello spazio su disco quando si ricostruiscono manualmente gli indici.
    Tuttavia, la modifica di questa variabile può influire sull'utilizzo complessivo della memoria del database.
-   Valutare la possibilità di liberare spazio eliminando dati potenzialmente non necessari.
-   Valutare la possibilità di ridurre il parametro *Periodo di conservazione dei dati* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) prima di eseguire il housekeeper.

[comment]: # ({/f576f708-e752da32})

[comment]: # ({de2a0c3b-e0cfde87})
##### Modifica della chiave primaria con downtime {#altering-primary-key-with-downtime-1}

1\. Rimuovere la chiave primaria corrente della tabella `auditlog` e aggiungere la nuova chiave primaria.

```sql
ALTER TABLE auditlog DROP PRIMARY KEY, ADD PRIMARY KEY (auditid, clock);
```

2\. Ricostruire gli indici (opzionale ma fortemente consigliato, vedere [Note importanti sulla ricostruzione degli indici](#important-notes-on-rebuilding-indexes-1)).

```sql
OPTIMIZE TABLE auditlog;
```

[comment]: # ({/de2a0c3b-e0cfde87})

[comment]: # ({19b5a6ba-9fb9cdb0})
##### Modifica della chiave primaria senza downtime {#altering-primary-key-without-downtime-1}

Qui è descritto il metodo manuale per modificare la chiave primaria.
In alternativa, puoi usare il toolkit [pt-online-schema-change](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html) di Percona.
Questo toolkit esegue automaticamente le seguenti azioni, riducendo al minimo anche lo spazio utilizzato per modificare la tabella `auditlog`.

1\. Crea una nuova tabella con la nuova chiave primaria e crea gli indici.

```sql
CREATE TABLE `auditlog_new` (
  `auditid`            varchar(25)                               NOT NULL,
  `userid`             bigint unsigned                           NULL,
  `username`           varchar(100)    DEFAULT ''                NOT NULL,
  `clock`              integer         DEFAULT '0'               NOT NULL,
  `ip`                 varchar(39)     DEFAULT ''                NOT NULL,
  `action`             integer         DEFAULT '0'               NOT NULL,
  `resourcetype`       integer         DEFAULT '0'               NOT NULL,
  `resourceid`         bigint unsigned                           NULL,
  `resource_cuid`      varchar(25)                               NULL,
  `resourcename`       varchar(255)    DEFAULT ''                NOT NULL,
  `recordsetid`        varchar(25)                               NOT NULL,
  `details`            longtext                                  NOT NULL,
  PRIMARY KEY (auditid,clock)
) ENGINE=InnoDB;
CREATE INDEX `auditlog_1` ON `auditlog_new` (`userid`,`clock`);
CREATE INDEX `auditlog_2` ON `auditlog_new` (`clock`);
CREATE INDEX `auditlog_3` ON `auditlog_new` (`resourcetype`,`resourceid`);
```

2\. Scambia le tabelle.

```sql
RENAME TABLE auditlog TO auditlog_old, auditlog_new TO auditlog;
```

3\. Copia i dati dalla tabella القديمة alla nuova tabella.

```sql
INSERT INTO auditlog SELECT * FROM auditlog_old;
```

Questo può essere fatto a blocchi (più istruzioni `INSERT INTO` con clausole `WHERE clock` secondo necessità) per evitare un uso eccessivo delle risorse.

4\. Elimina la vecchia tabella.

```sql
DROP TABLE auditlog_old;
```

[comment]: # ({/19b5a6ba-9fb9cdb0})

[comment]: # ({dc8ac96e-381b1eee})
#### PostgreSQL

[comment]: # ({/dc8ac96e-381b1eee})

[comment]: # ({64d2938a-30f863e9})
##### Note importanti sulla ricostruzione degli indici {#important-notes-on-rebuilding-indexes-2}

PostgreSQL ricostruisce automaticamente gli indici per la chiave primaria durante l'operazione `ALTER TABLE`.
Tuttavia, è fortemente consigliato ricostruire manualmente anche gli indici con l'istruzione `REINDEX TABLE CONCURRENTLY` per garantire prestazioni ottimali del database.

La ricostruzione degli indici può richiedere temporaneamente fino a tre volte lo spazio su disco attualmente utilizzato dagli indici.
Per ottenere la dimensione attuale degli indici, è possibile eseguire la seguente query:

```sql
SELECT pg_size_pretty(pg_indexes_size('auditlog'));
```

Se lo spazio disponibile su disco è un problema, seguire le istruzioni in [Modifica della chiave primaria senza tempi di inattività](#altering-primary-key-without-downtime-2).
Sono disponibili anche altre opzioni:

-   Aumentare il parametro PostgreSQL [`maintenance_work_mem`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) può aiutare a ridurre l'uso dello spazio su disco durante la ricostruzione manuale degli indici.
    Tuttavia, la modifica di questa variabile può influire sull'utilizzo complessivo della memoria del database.
-   Se si dispone di un altro disco o tablespace con più spazio disponibile, si può prendere in considerazione la modifica della posizione di archiviazione temporanea per la ricostruzione dell'indice.
    È possibile impostare il parametro PostgreSQL [`temp_tablespaces`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TEMP-TABLESPACES) per specificare un tablespace diverso per gli oggetti temporanei.
-   Valutare la possibilità di liberare spazio eliminando dati potenzialmente non necessari.
-   Valutare la possibilità di ridurre il parametro *Periodo di conservazione dei dati* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) prima di eseguire l'housekeeper.

[comment]: # ({/64d2938a-30f863e9})

[comment]: # ({18dc0642-915b5f5f})
##### Modifica della chiave primaria con downtime {#altering-primary-key-with-downtime-2}

1\. Rimuovere la chiave primaria corrente della tabella `auditlog` e aggiungere la nuova chiave primaria.

```sql
ALTER TABLE auditlog DROP CONSTRAINT auditlog_pkey;
ALTER TABLE auditlog ADD PRIMARY KEY (auditid,clock);
```

2\. Ricostruire gli indici (opzionale ma altamente consigliato, vedere [Note importanti sulla ricostruzione degli indici](#important-notes-on-rebuilding-indexes-2)).

```sql
REINDEX TABLE CONCURRENTLY auditlog;
```

[comment]: # ({/18dc0642-915b5f5f})

[comment]: # ({ab7f639c-998c6861})
##### Modifica della chiave primaria senza downtime {#altering-primary-key-without-downtime-2}

Qui è descritto il metodo manuale per modificare la chiave primaria.
In alternativa, l'estensione `pg_repack` può essere presa in considerazione per creare una nuova tabella, copiare i dati e scambiare le tabelle.

1\. Creare una nuova tabella con la nuova chiave primaria e creare gli indici.

```sql
CREATE TABLE auditlog_new (
  auditid              varchar(25)                               NOT NULL,
  userid               bigint                                    NULL,
  username             varchar(100)    DEFAULT ''                NOT NULL,
  clock                integer         DEFAULT '0'               NOT NULL,
  ip                   varchar(39)     DEFAULT ''                NOT NULL,
  action               integer         DEFAULT '0'               NOT NULL,
  resourcetype         integer         DEFAULT '0'               NOT NULL,
  resourceid           bigint                                    NULL,
  resource_cuid        varchar(25)                               NULL,
  resourcename         varchar(255)    DEFAULT ''                NOT NULL,
  recordsetid          varchar(25)                               NOT NULL,
  details              text            DEFAULT ''                NOT NULL,
  PRIMARY KEY (auditid,clock)
);
CREATE INDEX auditlog_new_1 ON auditlog_new (userid,clock);
CREATE INDEX auditlog_new_2 ON auditlog_new (clock);
CREATE INDEX auditlog_new_3 ON auditlog_new (resourcetype,resourceid);
```

2\. Scambiare le tabelle.

```sql
ALTER TABLE auditlog RENAME TO auditlog_old;
ALTER TABLE auditlog_new RENAME TO auditlog;
```

3\. Copiare i dati dalla vecchia tabella alla nuova tabella.

```sql
INSERT INTO auditlog SELECT * FROM auditlog_old;
```

Questo può essere fatto in blocchi (più istruzioni `INSERT INTO` con clausole `WHERE clock` secondo necessità) per evitare un uso eccessivo delle risorse.

4\. Eliminare la vecchia tabella.

```sql
DROP TABLE auditlog_old;
```

[comment]: # ({/ab7f639c-998c6861})

[comment]: # ({33200567-31083cb3})
#### Vedi anche

-   [Aggiornamento del database alle chiavi primarie](/manual/appendix/install/db_primary_keys)

[comment]: # ({/33200567-31083cb3})