Właściwości bazy danych

Wprowadzenie

Właściwości bazy danych umożliwiają ręczne dostosowanie fizycznego układu tabel i indeksów obiektów biznesowych, instrukcji bazy danych i inicjalizacji nowych połączeń z bazą danych.

Grupa docelowa

• Administratorzy
• Konsultanci techniczni

Opis

Możliwe jest użycie właściwości bazy danych w celu zmiany właściwości dostępu do bazy danych oraz modyfikacji modelu danych.

Właściwości bazy danych są zapisywane w pliku XML.

<?xml version="1.0" encoding="UTF-8"?>
<database>
 <lobsBuffered/>
</database>

Właściwości bazy danych muszą być przechowywane w katalogu klas systemu ERP. Właściwości bazy danych są zapisywane w oddzielnym pliku dla każdej bazy danych. Nazwa pliku to:

properties-<nazwa bazy danych>.xml

Właściwości bazy danych są odczytywane jednorazowo przy pierwszym dostępie do danej bazy danych, tj. po uruchomieniu serwera aplikacji. Jeśli właściwości bazy danych są używane, komunikat jest wyświetlany w dzienniku serwera aplikacji.

Można użyć następującego polecenia, aby wyświetlić dodatkowe dane wyjściowe debugowania dla właściwości bazy danych:

dbgcls -class:com.cisag.sys.kernel.sql.CisDatabaseProperties

Należy zwrócić uwagę, że dane wyjściowe debugowania mogą znacząco obniżyć wydajność serwera aplikacji. Polecenie to powinno być stosowane wyłącznie w systemach testowych.

Tabele i indeksy

System ERP jest niezależny od bazy danych. Dlatego w systemie instalacyjnym nie ma metadanych zależnych od bazy danych dla Business Objects. System ERP generuje tabele i indeksy obiektów biznesowych w oparciu o istniejące metadane dla każdego systemu bazy danych dla większości przypadków użycia.

Dostosuj właściwości fizyczne

W przypadku instalacji z bardzo dużą ilością danych, ręczne dostosowanie fizycznych parametrów tabel i indeksów może poprawić wydajność systemu ERP.

Właściwości bazy danych umożliwiają dołączenie dowolnego ciągu znaków do instrukcji CREATE TABLE lub CREATE INDEX dla każdej tabeli lub indeksu. Jeśli tabela lub indeks są nowo utworzone, zmodyfikowana instrukcja jest wykonywana.

<table>
 <name>ABC</name>
 <physical>ORGANIZATION INDEX</physical>
</table>

<index>
 <name>I123</name>
 <physical>PCTFREE 20</physical>
</index>

Właściwości bazy danych dla tabeli lub indeksu stają się skuteczne dopiero po utworzeniu tabeli lub indeksu, tj. tylko wtedy, gdy narzędzie Reorganizacja obiektów biznesowych (rgzbo) jest wywoływane z opcją -force lub gdy obiekt biznesowy zostanie zmieniony przez aktualizacje oprogramowania lub w systemie deweloperskim.

Narzędzie Wyświetlenie tabel baz danych (dspdbt) wyświetla tabele i nazwy indeksów obiektu biznesowego.

Dostosowanie kolejności kolumn

System zarządzania bazą danych Oracle może rozdzielać kolumny tabeli na wiele bloków w zależności od ich kolejności. W wyniku tego, do odczytania jednego wiersza może być konieczne odczytanie wielu bloków. Dlatego kolumny szczególnie często używane powinny znajdować się razem w jednym bloku, aby np. w zapytaniach wystarczył odczyt tylko jednego bloku.

Przykład:

Kolumny „GUID”, „CODE” i „DESCRIPTION” tabeli „ABC” mają być pierwszymi kolumnami:

<table> 
 <name>ABC</name> 
 <columnSequence> 
  GUID 
  CODE 
  DESCRIPTION 
 </columnSequence> 
</table>

Do obliczenia optymalnej kolejności kolumn na podstawie danych monitoringu należy użyć narzędzia Optymalizacja kolejności kolumn (optclmsqn). Narzędzie to może również zmieniać kolejność kolumn w tabeli w bazie danych.

Nawiązywanie połączenia

Za pomocą właściwości bazy danych można wykonywać dodatkowe polecenia podczas nawiązywania każdego połączenia z bazą danych. Dzięki tym poleceniom możliwa jest modyfikacja właściwości połączeń bazodanowych używanych przez system ERP. Polecenia wykonywane są w takiej kolejności, w jakiej zostały zdefiniowane w pliku XML.

<connectStatement>
 ALTER SESSION SET NLS_COMP='ANSI'
</connectStatement>

Zastępowanie poleceń bazodanowych

Za pomocą właściwości bazy danych można przed wykonaniem zastępować wybrane polecenia bazodanowe innymi. Umożliwia to na przykład wstawienie wskazówek dla optymalizatora lub zmianę kolejności łączeń (JOIN) w poleceniu bazodanowym. Dzięki właściwościom bazy danych optymalizacje te można przeprowadzić bez konieczności zmiany kodu programu systemu ERP.

Zastępowanie poleceń bazodanowych powinno stanowić przypadek wyjątkowy. Wszystkie zamiany, dla których jest to możliwe, należy możliwie najszybciej przenieść, np. jako adaptację, do środowiska deweloperskiego.

<replacement>
 <original>
  SELECT * FROM “ITEM001” WHERE “GUID”=?
 </original>
 <replaced>
  SELECT * FROM XYZ00.”ITEM001” WHERE “GUID”=?
 </replaced>
</replacement>

Awaria bazy danych (Database-Failover)

Obsługiwane systemy zarządzania bazami danych (DBMS) udostępniają różne mechanizmy obsługi awarii bazy danych (Failover). Funkcjonalność oferowana przez DBMS nie zawsze jednak zapewnia oczekiwany przez użytkownika poziom niezawodności.

System ERP udostępnia opcjonalne, aktywowane funkcje, które mogą zwiększyć poziom niezawodności podczas obsługi awarii bazy danych (Database-Failover).

Monitor transakcji

Monitor transakcji zwiększa niezawodność przy operacjach zapisu wykonywanych przez system ERP. Dzięki monitorowi transakcji możliwe jest rozpoznanie w przypadku błędu, czy transakcja zapisu została wykonana pomyślnie, czy zakończyła się niepowodzeniem. W sytuacji niepowodzenia transakcja zapisu jest ponawiana.

<transactionMonitor/>

Buforowanie LOB

Niektóre systemy zarządzania bazami danych (np. Oracle 10 i 11) nie są w stanie zapewnić niezawodności obsługi awarii bazy danych (Database-Failover) w przypadku zapytań z dużymi obiektami binarnymi lub tekstowymi (BLOB lub CLOB, łącznie określane jako LOB). System ERP może zwiększyć niezawodność przy dostępie do kolumn LOB poprzez buforowanie ich zawartości.

Buforowanie LOB dotyczy odczytu danych za pośrednictwem Business Objects oraz odczytu z Knowledge Store. Odczyt realizowany poprzez ODBC-SQL lub OQL nie jest zabezpieczany przez system ERP. Oznacza to, że większość aplikacji interaktywnych oraz aplikacji działających w tle staje się zabezpieczona przed awarią przy zastosowaniu buforowania LOB, nawet jeśli DBMS nie obsługuje Failover dla obiektów LOB. Jednak generowanie dokumentów, raportów oraz aplikacje typu Lista mogą przerywać działanie mimo aktywnego buforowania LOB.

Buforowanie LOB zwiększa zapotrzebowanie na pamięć serwera aplikacji oraz może powodować dodatkowe operacje na systemie plików serwera aplikacji.

<lobsBuffered/>

Limit czasu przełączenia awaryjnego (Failover-Timeout)

System zarządzania bazą danych (DBMS) może być tymczasowo niedostępny w trybie produkcyjnym. W takim przypadku przez określony czas nawiązanie połączenia z systemem zarządzania bazą danych nie jest możliwe. Można ustawić, jak długo serwer aplikacji ma próbować nawiązać połączenie z systemem DBMS. Po upływie tego czasu, aplikacja, która zażądała połączenia z bazą danych, zostanie zazwyczaj przerwana z komunikatem o błędzie.

Czas trwania podaje się jako wartość liczbową w minutach. Jeśli wartość nie zostanie podana, serwer aplikacji będzie próbował nawiązać połączenie bez ograniczenia czasowego.

<failoverTimeout>5</failoverTimeout>

<failoverTimeout/>

Wykrywanie błędów bazy danych

System ERP analizuje komunikaty o błędach bazy danych. Na podstawie numeru błędu system może na przykład rozpoznać, czy należy zainicjować przełączenie awaryjne (failover) bazy danych. Komunikaty o błędach bazy danych wraz z ich znaczeniem są na stałe zakodowane w systemie ERP. W razie potrzeby można dodać do systemu ERP dodatkowe komunikaty o błędach.

Obsługiwane są następujące typy komunikatów o błędach:

Komunikat o błędzie jest identyfikowany za pomocą SQL-State i numeru błędu. W przypadku błędu bazy danych system wyświetla stan SQL-State i numer błędu. W celu wykrycia błędu należy podać co najmniej jedną z tych wartości. Gdy wystąpi błąd bazy danych, dzieje się co następuje:

• Sprawdzane jest, czy wystąpił błąd rozpoznany przez system ERP. Jeśli tak, używany jest ten typ błędu.
• Następnie sprawdzane jest, czy błąd został zdefiniowany we właściwościach bazy danych. Jeśli wszystkie określone właściwości pasują do błędu, używany jest odpowiedni typ błędu.
• Błąd jest traktowany jako błąd nierozpoznany.

<exception>
 <type>CONNECTION_LOST</type>
 <errorCode>937</errorCode>
 <sqlState>42000</sqlState>
</exception>

Optymalizacja zmian w modelu danych

Zmiany w modelu danych mogą być czasochłonne, zwłaszcza przy przejściu na nowszą wersję oprogramowania. Dzięki właściwościom bazy danych można skrócić ten czas, rezygnując z zachowania integralności transakcji w części procesu przechodzenia na nowszą wersję.

Oracle: ALTER TABLE vs. CREATE TABLE AS SELECT

Tworzenie nowych kolumn ze stałą wartością początkową, usuwanie kolumn oraz wydłużanie atrybutów typu string jest zazwyczaj realizowane za pomocą polecenia ALTER TABLE.

W przypadku baz danych Oracle, zamiast używać ALTER TABLE, można wprowadzić zmiany w modelu danych za pomocą polecenia CREATE TABLE AS SELECT oraz tymczasowej tabeli. Takie rozwiązanie wymaga więcej miejsca na dysku w bazie danych, ale może prowadzić do mniejszego obciążenia dysku, szczególnie w przypadku zastosowania właściwości <updateOracleNoLogging> lub <updateOracleParallel>.

Przykład:

Wybierz CREATE_TABLE_AS zamiast ALTER_TABLE:

<updateTable>
 CREATE_TABLE_AS
</updateTable>

Oracle: NOLOGGING

Podczas tworzenia indeksów i używania polecenia CREATE TABLE AS SELECT można wykorzystać opcję NOLOGGING, która wyłącza zapis do dziennika archiwalnego (Archive Log). Wyłączenie tej funkcji znacznie przyspiesza te operacje. Jeśli jednak baza danych standardowo zapisuje dziennik archiwalny, użycie tej opcji sprawi, że stanie się on niespójny. Niespójny dziennik archiwalny może prowadzić do problemów, na przykład w bazach danych standby lub podczas odtwarzania danych z kopii zapasowej.

<updateOracleNoLogging/>

Oracle: PARALLEL

Tworzenie indeksów i używanie polecenia CREATE TABLE AS SELECT można przyspieszyć poprzez ich zrównoleglenie za pomocą opcji PARALLEL. Paralelizacja jest obsługiwana w bazach danych Oracle w wersji Enterprise Edition.

<updateOracleParallel>PARALLEL 4</updateOracleParallel>

iSeries: ALTER TABLE no commit

W przypadku wprowadzania zmian w modelu danych za pomocą polecenia ALTER TABLE na serwerach iSeries, można wyłączyć mechanizm dziennika za pomocą właściwości <updateAlterTableNoCommit/>. Znacznie przyspiesza to wprowadzanie modyfikacji.

<updateAlterTableNoCommit/>

Dostosowywanie połączeń z bazą danych

Zazwyczaj podczas instalacji systemu testowego lub produkcyjnego u klienta używa się kopii systemu deweloperskiego lub testowego systemu deweloperskiego. Baza konfiguracyjna, która jest importowana w ramach takiej instalacji, zwykle nie zawiera danych połączeniowych pasujących do systemu klienta. Poniższe właściwości systemowe umożliwiają dostosowanie tych danych.

Właściwości te zawierają nazwę obiektu biznesowego, nazwę bazy danych oraz ścieżkę atrybutu, który ma zostać dostosowany:

com.cisag.sys.configuration.obj.Database.<NazwaBazyDanych>.<ŚcieżkaAtrybutu>
com.cisag.sys.configuration.obj.SVMDBConnection.<NazwaBazyDanych>.<ŚcieżkaAtrybutu>

Wartość <NazwaBazyDanych> należy zastąpić nazwą bazy danych w odpowiedniej bazie konfiguracyjnej. Wartość <ŚcieżkaAtrybutu> należy zastąpić techniczną nazwą atrybutu, który ma zostać zmieniony. Pożądaną wartość atrybutu podaje się jako ciąg znaków.

Po uruchomieniu systemu z połączeniem do bazy danych dostosowanym za pomocą wymienionych właściwości, można przenieść te ustawienia do bazy konfiguracyjnej za pomocą następującego polecenia:

wrksysprp -update

Za pomocą następującego polecenia można wyeksportować właściwości systemu do pliku. W tym pliku można w wygodny sposób edytować połączenia z bazami danych:

wrksysprp -export:C:\temp\my.properties

Podczas instalacji nowego systemu z kopii innego systemu, należy zaimportować bazy danych z nazwami nowego systemu.

Polecenie wrksysprp –renameDatabases służy do zmiany nazw baz danych w bazie danych konfiguracji, tak aby odpowiadały nazwom schematów bazy danych.

Instrukcja: Tworzenie tabel i indeksów

Wymagania wstępne

Podczas wprowadzania lub modyfikowania właściwości bazy danych w celu tworzenia tabel lub indeksów, należy ponownie utworzyć wszystkie tabele, których dotyczy zmiana, za pomocą narzędzia Reorganizacja obiektów biznesowych (rgzbo). Należy przy tym bezwzględnie przestrzegać następujących wytycznych:

• wszystkie zmiany należy przetestować na systemie testowym, zanim zostaną wdrożone na systemie produkcyjnym.
• należy wykonać kopię zapasową bazy danych.

Instrukcja:

1. Umieść plik właściwości bazy danych, przeznaczony dla bazy db, o nazwie properties-<db>.xml w katalogu classes w systemie.
2. Zakończ działanie wszystkich serwerów aplikacji z wyjątkiem serwera wiadomości (Message-Server).
3. Upewnij się, że do serwera wiadomości nie są zalogowani żadni użytkownicy i nie są uruchomione żadne zlecenia przetwarzania.
4. Dla wszystkich obiektów biznesowych x1, …, xn i bazy danych db wykonaj następujące polecenia w narzędziu Toolshell:

• rgzbo -force -db:<db> -o:<x1>
• …
• rgzbo -force -db:<db> -o:<xn>

5. Uruchomić ponownie serwer wiadomości i wszystkie serwery aplikacji.
6. Sprawdzić czy tabele zostały pomyślnie utworzone.