Podle výchozího nastavení se funkce automatického přesměrování klientů bude opakovaně pokoušet o nové navázání připojení k databázi po dobu 10 minut. Je však možné konfigurovat přesný plán provádění opakovaných pokusů pomocí jedné nebo dvou následujících proměnných registru:
|Pokud je nastavena proměnná DB2_MAX_CLIENT_CONNRETRIES, avšak proměnná DB2_CONNRETRIES_INTERVAL nikoli, bude výchozí hodnotou proměnné DB2_CONNRETRIES_INTERVAL hodnota 30.
|Pokud není nastavena proměnná DB2_MAX_CLIENT_CONNRETRIES, avšak proměnná DB2_CONNRETRIES_INTERVAL ano, bude výchozí hodnotou proměnné DB2_MAX_CLIENT_CONNRETRIES hodnota 10.
|Pokud není nastavena proměnná DB2_MAX_CLIENT_CONNRETRIES ani DB2_CONNRETRIES_INTERVAL, |přejde funkce automatického přesměrování klientů zpět do výchozího režimu popsaného výše.
|Poznámka:
|V případě uživatelů s připojením typu 4 používajících ovladač DB2(R) Universal JDBC |je při konfiguraci funkce automatického přesměrování klientů třeba použít dvě následující vlastnosti zdroje dat:
|Proměnná registru DB2TIMEOUT již není podporována. Tento parametr byl používán k řízení |časového limitu pro klienty systému Windows(R) 3.x a Macintosh při zpracování rozsáhlých dotazů SQL. Tato funkce byla ve výchozím nastavení vypnuta.
| | |Při vytvoření kontejnerů tabulkového prostoru vytvoří produkt DB2 UDB všechny úrovně adresářů, které neexistují.
|Pokud je například specifikován kontejner /project/user_data/container1 a adresář /project přitom neexistuje, vytvoří produkt DB2 UDB adresáře /project a /project/user_data.
|Počínaje verzí produktu DB2 UDB verze 8.2 s opravnou sadou FixPak 4 jsou všechny adresáře vytvořené produktem DB2 UDB vybaveny oprávněními PERMISSION 700. To znamená, že přístup pro operace čtení (read), zápisu (write) a provádění (execute) je umožněn pouze vlastníkovi.
|Při vytváření více instancí postupujte podle následujícího scénáře:
|Vzhledem k tomu, že produkt DB2 UDB vytvořil na základě prvního požadavku úrovně adresářů /project/user_data s oprávněními PERMISSION 700, nemá uživatel user2 k těmto úrovním adresářů přístup a nemůže v těchto adresářích vytvořit kontejner container2. |V tomto případě bude operace CREATE TABLESPACE neúspěšná.
|Existují dva způsoby, jak popsanému konfliktu předejít:
|Formát jmen kontejnerů se změnil takovým způsobem, že současně došlo ke změně ID tabulkových prostorů a ID kontejnerů. Nový formát má následující tvar:
<cesta_k_úložišti>/<instance>/UZEL#### /T####### /C#######.<PŘÍPONA>
, kde:
Od verze DB2(R) Universal Database 8.2.2 (ekvivalentní verzi 8.1 s opravou FixPak 9) lze generované sloupce používat v jedinečných indexech.
Generované sloupce nelze používat v podmínkách, referenčních podmínkách, primárních klíčích a globálních dočasných tabulkách. Tabulky vytvořené pomocí klauzule LIKE a materializovaná zobrazení nedědí vlastnosti generovaných sloupců.
Pokud jste nastavili parametr DB2WORKLOAD=SAP, není automaticky vytvořen uživatelský tabulkový prostor SYSTOOLSPACE ani dočasný uživatelský tabulkový prostor SYSTOOLSTEMPSPACE. Tyto tabulkové prostory se používají pro tabulky vytvářené automaticky následujícími průvodci, obslužnými programy a funkcemi:
Bez tabulkových prostorů SYSTOOLSPACE a SYSTOOLSTEMPSPACE nelze tyto průvodce, obslužné programy a funkce používat.
Chcete-li používat uvedené průvodce, obslužné programy nebo funkce, proveďte některou z následujících akcí:
CREATE REGULAR TABLESPACE SYSTOOLSPACE IN IBMCATGROUP MANAGED BY SYSTEM USING ('SYSTOOLSPACE')
Po provedení nejméně jednoho z těchto kroků vytvořte dočasný uživatelský tabulkový prostor (při použití nastavení DPF opět pouze v uzlu katalogu). Příklady:
CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE IN IBMCATGROUP MANAGED BY SYSTEM USING ('SYSTOOLSTMPSPACE')
Po vytvoření tabulkového prostoru SYSTOOLSPACE a dočasného tabulkového prostoru SYSTOOLSTEMPSPACE můžete začít používat výše uvedené průvodce, obslužné programy a funkce.
Typ ověřování DATA_ENCRYPT_CMP je navržen tak, aby umožnil klientům z předchozí verze, která nepodporuje šifrování dat, připojení k serveru pomocí ověřování SERVER_ENCRYPT namísto DATA_ENCRYPT. Toto ověřování nefunguje, pokud platí následující tři výroky:
V takovém případě se klient nemůže připojit k serveru. Chcete-li umožnit připojení, musíte buď převést klienta na verzi 8, nebo musíte převést bránu na úroveň verze 8 FixPak 6 nebo nižší.
Přímý vstup/výstup (DIO) zlepšuje výkon paměti, protože vynechává ukládání do mezipaměti na úrovni souborového systému. Tento proces snižuje zatížení CPU a zpřístupňuje více paměti instanci databáze.
Souběžný vstup/výstup (CIO) zahrnuje výhody DIO a dále ulehčuje serializaci práv zápisu.
Produkt DB2 Universal Database (UDB) podporuje DIO a CIO v systému AIX a DIO v systémech HP-UX, Solaris Operating Environment, Linux a Windows.
Klíčová slova NO FILE SYSTEM CACHING a FILE SYSTEM CACHING jako součásti příkazů CREATE a ALTER TABLESPACE jazyka SQL vám umožňují zadat, zda se u jednotlivých tabulkových prostorů bude používat vstup/výstup DIO nebo CIO. Je-li používáno klíčové slovo NO FILE SYSTEM CACHING, systém DB2 UDB se pokusí používat souběžný vstup/výstup, kdykoli to bude možné. V případech, kdy vstup/výstup CIO není podporován (například používá-li se systém souborů JFS), bude místo něj použit vstup/výstup DIO.
Další informace naleznete v článku "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX" na následující adrese URL:
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/
Následující informace jsou součástí přílohy B, "Using automatic client rerouting", příručky Administration Guide: Implementation:
Funkce automatického přesměrování klientů produktu DB2 Universal Database pro systémy Linux, UNIX, a Windows umožňuje klientským aplikacím zotavit se z přerušení komunikace pomocí automatického opětného připojení databáze z klienta k serveru. Aplikace tedy mohou pokračovat v práci s minimálním přerušením.
Dojde-li k selhání připojení klienta k serveru, požadavky klienta o nové připojení budou distribuovány sadě systémů definované distributorem nebo dispečerem, jakým je například WebSphere EdgeServer.
Technologii distributora budete zřejmě používat v podobných prostředích:
Klient --> Technologie distributora --> (DB2 Connect Server 1 nebo DB2 Connect Server 2) --> DB2 z/OS
, kde:
Klient je katalogizován prostřednictvím položky DThostname, aby bylo možné použít pro přístup k libovolnému ze serverů DB2 Connect Server technologii distributora. Zprostředkující technologie distributora rozhoduje o použití položky GWYhostname1 nebo GWYhostname2. Jakmile je rozhodnuto, klient získá přímé soketové připojení k jedné z těchto dvou bran DB2 Connect. Jakmile je soketové připojení k vybranému serveru DB2 Connect navázáno, máte typickou propojitelnost klienta k serveru DB2 Connect a k DB2 z/OS.
Předpokládejme například, že distributor vyberte bránu GWYhostname2. Vznikne následující prostředí:
Klient --> DB2 Connect Server 2 --> DB2 z/OS
V případě, že dojde k selhání komunikace, distributor pokus o připojení nezopakuje. Chcete-li v takovém prostředí povolit pro databázi funkci automatického přesměrování klientů, musí být alternativní server pro asociovanou databázi či databáze na serveru DB2 Connect Server (DB2 Connect Server 1 nebo DB2 Connect Server 2) nastaven jako distributor (DThostname). Pokud bude potom server DB2 Connect Server 1 z jakéhokoli důvodu nepřístupný, spustí se funkce automatického přesměrování klientů a zopakuje se pokus o připojení klienta, kde distributorem bude primární i alternativní server. Tato volba vám umožní kombinovat a spravovat vlastnosti distributora pomocí funkce automatického přesměrování klientů v produktu DB2. Nastavení alternativního serveru na jiného hostitele než jméno hostitele distributora bude stále poskytovat klientům funkci automatického přesměrování klientů. Klienti ovšem navážou přímá připojení k zadanému alternativnímu serveru a obejdou tak technologii distributora, což vylučuje distributora a jím uvedenou hodnotu.
Automatické přesměrování klientů zabraňuje výskytu následujících kódů SQL:
Uvažte následující dva aspekty ovlivňující propojitelnost alternativního serveru se serverem DB2:
Aplikace spuštěné pod kontextem lokálního systémového účtu (LSA - local system account) jsou podporovány na všech platformách Windows kromě Windows ME.
Příkazy CONNECT a ATTACH podporují dvoudílná jména uživatelů. Kvalifikátor jména uživatele kompatibilního se standardem SAM je jméno typu NetBIOS, které má maximální délku 15 znaků. Tato funkce není podporována v systému Windows ME.
V operačních systémech UNIX(R) a Linux(TM) můžete přepsat jméno příkazce serveru Kerberos, které používá server DB2(R) Universal Database (UDB). Proměnnou prostředí DB2_KRB5_PRINCIPAL nastavte na požadované úplné jméno příkazce serveru. Instanci je nutné restartovat, protože systém DB2 UDB rozpoznává jméno příkazce serveru až po spuštění příkazu db2start.
Předpoklady podpory Kerberos v systému Linux jsou v dokumentaci popsány nepřesně. Poskytovaný modul plug-in zabezpečení Kerberos produktu DB2 je podporován serverem Red Hat Enterprise Linux Advanced Server 3 s klientem IBM Network Authentication Service (NAS) 1.4.
Pro propojení mezi servery zSeries a iSeries
Ani server zSeries, ani server iSeries nepodporuje vzájemné ověřování.
Ve všech případech administrační protokol DB2 nebo soubor db2diag.log vydá zprávu "Přihlášení se nezdařilo" nebo "Přihlášení bylo odepřeno".
Nelze kontaktovat místní úřad zabezpečení.Chyba je důsledkem toho, že systém Windows vyhledává nejdříve lokálního uživatele. Řešením je zcela zadat uživatele v připojovacím řetězci. Příklad:
jmeno@DOMAIN.IBM.COM
Chcete-li určit, zda jsou účty systému Windows konfigurovány pro použití šifrování DES, vyhledejte část Vlastnosti účtu ve službě Active Directory. Při změně vlastností účtu může být nezbytné restartovat počítač.
host/<jméno_hostitele_serveru>@<jméno_domény_serveru>Příklad:
host/myhost.domain.ibm.com@DOMAIN.IBM.COMJinak bude třeba spustit službu DB2 pod platným účtem domény.