Administrace: Implementace

Konfigurace funkce automatického přesměrování klientů (proměnná DB2_MAX_CLIENT_CONNRETRIES a DB2_CONNRETRIES_INTERVAL)

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:

|
• DB2_MAX_CLIENT_CONNRETRIES: Maximální počet opakovaných pokusů o připojení provedených funkcí automatického přesměrování klientů.
|
• DB2_CONNRETRIES_INTERVAL: Doba nečinnosti (v sekundách) mezi jednotlivými pokusy o připojení.

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:

|
• maxRetriesForClientReroute: Pomocí této vlastnosti lze omezit počet opakovaných pokusů pro případy selhání primárního připojení k serveru. Tuto vlastnost lze použít pouze v případě, že je také použita vlastnost retryIntervalClientReroute.
|
• retryIntervalForClientReroute: Pomocí této vlastnosti můžete specifikovat dobu nečinnosti mezi opakovanými pokusy (v sekundách). Tuto vlastnost lze použít pouze v případě, že je také použita vlastnost maxRetriesForClientReroute.

Proměnná registru DB2TIMEOUT - vysvětlení

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.

Adresáře vytvořené při vytvoření kontejneru tabulkového prostoru

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:

|
1. Předpokládejme například, že při použití výše uvedené struktury adresářů neexistují úrovně adresářů /project/user_data.
|
2. Uživatel user1 vytvoří instanci s výchozím názvem user1, dále databázi a poté vytvoří tabulkový prostor obsahující kontejner /project/user_data/container1.
|
3. Uživatel user2 vytvoří instanci s výchozím názvem user2, dále databázi |a poté se pokusí vytvořit tabulkový prostor obsahující kontejner /project/user_data/container2.

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:

|
1. Před vytvořením tabulkových prostorů vytvořte adresář /project/user_data a jako hodnotu oprávnění zadejte jakoukoli hodnotu, která umožní vytvoření tabulkových prostorů oběma uživatelům user1 a user2. Pokud všechny úrovně adresáře tabulkového prostoru existují, produkt DB2 UDB přístupová oprávnění nezmění.
|
2. Poté, co uživatel user1 vytvoří kontejner /project/user_data/container1, nastavte jako oprávnění adresáře /project/user_data jakoukoli hodnotu umožňující uživateli user2 vytvořit tabulkový prostor.

Automatické ukládání

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:

• /T####### je ID tabulkového prostoru. Například T0000003.
• /C####### je ID kontejneru. Například C0000012.

Definice generovaného sloupce v existující tabulce

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ů.

Agregační proměnné registru

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:

• Automatická údržba,
• Poradce s návrhem,
• panel informací o databázi Řídicího centra,
• uložená procedura SYSINSTALLOBJECTS, pokud není zadán vstupní parametr tabulkového prostoru,
• uložená procedura GET_DBSIZE_INFO.

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í:

• Ručně vytvořte tabulkový prostor SYSTOOLSPACE (při použití nastavení DPF pouze v uzlu katalogu). Příklady:

     CREATE REGULAR TABLESPACE SYSTOOLSPACE 
        IN IBMCATGROUP 
        MANAGED BY SYSTEM 
        USING ('SYSTOOLSPACE')

• Vytvořte objekty pro každé z následujících jmen nástrojů voláním funkce SYSINSTALLOBJECTS s uvedením platného tabulkového prostoru: "DB2AC", "POLICY" a " STMG_DBSIZE_INFO"

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.

Aspekty ověřování pro vzdálené klienty

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:

• Klient je na úrovni verze 7.2.
• Brána je na úrovni verze 8 FixPak 7 nebo vyšší.
• Server je na úrovni 8 FixPak 7 nebo vyšší.

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žší.

Podpora přímého vstupu a výstupu (DIO) a souběžného vstupu a výstupu (CIO)

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/

Technologie distributora a automatické přesměrování klientů

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:

• Komponenta technologie distributora má jméno hostitele TCP/IP DThostname
• Server DB2 Connect Server 1 má jméno hostitele TCP/IP GWYhostname1
• Server DB2 Connect Server 2 má jméno hostitele TCP/IP GWYhostname2
• Server DB2 z/OS server má jméno hostitele TCP/IP zOShostname

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:

• sqlcode -20157
• sqlcode -1768 (kód příčiny = 7)

Aspekty automatického přesměrování klientů pro katalogizaci na serveru DB2 Connect

Uvažte následující dva aspekty ovlivňující propojitelnost alternativního serveru se serverem DB2:

• První aspekt se týká použití serveru DB2 Connect pro poskytování přístupu k hostitelské databázi nebo databázi iSeries namísto vzdáleného a lokálního klienta. V takových situacích může dojít k nesrovnalostem kvůli záměně informací o propojitelnosti alternativního serveru v položce systémového adresáře databází. Chcete-li tyto nesrovnalosti minimalizovat, zvažte možnost katalogizace dvou položek v systémovém adresáři databází, které by reprezentovaly stejnou hostitelskou databázi nebo databázi iSeries. Jednu položku katalogizujte pro vzdálené klienty a druhou pro klienty lokální.
• Za druhé, informace alternativního serveru, které jsou vráceny z cílového serveru, se uchovávají pouze v mezipaměti. Je-li proces DB2 ukončen, informace v mezipaměti, a tedy i informace alternativního serveru, budou ztraceny.

Podpora lokálního systémového účtu (Windows)

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.

Podpora dvoudílného jména uživatele

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.

Podrobnosti ověřování Kerberos

Další informace o podpoře Kerberos