[comment]: # ({c4cea8a3-5b27abf6})
# 4 Vorbereitung der auditlog-Tabelle für die Partitionierung

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

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

Einige Datenbanken (zum Beispiel MySQL) erfordern, dass die Partitionierungsspalte Teil der eindeutigen Einschränkung der Tabelle ist.
Daher muss zum Partitionieren der Tabelle `auditlog` nach Zeit der Primärschlüssel von `auditid` in einen zusammengesetzten Schlüssel `auditid` + `clock` geändert werden.

Dieser Abschnitt enthält Anweisungen zum Ändern des Primärschlüssels der Tabelle `auditlog`.

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

[comment]: # ({496f4662-399f6b3f})
::: noteimportant
Die auf dieser Seite bereitgestellten Anweisungen sind für fortgeschrittene Benutzer gedacht.
Beachten Sie, dass diese Anweisungen möglicherweise an Ihre spezifische Konfiguration angepasst werden müssen.
Das Ändern des Primärschlüssels kann außerdem mit zukünftigen Upgrade-Patches inkompatibel sein, sodass zukünftige Upgrades möglicherweise manuell durchgeführt werden müssen.
<br><br>
Das Ändern des Primärschlüssels kann je nach Größe der Tabelle `auditlog` ein ressourcenintensiver und zeitaufwändiger Vorgang sein.
Es wird empfohlen, den Zabbix Server anzuhalten und das Zabbix Frontend für die Dauer der Änderung in den [Wartungsmodus](/manual/web_interface/maintenance_mode) zu versetzen.
Falls jedoch unbedingt erforderlich, gibt es eine Möglichkeit, den Primärschlüssel ohne Ausfallzeit zu ändern (siehe unten).
:::

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

[comment]: # ({388a49dd-762f2fc8})
Die Partitionierung der Tabelle `auditlog` kann beispielsweise das Housekeeping in großen Umgebungen verbessern.
Obwohl das Zabbix-[Housekeeping](/manual/web_interface/frontend_sections/administration/housekeeping) derzeit partitionierte Tabellen nicht nutzen kann (außer bei TimescaleDB), können Sie das Zabbix-Housekeeping deaktivieren und Partitionen mithilfe von Skripten löschen.

Seit Zabbix 7.0 wurde die Tabelle `auditlog` für TimescaleDB in eine Hypertabelle umgewandelt, wodurch der Housekeeper Daten in Chunks löschen kann.
Informationen zum Upgrade der bestehenden Tabelle `auditlog` auf eine Hypertabelle finden Sie unter [Upgrading TimescaleDB schema](/manual/appendix/install/timescaledb#upgrading-timescaledb-schema).

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

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

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

[comment]: # ({f576f708-e752da32})
##### Wichtige Hinweise zum Neuerstellen von Indizes {#important-notes-on-rebuilding-indexes-1}

MySQL erstellt Indizes für den Primärschlüssel während der `ALTER TABLE`-Operation automatisch neu.
Es wird jedoch dringend empfohlen, Indizes zusätzlich manuell mit der Anweisung `OPTIMIZE TABLE` neu zu erstellen, um eine optimale Datenbankleistung sicherzustellen.

Das Neuerstellen von Indizes kann vorübergehend zusätzlichen Speicherplatz in einer Größenordnung erfordern, die der von der Tabelle selbst belegten Größe entspricht.
Um die aktuelle Größe von Daten und Indizes zu ermitteln, können Sie die folgenden Anweisungen ausführen:

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

Wenn der verfügbare Speicherplatz ein Problem darstellt, folgen Sie den Anweisungen unter [Primärschlüssel ohne Ausfallzeit ändern](#altering-primary-key-without-downtime-1).
Es sind auch andere Optionen verfügbar:

-   Eine Erhöhung des MySQL-Parameters [`sort_buffer_size`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) kann dazu beitragen, den Speicherplatzverbrauch beim manuellen Neuerstellen von Indizes zu verringern.
    Allerdings kann die Änderung dieser Variable den gesamten Speicherverbrauch der Datenbank beeinflussen.
-   Erwägen Sie, Speicherplatz freizugeben, indem Sie möglicherweise unnötige Daten löschen.
-   Erwägen Sie, den Parameter *Data storage period* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) vor dem Ausführen des housekeeper zu verringern.

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

[comment]: # ({de2a0c3b-e0cfde87})
##### Ändern des Primärschlüssels mit Ausfallzeit {#altering-primary-key-with-downtime-1}

1\. Entfernen Sie den aktuellen Primärschlüssel der Tabelle `auditlog` und fügen Sie den neuen Primärschlüssel hinzu.

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

2\. Erstellen Sie die Indizes neu (optional, aber sehr empfohlen, siehe [Wichtige Hinweise zum Neuerstellen von Indizes](#important-notes-on-rebuilding-indexes-1)).

```sql
OPTIMIZE TABLE auditlog;
```

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

[comment]: # ({19b5a6ba-9fb9cdb0})
##### Ändern des Primärschlüssels ohne Ausfallzeit {#altering-primary-key-without-downtime-1}

Die manuelle Methode zum Ändern des Primärschlüssels wird hier beschrieben.
Alternativ können Sie das Toolkit [pt-online-schema-change](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html) von Percona verwenden.
Dieses Toolkit führt die folgenden Aktionen automatisch aus und minimiert dabei gleichzeitig den Speicherplatz, der für die Änderung der Tabelle `auditlog` benötigt wird.

1\. Erstellen Sie eine neue Tabelle mit dem neuen Primärschlüssel und erstellen Sie Indizes.

```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\. Tauschen Sie die Tabellen aus.

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

3\. Kopieren Sie die Daten von der alten Tabelle in die neue Tabelle.

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

Dies kann in Blöcken erfolgen (mehrere `INSERT INTO`-Anweisungen mit `WHERE clock`-Klauseln nach Bedarf), um eine übermäßige Ressourcennutzung zu vermeiden.

4\. Löschen Sie die alte Tabelle.

```sql
DROP TABLE auditlog_old;
```

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

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

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

[comment]: # ({64d2938a-30f863e9})
##### Wichtige Hinweise zum Neuerstellen von Indizes {#important-notes-on-rebuilding-indexes-2}

PostgreSQL erstellt Indizes für den Primärschlüssel während der `ALTER TABLE`-Operation automatisch neu.
Es wird jedoch dringend empfohlen, Indizes auch manuell mit der Anweisung `REINDEX TABLE CONCURRENTLY` neu zu erstellen, um eine optimale Datenbankleistung sicherzustellen.

Das Neuerstellen von Indizes kann vorübergehend bis zum Dreifachen des aktuell von Indizes belegten Speicherplatzes auf dem Datenträger erfordern.
Um die aktuelle Größe der Indizes zu ermitteln, können Sie die folgende Abfrage ausführen:

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

Wenn der verfügbare Speicherplatz ein Problem darstellt, befolgen Sie die Anweisungen unter [Primärschlüssel ohne Ausfallzeit ändern](#altering-primary-key-without-downtime-2).
Es sind auch andere Optionen verfügbar:

-   Eine Erhöhung des PostgreSQL-Parameters [`maintenance_work_mem`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) kann helfen, den Speicherplatzverbrauch beim manuellen Neuerstellen von Indizes zu reduzieren.
    Allerdings kann die Änderung dieser Variable die gesamte Speichernutzung der Datenbank beeinflussen.
-   Wenn Sie über eine weitere Festplatte oder einen Tablespace mit mehr verfügbarem Speicherplatz verfügen, können Sie den temporären Speicherort für das Neuerstellen des Index ändern.
    Sie können den PostgreSQL-Parameter [`temp_tablespaces`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TEMP-TABLESPACES) festlegen, um einen anderen Tablespace für temporäre Objekte anzugeben.
-   Erwägen Sie, Speicherplatz freizugeben, indem Sie möglicherweise unnötige Daten löschen.
-   Erwägen Sie, den Parameter *Data storage period* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) vor der Ausführung des housekeeper zu verringern.

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

[comment]: # ({18dc0642-915b5f5f})
##### Ändern des Primärschlüssels mit Ausfallzeit {#altering-primary-key-with-downtime-2}

1\. Entfernen Sie den aktuellen Primärschlüssel der Tabelle `auditlog` und fügen Sie den neuen Primärschlüssel hinzu.

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

2\. Indizes neu aufbauen (optional, aber dringend empfohlen, siehe [Wichtige Hinweise zum Neuerstellen von Indizes](#important-notes-on-rebuilding-indexes-2)).

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

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

[comment]: # ({ab7f639c-998c6861})
##### Ändern des Primärschlüssels ohne Ausfallzeit {#altering-primary-key-without-downtime-2}

Hier wird die manuelle Methode zum Ändern des Primärschlüssels beschrieben.
Alternativ kann die Erweiterung `pg_repack` in Betracht gezogen werden, um eine neue Tabelle zu erstellen, Daten zu kopieren und Tabellen zu tauschen.

1\. Erstellen Sie eine neue Tabelle mit dem neuen Primärschlüssel und legen Sie Indizes an.

```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\. Tauschen Sie die Tabellen aus.

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

3\. Kopieren Sie die Daten von der alten Tabelle in die neue Tabelle.

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

Dies kann in Blöcken erfolgen (mehrere `INSERT INTO`-Anweisungen mit `WHERE clock`-Klauseln nach Bedarf), um eine übermäßige Ressourcennutzung zu vermeiden.

4\. Löschen Sie die alte Tabelle.

```sql
DROP TABLE auditlog_old;
```

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

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

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

[comment]: # ({fe750069-f5959ede})
##### Wichtige Hinweise zum Neuerstellen von Indizes {#important-notes-on-rebuilding-indexes-3}

Oracle erstellt Indizes für den Primärschlüssel während der `ALTER TABLE`-Operation automatisch neu.
Es wird jedoch dringend empfohlen, Indizes auch manuell mit den `ALTER INDEX <index> REBUILD PARALLEL`-Anweisungen neu zu erstellen, um eine optimale Datenbankleistung sicherzustellen.

Das Neuerstellen von Indizes kann vorübergehend erheblichen Speicherplatz auf dem Datenträger erfordern.

Wenn der verfügbare Speicherplatz auf dem Datenträger ein Problem darstellt, befolgen Sie die Anweisungen unter [Primärschlüssel ohne Ausfallzeit ändern](#altering-primary-key-without-downtime-3).
Es sind auch andere Optionen verfügbar:

-   Eine Erhöhung des Oracle-Parameters [`SORT_AREA_SIZE`](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/SORT_AREA_SIZE.html) kann dazu beitragen, den Speicherplatzverbrauch beim manuellen Neuerstellen von Indizes zu verringern.
    Allerdings wirkt sich die Änderung dieser Variable auf die gesamte Speichernutzung der Datenbank aus.
-   Sie können den Parallelitätsgrad mit der PARALLEL-Klausel festlegen, zum Beispiel: `ALTER INDEX auditlog_1 REBUILD PARALLEL 4`
-   Erwägen Sie, Speicherplatz freizugeben, indem Sie möglicherweise unnötige Daten löschen.
-   Erwägen Sie, den Parameter *Datenaufbewahrungszeitraum* [Housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) vor der Ausführung des Housekeepers zu verringern.

[comment]: # ({/fe750069-f5959ede})

[comment]: # ({586dc269-221f8287})
##### Ändern des Primärschlüssels mit Ausfallzeit {#altering-primary-key-with-downtime-3}

1\. Rufen Sie den Namen der Einschränkung ab.

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

2\. Entfernen Sie den aktuellen Primärschlüssel der Tabelle `auditlog` und fügen Sie den neuen Primärschlüssel hinzu.

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

3\. Erstellen Sie die Indizes neu (optional, aber dringend empfohlen, siehe [Wichtige Hinweise zum Neuerstellen von Indizes](#important-notes-on-rebuilding-indexes-3)).

3.1\. Ermitteln Sie die Indexnamen.

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

3.2\. Erstellen Sie jeden Index neu.

```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})
##### Ändern des Primärschlüssels ohne Ausfallzeit {#altering-primary-key-without-downtime-3}

1\. Erstellen Sie eine neue Tabelle mit dem neuen Primärschlüssel und erstellen Sie Indizes.

```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\. Tauschen Sie die Tabellen aus.

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

3\. Kopieren Sie die Daten aus der alten Tabelle in die neue Tabelle.

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

Dies kann in Blöcken erfolgen (mehrere `INSERT INTO`-Anweisungen mit `WHERE clock`-Klauseln nach Bedarf), um eine übermäßige Ressourcennutzung zu vermeiden.

4\. Löschen Sie die alte Tabelle.

```sql
DROP TABLE auditlog_old;
```

[comment]: # ({/d714ab21-af258bb0})

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

-   [Datenbank-Upgrade auf Primärschlüssel](/manual/appendix/install/db_primary_keys)

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