[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 [Alterazione della chiave primaria senza tempi di inattività](#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 l'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 la modifica della 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 vecchia 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 corrente 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 quando si ricostruiscono manualmente gli indici.
    Tuttavia, la modifica di questa variabile può influire sull'uso 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]: # ({2a8e17b6-2132d968})
#### Oracle

[comment]: # ({/2a8e17b6-2132d968})

[comment]: # ({fe750069-f5959ede})
##### Note importanti sulla ricostruzione degli indici {#important-notes-on-rebuilding-indexes-3}

Oracle ricostruisce automaticamente gli indici per la chiave primaria durante l'operazione `ALTER TABLE`.
Tuttavia, è fortemente consigliato ricostruire manualmente anche gli indici con le istruzioni `ALTER INDEX <index> REBUILD PARALLEL` per garantire prestazioni ottimali del database.

La ricostruzione degli indici può richiedere temporaneamente una notevole quantità di spazio su disco.

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-3).
Sono disponibili anche altre opzioni:

-   Aumentare il parametro Oracle [`SORT_AREA_SIZE`](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/SORT_AREA_SIZE.html) può aiutare a ridurre l'uso dello spazio su disco durante la ricostruzione manuale degli indici.
    Tuttavia, la modifica di questa variabile influirà sull'utilizzo complessivo della memoria del database.
-   È possibile impostare il grado di parallelismo usando la clausola PARALLEL, ad esempio: `ALTER INDEX auditlog_1 REBUILD PARALLEL 4`
-   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]: # ({/fe750069-f5959ede})

[comment]: # ({586dc269-221f8287})
##### Modifica della chiave primaria con downtime {#altering-primary-key-with-downtime-3}

1\. Recuperare il nome del vincolo.

```sql
SELECT CONSTRAINT_NAME FROM all_constraints WHERE TABLE_NAME = 'AUDITLOG' AND CONSTRAINT_TYPE = 'P';
```

2\. Eliminare la chiave primaria corrente della tabella `auditlog` e aggiungere la nuova chiave primaria.

```sql
ALTER TABLE auditlog DROP CONSTRAINT <constraint_name>;
ALTER TABLE auditlog ADD CONSTRAINT auditlog_pk PRIMARY KEY (auditid, clock);
```

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

3.1\. Ottenere i nomi degli indici.

```sql
SELECT index_name FROM user_indexes WHERE table_name='AUDITLOG';
```

3.2\. Ricostruire ciascun indice.

```sql
ALTER INDEX auditlog_pk REBUILD PARALLEL;
ALTER INDEX auditlog_1 REBUILD PARALLEL;
ALTER INDEX auditlog_2 REBUILD PARALLEL;
ALTER INDEX auditlog_3 REBUILD PARALLEL;
```

[comment]: # ({/586dc269-221f8287})

[comment]: # ({d714ab21-af258bb0})
##### Alterazione della chiave primaria senza downtime {#altering-primary-key-without-downtime-3}

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

```sql
CREATE TABLE auditlog_new (
  auditid              nvarchar2(25)                             ,
  userid               number(20)                                NULL,
  username             nvarchar2(100)  DEFAULT ''                ,
  clock                number(10)      DEFAULT '0'               NOT NULL,
  ip                   nvarchar2(39)   DEFAULT ''                ,
  action               number(10)      DEFAULT '0'               NOT NULL,
  resourcetype         number(10)      DEFAULT '0'               NOT NULL,
  resourceid           number(20)                                NULL,
  resource_cuid        nvarchar2(25)                             ,
  resourcename         nvarchar2(255)  DEFAULT ''                ,
  recordsetid          nvarchar2(25)                             ,
  details              nclob           DEFAULT ''                ,
  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]: # ({/d714ab21-af258bb0})

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

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

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