IT blok - Michal Šika

kutilovo živobytí

Dump a load obsahu docbáze

V tomto článku popíšu vytvoření dump a load skriptů pro celou Documentum docbázi i pro postupný dump a load po jednotlivých adresářích.

Documentum umožňuje udělad dump a load obsahu docbáze. Znamená to, že jsou exportována data do nějakého souboru, který můžeme přenést na jiný server, kde běží jiná docbáze a zde je zase naloadovat.
Je důležité, aby se cílová docbáze, do které se loaduje, nejmenovala stejně jako docbáze zdrojová a ani aby neměla stejné repository ID.

Dump celé docbáze

Pro provedení dumpu celé docbáze, je možné využít následující API skript:

create,c,dm_dump_record
set,c,l,file_name
D:Tempjmeno_souboru.dmp
set,c,l,dump_operation
full_docbase_dump
set,c,l,include_content
T
save,c,l
getmessage,c
exit

Tyto řádky se uloží například do souboru dump.api a ten vložíme do adresáře $DM_HOMEbin, kde se nachází i program iapi32.exe (u Linuxu je to iapi).

Zde se spustí příkazová řádka a zadá se příkaz

iapi32.exe jmeno_repository -Uuzivatel -Pheslo -rjmeno_dump_scriptu -e > dump_log.txt

Tedy konkrétně toto:

iapi32.exe -Udmadmin -Pheslo -rdump.api -e > dump_log.txt

Toto je také možné vložit do nějakého *.bat souboru (např. dump.bat) a pak spustit poklikáním.
Příkaz (nebo *.bat dávka) se přihlásí do docbáze přes API rozhraní, spustí dump sript (*.api) a zaznamená vše do logu.

V *.api skriptu si všimněme parametru include_content, který je nastaven na hodnotu TRUE. To znamená, že se vytvoří jeden velký dump soubor.
Pokud by parametr byl nastaven na FALSE, tak by se vytvořilo několik menších dump souborů. To by mírně urychlilo proces dumpu. Nicméně toto nastavení se doporučuje pokud zdrojová i cílová docbáze jsou na jednom serveru.

Při použití tohoto řešení, je proveden dump nad objekty dm_sysobject, dm_document, dmr_content, dm_user a dm_group, proto je dobré nad nimi nejprve spustit count, abychom měli představu, jak bude výsledný soubor velký.

Dump jednotlivých adresářů

Pro provedení dumpu jednoho adresáře (kabinetu) je potřeba vytvořit dump.api skript s následujícím obsahem:

create,c,dm_dump_record
set,c,l,file_name
D:Tempjmeno_souboru.dmp
set,c,l,include_content
T
append,c,l,type
dm_sysObject
append,c,l,predicate
Folder('/Archiv/Mapy sken',descend)
save,c,l
getmessage,c

Tímto je proveden dump adresáře /Archiv/Mapy sken, který se nachází v docbázi.
Je možné upravit řádku „Folder“ a to takto Folder('/Archiv/Mapy sken'descend) and r_modify_date> date(....) pro to, aby se dumpoval jen obsah adresáře novější než nějaké datum.

Dump objektů docbáze

Kromě dumpu adresářů je možné ještě provést dump dalších součástí repository, například kabinetů. Je potřeba jen upravit volitelnou část skriptu:

append,c,l,type
dm_cabinet
append,c,l,predicate
object_name='jmeno_kabinetu'

Takto můžeme provést dump jednotlivých objektů.

Trasování dumpu

Kromě klasických log souborů které se vytvoří během dumpu, je možné provést trasování běhu dumpu (to v případech, že dochází k nějakým chybám). Pro trasování běhu dump skriptu je možné do skriptu přidat následující příkaz

trace,c,severity_level,logfile

Mohou být použity následující úrovně závažnosti (severity_level):[html]

  • 8 – informace o dumpovaných/loadovaných objektech
  • 10 – timingové informace, commitování po každém loadovaném objektu
  • 11 – informace o load operacích

Také je možné využít SQL trace pro řešení problémů dump a load procesů.
Pro zapnutí SQL trasování se do dump nebo load skriptů na první řádku přidá následující příkaz:

apply,c,NULL,SQL_TRACE,LEVEL,I,1

A pro vypnutí se na poslední řádek dump nebo load skriptu přidá příkaz:

apply,c,NULL,SQL_TRACE,LEVEL,I,0

Preload

Jména filestorů musí souhlasit ve zdrojové i cílové docbázi. Pro generování seznamu filestorů, které je potřeba vytvořit v cílové docbázi před loadem zjistíme spuštěním nástroje preload.
Ten se nachází ve stejném adresáři jako iapi32.exe, tedy $DM_HOMEbin

Spustíme jej následujícím příkazem:

preload jmeno_docbaze -Ujmeno -Pheslo -dump_file jmeno_souboru

Load

Po dokončení dumpu na zdrojové docbázi se přenese dump soubor na cílový server a zde se spustí load.

Před začátkem loadování je nutné se přesvědčit o následujícím:

  • Na cílovém serveru je dostatek volného místa pro data (velikost docbáze se zvětší o ten samý objem, jako má dump soubor)
  • Jsou vytvořeny potřebné filestory, které nám ukázal preload skript
  • Pokud se dump soubor přenášel pomocí FTP, je nutné aby FTP bylo nastaveno na binární přenos
  • Uživatel provádějící load by měl mít práva na čtení/zápis do tohoto souboru

Pro load dat, které byly vydumpovány jedním z předchozích způsobů si napíšeme následující load.api skript:

create,c,dm_load_record
set,c,l,filename
D:Tempjmeno_souboru.dmp
save,c,l
getmessage,c
exit

Jeho umístění je stejné jako v případě dump skriptu na zdrojovém content serveru. Pro jeho spuštění je možné vytvořit opět *.bat dávku se stejným obsahem jako v případě dumpu.
Jen je potřeba upravit jméno docbáze, popřípadě přihlašovací údaje apod.

Závěrečné poznámky

Velikost dump souborů je omezena pouze omezením operačního systému, na kterém běží Documentum Content server.

Cílová docbáze musí mít rozdílné repository ID a jméno od zdrojové docbáze. Jinak by při loadu docházelo ke zbytečným chybám.

V případě rozdílného kódování zdrojové a cílové docbáze je potřeba do dump skriptu přidat následující řádky:

set,c,sessionconfig,session_codepage
codepage

Kde codepage je kódování ve kterém chcete provést dump docbáze (mělo by to být kódování cílové docbáze).

Není možné loadovat část dump souboru.

Pokud při loadu dojde ke zduplikování některých objektů (vznikne nový dokument s jiným r_objedt_id) je možné duplikáty smazat.

Není možné provést dump a load customizací aplikace, které se provádí pomocí DocApp nebo DAR.

Jak je vidět, dump a load docbáze a jejích částí není nic složitého. Jen je potřeba se obrnit trpělivostí, protože při větších oběmech dat trvají obě operace relativně dlouhou dobu.
Z mých zkušeností trvá dump a load adresáře, který má cca 30GB (dump souboru je o stejné velikosti) cca 1 hodinu čistého času, v případě, že nedojde k chybám.

Nicméně i tak je to časově méně náročné než například migrace celé docbáze.

Michal Šika