Podręcznik Administration Guide: Implementation

Konfigurowanie automatycznego przekierowywania klienta (DB2_MAX_CLIENT_CONNRETRIES i DB2_CONNRETRIES_INTERVAL)

Domyślnie opcja automatycznego przekierowywania klienta ponawia połączenie z bazą danych przez okres do 10 minut. Można jednak dokładnie skonfigurować zachowanie podczas ponawiania za pomocą jednej lub obu następujących dwóch zmiennych rejestru:

|
• DB2_MAX_CLIENT_CONNRETRIES: Maksymalna liczba prób ponowienia połączenia wykonywanych przez funkcję automatycznego przekierowania klienta.
|
• DB2_CONNRETRIES_INTERVAL: Czas uśpienia między kolejnymi próbami ponowienia połączenia podany w sekundach.

Jeśli ustawiona jest wartość parametru DB2_MAX_CLIENT_CONNRETRIES, a wartość parametru DB2_CONNRETRIES_INTERVAL nie jest ustawiona, dla parametru |DB2_CONNRETRIES_INTERVAL zostanie przyjęta wartość domyślna równa 30.

Jeśli nie jest ustawiona wartość parametru DB2_MAX_CLIENT_CONNRETRIES, a wartość parametru DB2_CONNRETRIES_INTERVAL jest ustawiona, dla parametru |DB2_MAX_CLIENT_CONNRETRIES zostanie przyjęta wartość domyślna równa 10.

Jeśli nie jest ustawiona wartość parametru DB2_MAX_CLIENT_CONNRETRIES, ani DB2_CONNRETRIES_INTERVAL, opcja automatycznego przekierowania klienta powróci do opisanego poprzednio zachowania domyślnego.

Uwaga:

Użytkownicy połączenia typu 4 ze sterownikiem uniwersalnym JDBC DB2^(R) powinni użyć następujących dwóch właściwości źródła danych w celu skonfigurowania automatycznego przekierowania klienta:

|
• maxRetriesForClientReroute: Ta właściwość służy do ograniczenia liczby ponownych prób w przypadku niepowodzenia podstawowego połączenia z serwerem. Ta właściwość jest używana tylko, gdy zostanie również ustawiona właściwość retryIntervalClientReroute.
|
• retryIntervalForClientReroute: Ta właściwość służy do określenia (w sekundach) czasu uśpienia przed ponowieniem próby. Ta właściwość jest używana tylko, gdy zostanie również ustawiona właściwość maxRetriesForClientReroute.

Opis zmiennej rejestru DB2TIMEOUT

Zmienna rejestru DB2TIMEOUT nie jest już obsługiwana. To ustawienie było wykorzystywane do sterowania długością limitu czasu dla klientów systemu Windows^(R) 3.x i Macintosh w trakcie długich zapytań SQL. Ta opcja została domyślnie wyłączona.

Katalogi tworzone podczas tworzenia przestrzeni dyskowej obszaru tabel

Podczas tworzenia przestrzeni dyskowej obszaru tabel program DB2 UDB tworzy wszelkie poziomy katalogu, które nie istnieją.

Jeśli na przykład kontener został określony jako /projekt/dane_użytkownika/kontener1, a katalog /projekt nie istnieje, program DB2 UDB utworzy katalogi /projekt i /projekt/dane_użytkownika.

Poczynając od programu DB2 UDB, wersja 8.2, pakiet poprawek 4, wszelkie katalogi utworzone prze program DB2 UDB są tworzone z ustawieniem PERMISSION 700. Oznacza to, że tylko właściciel ma dostęp do odczytu, zapisu i wykonania.

Podczas tworzenia wielu instancji należy zwrócić uwagę na następujący scenariusz:

|
1. Korzystając z takiej samej struktury katalogu, jak powyżej, załóżmy, że nie istnieją poziomy katalogu /projekt/dane_użytkownika.
|
2. Użytkownik1 tworzy instancję o domyślnej nazwie użytkownik1, a następnie tworzy bazę danych, po czym tworzy obszar tabel mający /projekt/dane_użytkownika/kontener1 jako jeden z kontenerów.
|
3. Użytkownik2 tworzy instancję o domyślnej nazwie użytkownik2, a następnie tworzy bazę danych, po czym próbuje utworzyć obszar tabel mający /projekt/dane_użytkownika/kontener2 jako jeden z kontenerów.

Ponieważ program DB2 UDB utworzył poziomy katalogu /projekt/dane_użytkownika z ustawieniem |PERMISSION 700 dla pierwszego żądania, użytkownik2 nie ma dostępu do tych poziomów katalogu i nie może utworzyć kontenera kontener2 w tych katalogach. | W takim przypadku operacja CREATE TABLESPACE nie powiedzie się.

Istnieją dwie metody rozwiązania tego konfliktu:

|
1. Należy utworzyć katalog /projekt/dane_użytkownika przed utworzeniem obszarów tabel i ustawienia uprawnienia dla jakiegokolwiek dostępu niezbędnego zarówno dla użytkownika1, jak i użytkownika2 do utworzenia obszarów tabel. Jeśli istnieją wszystkie poziomy katalogu obszaru tabel, program DB2 UDB nie zmodyfikuje dostępu.
|
2. Po utworzeniu przez użytkownika1 kontenera /projekt/dane_użytkownika/kontener1 należy ustawić uprawnienie dla katalogu /projekt/dane_użytkownika na dowolny poziom dostępu niezbędny do utworzenia obszaru tabel przez użytkownika2.

Automatyczne wykorzystanie pamięci

Format nazw kontenerów zmienił się taki sposób, że zmianie ulega także identyfikator obszaru tabel i identyfikator kontenera. Nowy format jest następujący:

<ścieżka pamięci>/<instancja>/WĘZEŁ####
/T#######
/C#######.<EXT>

gdzie:

• /T####### jest identyfikatorem obszaru tabel. Na przykład T0000003.
• /C####### jest identyfikatorem kontenera. Na przykład C0000012.

Definiowanie kolumny generowanej w istniejącej tabeli

Począwszy od wersji 8.2.2 programu DB2^(R) Universal Database (równoważnej wersji 8.1 z pakietem poprawek 9) kolumny generowane mogą być używane w indeksach unikalnych.

Kolumny generowane nie mogą być używane w ograniczeniach, ograniczeniach referencyjnych, kluczach podstawowych i globalnych tabelach tymczasowych. Tabela utworzona przy użyciu klauzuli LIKE widoków materializowanych nie dziedziczy właściwości kolumny generowanej.

Zagregowane zmienne rejestru

Obszar tabel użytkownika SYSTOOLSPACE ani tymczasowy obszar tabel SYSTOOLSTEMPSPACE nie są tworzone automatycznie po ustawieniu zmiennej DB2WORKLOAD=SAP. Te obszary tabel są używane dla tabel tworzonych automatycznie przez następujących kreatorów, narzędzia lub funkcje:

• Konserwacja automatyczna
• Doradca projektowania
• Panel informacyjny bazy danych w Centrum sterowania
• Procedura zapisana w bazie SYSINSTALLOBJECTS, jeśli nie określono obszaru tabel jako parametru wejściowego
• Procedura zapisana w bazie GET_DBSIZE_INFO

Bez obszarów SYSTOOLSPACE i SYSTOOLSTEMPSPACE nie jest możliwe korzystanie z tych kreatorów, narzędzi lub funkcji.

Aby możliwe było używanie kreatorów, narzędzi lub funkcji, należy wykonać jedną z następujących czynności:

• Ręcznie utworzyć obszar SYSTOOLSPACE (w przypadku użycia DPF - tylko na węźle katalogu). Na przykład:

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

• Wywołać procedurę SYSINSTALLOBJECTS w celu utworzenia obiektów, określają poprawny obszar tabel dla każdej z następujących nazw narzędzi: "DB2AC", "POLICY" i "STMG_DBSIZE_INFO"

Po zakończeniu co najmniej jednej z powyższych operacji należy utworzyć tymczasowy obszar tabel użytkownika (w przypadku korzystania z DPF - tylko na węźle katalogu). Na przykład:

   CREATE USER TEMPORARY TABLESPACE SYSTOOLSTMPSPACE 
      IN IBMCATGROUP 
      MANAGED BY SYSTEM 
      USING ('SYSTOOLSTMPSPACE')

Po utworzeniu obszaru tabel SYSTOOLSPACE i tymczasowego obszaru tabel SYSTOOLSTEMPSPACE można używać kreatorów, narzędzi lub funkcji wymienionych powyżej.

Zagadnienia dotyczące uwierzytelniania zdalnych klientów

Typ uwierzytelniania DATA_ENCRYPT_CMP został wprowadzony w celu umożliwienia klientom w poprzedniej wersji, która nie obsługuje szyfrowania danych, łączenie się z serwerem za pomocą uwierzytelniania SERVER_ENCRYPT zamiast uwierzytelniania DATA_ENCRYPT. To uwierzytelnianie nie działa, jeśli poniższe stwierdzenia są prawdziwe:

• Klient jest w wersji 7.2.
• Brama jest w wersji 8, pakiet poprawek 7, lub nowszej.
• Serwer jest w wersji 8, pakiet poprawek 7, lub nowszej.

W takim przypadku klient nie może połączyć się z serwerem. Aby umożliwić połączenie, należy albo zaktualizować klienta do wersji 8, albo zapewnić, że brama będzie w wersji 8, pakiet poprawek 6, lub starszej.

Obsługa bezpośredniego we/wy (DIO) i współbieżnego we/wy (CIO)

Bezpośrednie we/wy (DIO) poprawia wydajność pamięci dzięki pomijaniu buforowania na poziomie systemu plików. Ten proces redukuje nakład pracy jednostki centralnej i udostępnia większą ilość pamięci instancji bazy danych.

Współbieżne we/wy (CIO) ma wszystkie zalety DIO, a ponadto upraszcza szeregowanie dostępów do zapisu.

Program DB2 Universal Database (UDB) obsługuje DIO i CIO w systemie AIX oraz DIO w systemach HP-UX, Środowisku Operacyjnym Solaris, Linux i Windows.

Parametry NO FILE SYSTEM CACHING FILE SYSTEM CACHING stanowią elementy instrukcji SQL CREATE i ALTER TABLESPACE i umożliwiają określenie, czy dla danego obszaru tabel ma być używane DIO, czy CIO. Gdy obowiązuje ustawienie NO FILE SYSTEM CACHING, DB2 UDB próbuje używać współbieżnego we/wy, gdy tylko jest to możliwe. W sytuacji, gdy CIO nie jest obsługiwane (np. jeśli używany jest system plików JFS), używane jest we/wy DIO.

Więcej informacji na ten temat zawiera artykuł "Improve database performance on file system containers in IBM DB2 UDB Stinger using Concurrent I/O on AIX", który można znaleźć pod następującym adresem URL:

http://www.ibm.com/developerworks/db2/library/techarticle/dm-0408lee/

Technologia dystrybucji i automatyczne przekierowanie klientów

Następujące informacje stanowią część podręcznika Administration Guide: Implementation, Dodatek B, "Using automatic client rerouting":

Opcja automatycznego przekierowania klienta programu DB2 Universal Database dla systemów Linux, UNIX i Windows umożliwia aplikacjom klienckim odtworzenie stanu po przerwaniu połączenia z serwerem poprzez automatyczne ponowne nawiązanie połączenia bazy danych klienta z serwerem, dzięki czemu mogą one kontynuować działanie po minimalnej przerwie.

Jeśli połączenie klienta z serwerem zostanie przerwane, żądania ponownego połączenia klienta są dystrybuowane do zdefiniowanego zbioru systemów przez program dystrybucyjny lub rozsyłający, taki jak WebSphere EdgeServer.

Technologii dystrybucji można używać w środowisku zbliżonym do poniższego:

Klient --> technologia dystrybucji --> (serwer DB2 Connect Server 1 lub serwer DB2 Connect Server 2) --> DB2 z/OS

gdzie:

• Komponent technologii dystrybucji ma nazwę hosta TCP/IP równą DThostname
• Serwer DB2 Connect Server 1 ma nazwę hosta TCP/IP równą GWYnazwa_hosta1
• Serwer DB2 Connect Server 2 ma nazwę hosta TCP/IP równą GWYnazwa_hosta2
• Serwer DB2 z/OS ma nazwę hosta TCP/IP równą zOSnazwa_hosta

Klient jest wpisywany do katalogu z nazwą DThostname, aby można było wykorzystać technologię dystrybucji w celu uzyskania dostępu do dowolnego z serwerów DB2 Connect. Jeśli technologia dystrybucji jest aktywna, decyzja o użyciu serwera GWYnazwa_hosta1 lub GWYnazwa_hosta2 jest podejmowana przez oprogramowanie. Po podjęciu decyzji klient uzyskuje bezpośrednie połączenie przez gniazdo z jedną z dwóch bram DB2 Connect. Po nawiązaniu połączenia przez gniazdo z wybranym serwerem DB2 Connect powstaje typowe połączenie klienta z serwerem DB2 Connect dla DB2 z/OS.

Na przykład przyjmijmy, że program dystrybucyjny wybrał GWYnazwa_hosta2. Tworzy to następujące środowisko:

Klient --> serwer DB2 Connect Server 2 --> DB2 z/OS

Program dystrybucyjny nie wznawia żadnego połączenia, jeżeli wystąpi jakakolwiek awaria komunikacji. Jeśli dla bazy danych w takim środowisku należy włączyć opcję automatycznego przekierowania klienta, alternatywny serwer dla powiązanej bazy danych lub baz danych na serwerze DB2 Connect Server (serwer DB2 Connect Server 1 lub serwer DB2 Connect Server 2) powinien zostać ustawiony tak, aby był nim program dystrybucyjny (DThostname). Następnie, jeśli serwer DB2 Connect Server 1 zablokuje się z jakiegoś powodu, zostanie wyzwolone automatyczne przekierowanie klienta i nastąpi próba połączenia klienta z programem dystrybucyjnym zarówno dla serwera podstawowego, jak i alternatywnego. Ta opcja umożliwia zachowanie możliwości programu dystrybucyjnego i jego połączenie z opcją DB2 automatycznego przekierowania klienta. Nawet jeśli nazwa serwera alternatywnego będzie inna niż nazwa hosta programu dystrybucyjnego, klienci nadal będą mogli korzystać z opcji automatycznego przekierowania klienta. Jednak klienci będą nawiązywać bezpośrednie połączenia ze zdefiniowanym serwerem alternatywnym i pomijać technologię dystrybucji, co spowoduje wyeliminowanie programu dystrybucyjnego i zapewnianych przez niego korzyści.

Automatyczne przekierowanie klienta spowoduje przechwycenie następujących kodów sql:

• sqlcode -20157
• sqlcode -1768 (kod przyczyny = 7)

Uwagi dotyczące automatycznego przekierowywania klienta w celu wpisania go do katalogu na serwerze DB2 Connect

Należy pamiętać o poniższych uwagach dotyczących połączenia serwera alternatywnego z serwerem DB2 Connect:

• Pierwsza uwaga dotyczy korzystania z serwera DB2 Connect w celu zapewnienia dostępu do bazy danych na hoście lub w systemie iSeries w imieniu klientów zarówno zdalnych, jak i lokalnych. W takich sytuacjach może powstać niejasność co do informacji o połączeniu z serwerem alternatywnym w pozycji systemowego katalogu bazy danych. Aby zminimalizować tę niejasność, należy wziąć pod uwagę możliwość wpisania do katalogu dwóch pozycji z systemowego katalogu bazy danych, reprezentujących tę samą bazę danych na hoście lub w systemie iSeries. Jedną pozycję należy wpisać do katalogu dla klientów zdalnych, a drugą dla klientów lokalnych.
• Po drugie, informacje o serwerze alternatywnym zwracane z serwera docelowego są przechowywane tylko w pamięci podręcznej. W razie zakończenia procesu DB2, informacje z pamięci podręcznej, i tym samym informacje o serwerze alternatywnym, zostaną utracone.

Obsługa lokalnych kont systemowych (Windows)

Aplikacje działające w kontekście lokalnego konta systemowego (Local System Account - LSA) są obsługiwane we wszystkich systemach Windows, oprócz Windows ME.

Obsługa dwuczęściowych identyfikatorów użytkowników

Instrukcja CONNECT i komenda ATTACH obsługują dwuczęściowe identyfikatory użytkowników. Kwalifikator zgodnego z SAM identyfikatora użytkownika jest nazwą w stylu protokołu NetBIOS o maksymalnej długości 15 znaków. Ta opcja nie jest obsługiwana w systemie Windows ME.

Szczegóły dotyczące uwierzytelniania Kerberos

Dodatkowe informacje na temat obsługi protokołu Kerberos