[comment]: # ({c4cea8a3-5b27abf6})
# 4 Przygotowanie tabeli auditlog do partycjonowania

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

[comment]: # ({f697fbbd-9f4e8194})
#### Przegląd

Niektóre bazy danych (na przykład MySQL) wymagają, aby kolumna partycjonowania była częścią unikalnego ograniczenia tabeli.
Dlatego, aby partycjonować tabelę `auditlog` według czasu, klucz główny musi zostać zmieniony z `auditid` na klucz złożony `auditid` + `clock`.

Ta sekcja zawiera instrukcje dotyczące zmiany klucza głównego tabeli `auditlog`.

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

[comment]: # ({496f4662-399f6b3f})
::: noteimportant
Instrukcje podane na tej stronie są przeznaczone dla zaawansowanych użytkowników.
Należy pamiętać, że instrukcje te mogą wymagać dostosowania do konkretnej konfiguracji.
Zmiana klucza głównego może być również niezgodna z przyszłymi poprawkami aktualizacyjnymi, dlatego może być konieczna ręczna obsługa przyszłych aktualizacji.
<br><br>
Zmiana klucza głównego może być operacją wymagającą dużych zasobów i zająć dużo czasu, w zależności od rozmiaru tabeli `auditlog`.
Zaleca się zatrzymanie serwera Zabbix i przełączenie frontend Zabbix w [tryb konserwacji](/manual/web_interface/maintenance_mode) na czas wprowadzania zmiany.
Jeśli jednak jest to absolutnie konieczne, istnieje sposób na zmianę klucza głównego bez przestoju (patrz poniżej).
:::

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

[comment]: # ({388a49dd-762f2fc8})
Partycjonowanie tabeli `auditlog` może poprawić na przykład housekeeping w dużych środowiskach.
Chociaż [housekeeping](/manual/web_interface/frontend_sections/administration/housekeeping) Zabbix obecnie nie może korzystać z tabel partycjonowanych (z wyjątkiem TimescaleDB), można wyłączyć housekeeping Zabbix i usuwać partycje za pomocą skryptów.

Od Zabbix 7.0 tabela `auditlog` dla TimescaleDB została przekształcona w hypertable, co pozwala housekeeperowi usuwać dane całymi chunkami.
Aby zaktualizować istniejącą tabelę `auditlog` do hypertable, zobacz [Upgrading TimescaleDB schema](/manual/appendix/install/timescaledb#upgrading-timescaledb-schema).

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

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

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

[comment]: # ({f576f708-e752da32})
##### Ważne uwagi dotyczące przebudowy indeksów {#important-notes-on-rebuilding-indexes-1}

MySQL automatycznie przebudowuje indeksy dla klucza głównego podczas operacji `ALTER TABLE`.
Jednak zdecydowanie zaleca się również ręczną przebudowę indeksów za pomocą polecenia `OPTIMIZE TABLE`, aby zapewnić optymalną wydajność bazy danych.

Przebudowa indeksów może tymczasowo wymagać dodatkowej ilości miejsca na dysku równej rozmiarowi samej tabeli.
Aby uzyskać bieżący rozmiar danych i indeksów, można wykonać następujące polecenia:

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

Jeśli dostępna przestrzeń dyskowa jest problemem, postępuj zgodnie z instrukcjami [Zmiana klucza głównego bez przestoju](#altering-primary-key-without-downtime-1).
Dostępne są również inne opcje:

-   Zwiększenie parametru MySQL [`sort_buffer_size`](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html) może pomóc zmniejszyć zużycie miejsca na dysku podczas ręcznej przebudowy indeksów.
    Należy jednak pamiętać, że modyfikacja tej zmiennej może wpłynąć na ogólne zużycie pamięci przez bazę danych.
-   Rozważ zwolnienie miejsca poprzez usunięcie potencjalnie niepotrzebnych danych.
-   Rozważ zmniejszenie parametru *Okres przechowywania danych* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) przed uruchomieniem housekeepera.

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

[comment]: # ({de2a0c3b-e0cfde87})
##### Zmiana klucza głównego z przestojem {#altering-primary-key-with-downtime-1}

1\. Usuń bieżący klucz główny tabeli `auditlog` i dodaj nowy klucz główny.

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

2\. Odbuduj indeksy (opcjonalnie, ale zdecydowanie zalecane, zobacz [Ważne uwagi dotyczące odbudowy indeksów](#important-notes-on-rebuilding-indexes-1)).

```sql
OPTIMIZE TABLE auditlog;
```

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

[comment]: # ({19b5a6ba-9fb9cdb0})
##### Zmiana klucza głównego bez przestoju {#altering-primary-key-without-downtime-1}

Ręczna metoda zmiany klucza głównego jest opisana tutaj.
Alternatywnie można użyć zestawu narzędzi [pt-online-schema-change](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html) firmy Percona.
Ten zestaw narzędzi automatycznie wykonuje następujące działania, jednocześnie minimalizując ilość miejsca używanego podczas zmiany tabeli `auditlog`.

1\. Utwórz nową tabelę z nowym kluczem głównym i utwórz indeksy.

```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\. Zamień tabele.

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

3\. Skopiuj dane ze starej tabeli do nowej tabeli.

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

Można to wykonać w częściach (za pomocą wielu instrukcji `INSERT INTO` z klauzulami `WHERE clock`, w razie potrzeby), aby uniknąć nadmiernego zużycia zasobów.

4\. Usuń starą tabelę.

```sql
DROP TABLE auditlog_old;
```

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

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

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

[comment]: # ({64d2938a-30f863e9})
##### Ważne uwagi dotyczące przebudowy indeksów {#important-notes-on-rebuilding-indexes-2}

PostgreSQL automatycznie przebudowuje indeksy dla klucza głównego podczas operacji `ALTER TABLE`.
Jednak zdecydowanie zaleca się również ręczną przebudowę indeksów za pomocą polecenia `REINDEX TABLE CONCURRENTLY`, aby zapewnić optymalną wydajność bazy danych.

Przebudowa indeksów może tymczasowo wymagać nawet trzykrotności miejsca na dysku aktualnie zajmowanego przez indeksy.
Aby sprawdzić bieżący rozmiar indeksów, możesz wykonać następujące zapytanie:

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

Jeśli dostępne miejsce na dysku jest problemem, postępuj zgodnie z instrukcjami w sekcji [Zmiana klucza głównego bez przestoju](#altering-primary-key-without-downtime-2).
Dostępne są również inne opcje:

-   Zwiększenie parametru PostgreSQL [`maintenance_work_mem`](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) może pomóc zmniejszyć zużycie miejsca na dysku podczas ręcznej przebudowy indeksów.
    Jednak modyfikacja tej zmiennej może wpłynąć na ogólne zużycie pamięci bazy danych.
-   Jeśli masz inny dysk lub tablespace z większą ilością wolnego miejsca, możesz rozważyć zmianę lokalizacji tymczasowego przechowywania na potrzeby przebudowy indeksu.
    Możesz ustawić parametr PostgreSQL [`temp_tablespaces`](https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-TEMP-TABLESPACES), aby wskazać inny tablespace dla obiektów tymczasowych.
-   Rozważ zwolnienie miejsca poprzez usunięcie potencjalnie niepotrzebnych danych.
-   Rozważ zmniejszenie parametru *Okres przechowywania danych* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) przed uruchomieniem housekeeper.

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

[comment]: # ({18dc0642-915b5f5f})
##### Zmiana klucza głównego z przestojem {#altering-primary-key-with-downtime-2}

1\. Usuń bieżący klucz główny tabeli `auditlog` i dodaj nowy klucz główny.

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

2\. Odbuduj indeksy (opcjonalnie, ale zdecydowanie zalecane; zobacz [Ważne uwagi dotyczące odbudowy indeksów](#important-notes-on-rebuilding-indexes-2)).

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

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

[comment]: # ({ab7f639c-998c6861})
##### Zmiana klucza głównego bez przestoju {#altering-primary-key-without-downtime-2}

Opis ręcznej metody zmiany klucza głównego znajduje się tutaj.
Alternatywnie można rozważyć rozszerzenie `pg_repack` do utworzenia nowej tabeli, skopiowania danych i zamiany tabel.

1\. Utwórz nową tabelę z nowym kluczem głównym i utwórz indeksy.

```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\. Zamień tabele.

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

3\. Skopiuj dane ze starej tabeli do nowej tabeli.

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

Można to wykonać w częściach (wiele instrukcji `INSERT INTO` z klauzulami `WHERE clock` w razie potrzeby), aby uniknąć nadmiernego zużycia zasobów.

4\. Usuń starą tabelę.

```sql
DROP TABLE auditlog_old;
```

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

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

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

[comment]: # ({fe750069-f5959ede})
##### Ważne uwagi dotyczące przebudowy indeksów {#important-notes-on-rebuilding-indexes-3}

Oracle automatycznie przebudowuje indeksy dla klucza głównego podczas operacji `ALTER TABLE`.
Jednak zdecydowanie zaleca się również ręczną przebudowę indeksów za pomocą instrukcji `ALTER INDEX <index> REBUILD PARALLEL`, aby zapewnić optymalną wydajność bazy danych.

Przebudowa indeksów może tymczasowo wymagać znacznej ilości miejsca na dysku.

Jeśli dostępna przestrzeń dyskowa jest problemem, postępuj zgodnie z instrukcjami [Zmiana klucza głównego bez przestoju](#altering-primary-key-without-downtime-3).
Dostępne są również inne opcje:

-   Zwiększenie parametru Oracle [`SORT_AREA_SIZE`](https://docs.oracle.com/en/database/oracle/oracle-database/19/refrn/SORT_AREA_SIZE.html) może pomóc zmniejszyć zużycie miejsca na dysku podczas ręcznej przebudowy indeksów.
    Jednak modyfikacja tej zmiennej wpłynie na ogólne zużycie pamięci przez bazę danych.
-   Możesz ustawić stopień równoległości za pomocą klauzuli PARALLEL, na przykład: `ALTER INDEX auditlog_1 REBUILD PARALLEL 4`
-   Rozważ zwolnienie miejsca przez usunięcie potencjalnie niepotrzebnych danych.
-   Rozważ zmniejszenie parametru *Okres przechowywania danych* [housekeeper](/manual/web_interface/frontend_sections/administration/housekeeping#overview) przed uruchomieniem housekeeper.

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

[comment]: # ({586dc269-221f8287})
##### Zmiana klucza głównego z przestojem {#altering-primary-key-with-downtime-3}

1\. Pobierz nazwę ograniczenia.

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

2\. Usuń bieżący klucz główny tabeli `auditlog` i dodaj nowy klucz główny.

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

3\. Odbuduj indeksy (opcjonalnie, ale zdecydowanie zalecane; zobacz [Ważne uwagi dotyczące odbudowy indeksów](#important-notes-on-rebuilding-indexes-3)).

3.1\. Pobierz nazwy indeksów.

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

3.2\. Odbuduj każdy indeks.

```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})
##### Zmiana klucza głównego bez przestoju {#altering-primary-key-without-downtime-3}

1\. Utwórz nową tabelę z nowym kluczem głównym i utwórz indeksy.

```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\. Zamień tabele.

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

3\. Skopiuj dane ze starej tabeli do nowej tabeli.

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

Można to wykonać partiami (wiele instrukcji `INSERT INTO` z klauzulami `WHERE clock` w razie potrzeby), aby uniknąć nadmiernego zużycia zasobów.

4\. Usuń starą tabelę.

```sql
DROP TABLE auditlog_old;
```

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

[comment]: # ({33200567-31083cb3})
#### Zobacz także

-   [Aktualizacja bazy danych do kluczy głównych](/manual/appendix/install/db_primary_keys)

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