W przypadku włączenia zmiennej rejestru DB2_FORCE_FCM_BP dla innych użytkowników będzie dostępny o jeden mniej segment pamięci współużytkowanej, a w szczególności dla puli buforów bazy danych. Włączenie zmiennej rejestru DB2_FORCE_FCM_BP powoduje więc redukcję maksymalnej wielkości pul buforów bazy danych. Należy zauważyć, że w związku z dużą liczbą dostępnych segmentów pamięci współużytkowanej środowisku 64-bitowym ta redukcja liczby segmentów pamięci współużytkowanej będzie stanowiła problem tylko w środowiskach 32-bitowych.
| | |Gdy tabela zostanie utworzona po raz pierwszy, dane statystyczne katalogu zostaną ustawione na -1 w celu wskazania, że tabela nie ma danych statystycznych. Do chwili zebrania danych statystycznych program DB2 UDB używa wartości domyślnych podczas kompilacji i optymalizacji instrukcji SQL. | Aktualizacja danych statystycznych tabeli lub indeksu może się nie powieść, jeśli nowe wartości są niespójne z wartościami domyślnymi. W związku z tym przed ręczną aktualizacją danych statystycznych tabeli lub indeksu należy dla nich uruchomić komendę runstats.
| | |Komunikat o błędzie SQL SQL1169N ma nowy kod przyczyny 5 w celu zaznaczenia, że kolumna tabeli wyjaśniania jest za mała.
|Poniższy tekst stanowi aktualizację podręcznika Administration |Guide: Performance, Chapter 6. Understanding the SQL compiler.
|Rozbudowy MDC można użyć nawet, jeśli indeks RID jest częścią planu optymalizacji bez względu na obecność klauzuli WHERE w instrukcji DELETE. |W efekcie podczas wyświetlania warunków, które muszą być spełnione w celu umożliwienia rozbudowy i zastosowania skuteczniejszego sposobu usuwania wierszy, należy usunąć warunek, stanowiący że "Indeks RID nie został wybrany przez optymalizator w celu wyszukania wierszy, które mają zostać usunięte, jeśli nie wybrano klauzuli WHERE w instrukcji DELETE".
|Ponadto można określić, czy rozbudowa MDC została wykonana, ponieważ na wyjściu db2expln zostanie wyświetlona fraza "Cell Delete". | Należy zauważyć, że komenda db2exfmt nie wyświetla tej informacji.
|Poniższy tekst stanowi aktualizację Dodatku A. |Zmienne środowiskowe i rejestru DB2:
|Opis zmiennej DB2_MDC_ROLLOUT należy zmienić w taki sposób, że warunek "Indeks RID nie został wybrany przez optymalizator w celu wyszukania wierszy, które mają zostać usunięte, jeśli nie wybrano klauzuli WHERE w instrukcji DELETE" powinien zostać usunięty z listy.
| | |W przypadku aktualizacji wartości parametru konfiguracji newlogpath, mirrorpath lub overflowlogpath w środowisku programu DB2 UDB Enterprise Server Edition numer węzła zostanie dodany do nazwy ścieżki bez względu na liczbę węzłów w systemie. Dotyczy to zarówno systemów z jedną partycją, jak i z wieloma partycjami w środowisku programu DB2 UDB Enterprise Server Edition.
| | |Wartość domyślna zmiennej DB2_COLLECT_TS_REC_INFO jest równa ON. W programie DB2 UDB, wersja 8.1, pakiet poprawek 7, wartość domyślna zmiennej rejestru DB2_COLLECT_TS_REC_INFO została zmieniona na |ON. W bieżącej dokumentacji została nieprawidłowo podana wartość domyślna tej zmiennej jako OFF.
Instancja programu zarządzającego składa się z frontowego programu narzędziowego i jednego lub wielu demonów. Każda uruchamiana instancja programu zarządzającego jest specyficzna dla instancji menedżera bazy danych. Domyślnie podczas uruchamiania programu zarządzającego na każdej partycji partycjonowanej bazy danych uruchamiany jest jego demon. Można jednak zadecydować, aby demon był uruchamiany tylko na jednej partycji, która ma być monitorowana.
Każdy demon zarządzający gromadzi informacje o aplikacjach, które korzystają z bazy danych. Następnie demon zarządzający porównuje te informacje z regułami określonymi w pliku konfiguracyjnym programu zarządzającego dla tej bazy danych.
Rozważając reorganizację tabel w miejscu (zamiast klasycznej reorganizacji tabel), należy pamiętać, że wymaga ona więcej miejsca na protokół.
Reorganizacja tabel w miejscu wymaga więcej miejsca niż reorganizacja klasyczna, ponieważ wykonywane w jej ramach działania są protokołowane w taki sposób, aby możliwe było odtworzenie danych po nieoczekiwanej awarii.
Ilość miejsca wymagana na protokół reorganizacji w miejscu może kilkakrotnie przekraczać wielkość reorganizowanej tabeli. Ilość miejsca zależy od liczby przenoszonych rekordów oraz od liczby i wielkości indeksów tabeli.
Zalecenie: Reorganizację tabel w miejscu warto wybierać w przypadku konieczności pracy 24 godziny na dobę przez 7 dni w tygodniu przy zachowaniu minimalnego okna konserwacji.
Podczas reorganizacji otwartej tabeli DMS można uruchomić tworzenie kopii zapasowej otwartej bazy danych dla obszaru tabel, w którym znajduje się tabela. W fazie obcinania mogą występować okresy oczekiwania na blokady dla operacji reorganizacji.
Szczegółowe informacje na temat stosowania tych metod reorganizacji tabel można znaleźć w opisach składni komendy REORG TABLE.
W 64-bitowej wersji systemu AIX(R) 5L zmienna rejestru DB2_LARGE_PAGE_MEM obsługuje teraz słowo kluczowe FCM.
Domyślnie w 64-bitowej wersji systemu AIX(R) 5L(TM) pamięć FCM znajduje się w zestawie pamięci menedżera DBMS. Jednak gdy zmienna rejestru DB2_FORCE_FCM_BP jest włączona, pamięć FCM znajduje się w swoim własnym zestawie pamięci. W 64-bitowej wersji systemu AIX 5L(TM) zmienna rejestru DB2_LARGE_PAGE_MEM jest zgodna ze specyfikacją zestawu pamięci menedżera DBMS. Gdy pamięć FCM znajduje się w zestawie pamięci menedżera DBMS i dla tego zestawu pamięci włączona jest obsługa dużych stron, pamięć FCM będzie ulokowana w dużych stronach. Gdy pamięć FCM znajduje się w swoim własnym zestawie pamięci, do wartości zmiennej rejestru DB2_LARGE_PAGE_MEM trzeba dodać słowo kluczowe FCM, aby włączyć duże strony dla pamięci FCM.
Poczynając od wersji 8.2.2 (odpowiednika wersji 8.1 z pakietem poprawek 9) programu DB2 Universal Database(TM) (UDB) plik konfiguracyjny określony przez zmienną rejestru DB2_RESOURCE_POLICY przyjmuje element SCHEDULING_POLICY. Element SCHEDULING_POLICY może być używany na niektórych platformach do wybierania:
Zmienne rejestru DB2PRIORITIES i DB2NTPRICLASS mogą być używane niezależnie od siebie do sterowania strategią planowania systemu operacyjnego i ustawiania priorytetów agentów DB2.
Jednak określenie elementu SCHEDULING_POLICY w pliku konfiguracyjnym strategii zasobów pozwala wybrać w jednym miejscu zarówno strategię planowania, jak i odpowiednie priorytety agentów.
Wybór strategii planowania AIX SCHED_FIFO2 z podwyższonym priorytetem dla procesów zapisu i odczytu protokołu db2:
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Odpowiednik DB2NTPRICLASS=H w systemie Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Wraz z pakietem poprawek 8 zostały dodane systemowe zmienne środowiskowe DB2_MAPPED_BASE i DB2DBMSADDR.
Korzystanie z tych zmiennych rejestru jest zalecane wyłącznie dla zaawansowanych użytkowników.
Jeśli ta zmienna nie zostanie ustawiona, program DB2 UDB będzie próbował przemieścić współużytkowane biblioteki pod adres wirtualny 0x10000000.
Zmienna rejestru może również wskazywać na dowolny adres wirtualny (w kodzie szesnastkowym) w zakresie przestrzeni adresów 31- i 32-bitowych.
db2set DB2_MAPPED_BASE=
Następujący komunikat może wielokrotnie pojawić się w pliku db2diag.log, ponieważ ta zmiana jest wymagana raz dla każdego węzła logicznego:
ADM0506I Program DB2 automatycznie zaktualizował wartość parametru "mapped_base" z wartości "0x40000000(szesnastkowo) 1073741824(dziesiętnie)" na zalecaną wartość "0x10000000(szesnastkowo) 268435456(dziesiętnie)".
Komunikat ten będzie występował tylko wtedy, gdy ustawienie zmiennej rejestru powiedzie się, i będzie zawierał adres, pod który zostały przemieszczone współużytkowane biblioteki.
db2set DB2DBMSADDR=
Zmienną tę można ustawić w powiązaniu ze zmienną DB2_MAPPED_BASE lub samodzielnie w celu dokładnego dostrojenia układu przestrzeni adresowej procesów programu DB2 UDB. Ta zmienna powoduje zmianę położenia pamięci współużytkowanej instancji z jej bieżącego położenia pod adresem wirtualnym 0x20000000 na nową, podaną wartość.
W wersji 8.2 dodano nową zmienną rejestru: DB2TCP_CLIENT_RCVTIMEOUT.
W wersji 8.2 dodano zmienną wydajności DB2_LARGE_PAGE_MEM.
| Nazwa zmiennej | Systemy operacyjne | Wartości |
|---|---|---|
| Opis | ||
| DB2_LARGE_PAGE_MEM |
Tylko AIX 5.x w wersji 64-bitowej Linux |
Wartość domyślna = NULL
Wartość * spowoduje, że wszystkie regiony pamięci będą używały pamięci z dużymi stronami. Zmiennej tej można także przypisać listę oddzielonych przecinkami regionów pamięci, które powinny używać pamięci z dużymi stronami. Dostępne regiony zależą od systemu operacyjnego. W 64-bitowym systemie AIX 5.x można określić następujące regiony: DB, DBMS lub PRIVATE. W systemie Linux można określić region DB. |
|
Region pamięci z dużymi stronami jest obsługiwany tylko przez program DB2 Universal Database (UDB) dla systemu AIX 5L w wersji 64-bitowej i przez program DB2 UDB dla systemu Linux. Zmienna rejestru DB2_LARGE_PAGE_MEM służy do włączenia obsługi dużych stron w systemie AIX 5.x lub w dowolnym systemie Linux z odpowiednim jądrem. Ta zmienna rejestru zastępuje zmienną DB2_LGPAGE_BP, która służy jedynie do włączania pamięci dużych stron tylko dla regionu pamięci współużytkowanej przez bazę danych. Teraz funkcję tę można włączyć, ustawiając DB2_LARGE_PAGE_MEM=DB. Wszelkie informacje w dokumentacji o włączeniu obsługi dużych stron za pomocą zmiennej rejestru DB2_LGPAGE_BP można interpretować jako równoznaczne z ustawieniem DB2_LARGE_PAGE_MEM=DB. Użycie dużych stron jest przede wszystkim przeznaczone do poprawy wydajności w wysokowydajnych aplikacjach. Dzięki użyciu dużych stron w aplikacjach z intensywnym wykorzystaniem pamięci, które potrzebują dużo pamięci wirtualnej, można uzyskać poprawę wydajności. W celu włączenia korzystania z dużych stron w programie DB2 UDB należy najpierw skonfigurować obsługę dużych stron w systemie operacyjnym. Włączenie dużych prywatnych stron w znacznym stopniu zwiększy wykorzystanie pamięci przez program DB2 UDB, ponieważ każdy agent DB2 UDB będzie używał przynajmniej jednej dużej strony (16 MB) pamięci fizycznej. Aby można było włączyć duże strony dla prywatnej pamięci agenta w 64-bitowej wersji programu DB2 UDB dla systemu AIX (ustawienie DB2_LARGE_PAGE_MEM=PRIVATE), muszą być spełnione poniższe warunki (niezależnie od skonfigurowania obsługi dużych stron w systemie operacyjnym):
W 64-bitowej wersji programu DB2 UDB dla systemu AIX włączenie tej zmiennej redukuje wielkość segmentu pamięci współużytkowanej, zmniejszając pamięć bazy danych do minimalnej wymaganej wielkości. Domyślnie tworzony jest segment o wielkości 64 GB: więcej szczegółowych informacji na ten temat zawiera opis parametru konfiguracyjnego określającego wielkość współużytkowanej pamięci bazy danych (database_memory). Pozwala to uniknąć rezerwowania w pamięci RAM większego obszaru pamięci współużytkowanej niż może być potrzebny. Ustawienie tej zmiennej ograniczy możliwość dynamicznego zwiększania ogólnej konfiguracji pamięci współużytkowanej bazy danych (na przykład zwiększania pul buforów). W systemach Linux dodatkowo wymagana jest biblioteka libcap.so. Aby opcja działała, należy tę bibliotekę wcześniej zainstalować. Jeśli opcja jest włączona, a biblioteka nie jest zainstalowana, program DB2 UDB wyłączy duże strony jądra i będzie działał jak poprzednio. Aby w systemie Linux sprawdzić, czy duże strony jądra są dostępne, należy użyć następującej komendy: cat /proc/meminfo Jeśli duże strony są dostępne, powinny zostać wyświetlone trzy wiersze (z różnymi liczbami, zależnie od wielkości pamięci skonfigurowanej na danym komputerze): HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Jeśli wiersze te nie zostaną wyświetlone lub jeśli wartość parametru HugePages_Total wynosi 0, należy skonfigurować system operacyjny lub jądro. |
||
Następująca aktualizacja dotyczy tematu "SQL compiler variables" w Dodatku A, "DB2 registry and environment variables", podręcznika Administration Guide: Performance:
Jeśli jedna lub obie zmienne kompilatora DB2 DB2_MINIMIZE_LISTPREFETCH i DB2_INLIST_TO_NLJN będą miały wartość ON, pozostaną one aktywne nawet w przypadku użycia opcji REOPT(ONCE).
Poniżej zostały podane aktualizacje dokumentacji dotyczące parametrów konfiguracyjnych:
Parametr konfiguracyjny menedżera bazy danych Typ uwierzytelniania (authentication) akceptuje również następujące wartości:
Serwer akceptuje zaszyfrowane schematy uwierzytelniania SERVER i szyfrowanie danych użytkownika. Uwierzytelnianie działa dokładnie tak samo, jak dla wartości SERVER_ENCRYPT.
Podczas korzystania z tego typu uwierzytelniania są szyfrowane następujące dane użytkownika:
Serwer akceptuje zaszyfrowane schematy uwierzytelniania SERVER i szyfrowanie danych użytkownika. Ponadto ten typ uwierzytelniania zapewnia zgodność z wcześniejszymi produktami, które nie obsługują typu uwierzytelniania DATA_ENCRYPT. Te produkty mogą się łączyć z typem uwierzytelniania SERVER_ENCRYPT bez szyfrowania danych użytkownika. Produkty obsługujące nowy typ uwierzytelniania muszą z niego korzystać. Ten typ uwierzytelniania jest poprawny tylko w pliku konfiguracyjnym serwera menedżera bazy danych; nie można go używać w komendzie CATALOG DATABASE.
Poczynając od wersji 8.2 programu DB2 Universal Database domyślna wartość parametru konfiguracji menedżera bazy danych Strategia wpływu na instancję (util_impact_lim) zmienia się ze 100 na 10.
Następujące parametry konfiguracyjne menedżera bazy danych akceptują teraz nazwy grup o długości 30 bajtów (lub mniej) na wszystkich platformach:
Tabela w temacie "Podsumowanie parametrów konfiguracyjnych menedżera bazy danych" zawiera niepoprawne typy danych dla tych parametrów konfiguracji menedżera bazy danych. Prawidłowa wartość we wszystkich tych przypadkach jest równa char(30).
Maksymalna wielkość parametru konfiguracyjnego Rozszerzona wielkość segmentu pamięci masowej bazy danych (estore_seg_size) dla platform opartych na systemie Windows wynosi 16 777 216.
Poprawna wartość górnego limitu parametru konfiguracyjnego bazy danych Wartość limitu czasu HADR (hadr_timeout) jest równa 4 294 967 295.
W dokumentacji dotyczącej parametru konfiguracyjnego bazy danych Maksymalna ilość pamięci masowej dla listy blokad (locklist) znajduje się informacja, że maksymalna wartość dla 64-bitowych i 32-bitowych serwerów systemu Windows, które obsługują tylko lokalnych klientów, jest równa 60 000. Ta wartość jest niepoprawna i powinna wynosić 524 288.
Zakres wartości parametru konfiguracyjnego bazy danych Liczba kopii zapasowych bazy danych (num_db_backups) jest niepoprawny. Poprawny zakres to od 0 do 32 767.
Po przeprowadzeniu migracji z wersji 8.1 do 8.2 programu DB2 Universal Database (UDB) program DB2 UDB będzie używał nowego pliku parametrów konfiguracyjnych bazy danych o wielkości 16 kB i nazwie SQLDBCONF. (W wersji 8.1 plik parametrów konfiguracyjnych bazy danych miał wielkość tylko 4 kB i nazwę SQLDBCON).
Od wersji 8.1 zmienna rejestru DB2_HASH_JOIN jest domyślnie ustawiana na wartość ON.
Należy użyć zmiennej łączenia mieszającego, ale trzeba ją dostroić w celu uzyskania najlepszej wydajności.
Wydajność łączenia mieszającego jest najwyższa, jeśli można uniknąć pętli mieszania i przepełnienia dysku. Aby dostroić wydajność łączenia mieszającego, należy oszacować maksymalną ilość pamięci dostępną dla parametru sheapthres, a następnie dostroić parametr sortheap. Należy zwiększać jego wartość tak, aby uniknąć tylu pętli mieszania i przepełnień dysku, ile tylko możliwe, ale nie można osiągnąć limitu określanego przez parametr sheapthres.
Więcej informacji na ten temat zawiera temat "Join methods" w podręczniku Administration Guide: Performance.
Funkcję realizowaną uprzednio za pomocą zmiennej DB2NTNOCACHE można obecnie realizować na poziomie obszaru tabel, określając klauzulę NO FILE SYSTEM CACHING w instrukcji CREATE TABLESPACE lub ALTER TABLESPACE. Szczegółowe informacje na temat składni tej klauzuli można znaleźć w podręczniku SQL Reference. Zmienna rejestru DB2NTNOCACHE zostanie usunięta w przyszłej wersji.
Tabele wyjaśniania mogą być wspólne dla kilku użytkowników. Są one jednak definiowane dla jednego użytkownika, a dla każdego dodatkowego użytkownika tworzone są aliasy o tej samej nazwie, wskazujące na zdefiniowane tabele. Rozwiązaniem alternatywnym może być zdefiniowanie tabel wyjaśniania w ramach schematu SYSTOOLS. Narzędzie Explain domyślnie używa schematu SYSTOOLS, o ile w ramach identyfikatora sesji użytkownika dla dynamicznego SQL - albo identyfikatora autoryzowanego użytkownika instrukcji dla statycznego SQL - nie zostaną znalezione żadne inne tabele wyjaśniania ani aliasy. Każdy użytkownik współużytkujący tabele wyjaśniania musi mieć uprawnienia do wstawiania danych do tych tabel. Uprawnienia do odczytu wspólnych tabel wyjaśniania również powinny być ograniczone, zwykle do użytkowników, którzy analizują informacje wyjaśniania.
Dane wyjaśniania są przechwytywane, gdy zażąda tego użytkownik podczas kompilowania instrukcji SQL. Wysyłając żądanie danych wyjaśniania, należy zastanowić się nad przewidywanym sposobem wykorzystania przechwyconych informacji.
Informacje dotyczące tabel wyjaśniania są przechwytywane w następujących przypadkach:
Parametr informacji o zestawianiu może być wyświetlany tylko przy użyciu funkcji API db2CfgGet. Nie można go wyświetlić przy użyciu procesora wiersza komend lub Centrum sterowania.
Ten parametr udostępnia 260 bajtów informacji o zestawianiu w bazie danych. Pierwsze 256 bajtów określa kolejność zestawiania bazy danych, gdzie bajt "n" zawiera wagę sortowania punktu kodowego, którego reprezentacja dziesiętna w stronie kodowej bazy danych wynosi "n".
Ostatnie cztery bajty zawierają informacje wewnętrzne o typie kolejności zestawiania. Te cztery bajty parametru collate_info to liczba całkowita. Zależy ona od kolejności endian danej platformy. Możliwe wartości to:
Jeśli istnieje potrzeba skorzystania z tych informacji wewnętrznych, należy rozważyć odwracanie bajtów podczas pobierania informacji dla bazy danych na innej platformie.
Kolejność zestawiania można określić podczas tworzenia bazy danych.
Poczynając od wersji 8.2 programu DB2 Universal Database (UDB) dla obszaru tabel można używać automatycznej wielkości preselekcji, korzystając ze zmiennej AUTOMATIC. Program DB2 UDB automatycznie aktualizuje wielkość preselekcji, jeśli dla obszaru tabel zmieni się liczba kontenerów.
Składnia zmiennej rejestru DB2_PARALLEL_IO została rozszerzona w celu rozpoznawania kontenerów z różnymi charakterystykami paralelizmu wejścia/wyjścia. Dzięki rozszerzonej składni kontenery dla różnych obszarów tabel mogą mieć różne charakterystyki paralelizmu wejścia/wyjścia. Charakterystyka paralelizmu wejścia/wyjścia każdego obszaru tabel jest wykorzystywana, jeśli dla obszaru tabel wielkość preselekcji została określona jako AUTOMATIC. Jeśli zmienna rejestru DB2_PARALLEL_IO jest włączona, ale nie jest używana rozszerzona składnia identyfikująca konkretne charakterystyki paralelizmu wejścia/wyjścia dla obszarów tabel, zostanie przyjęty domyślny poziom paralelizmu. Domyślnym poziomem jest RAID 5 (6+1).
Informacja o wielkości preselekcji wykorzystywana przez optymalizator jest odświeżana tylko, gdy zostanie wykonana instrukcja ALTER TABLESPACE, która zmienia wielkość preselekcji obszaru tabel lub zmienia liczbę kontenerów (za pomocą ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET). Po zmianie liczby dysków fizycznych na kontener w rejestrze należy wykonać instrukcję ALTER TABLESPACE <nazwa obszaru tabel> PREFETCHSIZE AUTOMATIC w celu odświeżenia informacji optymalizatora (o ile została już wykonana instrukcja ALTER TABLESPACE, która odświeża informacje optymalizatora).
Jeśli obszar tabel został przekierowany lub odtworzony w celu korzystania z innej liczby kontenerów, należy odświeżyć informacje optymalizatora wykonując instrukcję ALTER TABLESPACE <nazwa obszaru tabel> PREFETCHSIZE AUTOMATIC. Jeśli w obszarze tabel jest wiele zestawów rozsiania, do obliczenia wielkości preselekcji używana jest maksymalna liczba kontenerów wśród zestawów rozsiania. Jeśli obliczona wielkość preselekcji przekroczy wielkość maksymalną (32 767 stron), jako wielkość preselekcji będzie używana największa wielokrotność liczby kontenerów, która jest mniejsza od wartości maksymalnej.
W środowisku programu DB2 UDB Enterprise Server Edition, jeśli obszar tabel używa wielkości preselekcji AUTOMATIC, wielkość preselekcji może być różna dla różnych partycji bazy danych. Taka sytuacja może występować, ponieważ różne partycje bazy danych mogą mieć różne liczby kontenerów, które są wykorzystywane do obliczania wielkości preselekcji. Aby wygenerować plan dostępu dla zapytania, optymalizator wykorzystuje wielkość preselekcji z pierwszej partycji w grupie partycji bazy danych.
[ Początek strony |Poprzednia strona | Następna strona | Spis treści ]