załacznik nr3

EDZ.242-66/10 Załącznik nr 3 – Wymogi dotyczące bazy danych i środowiska serwerowego
ZAŁĄCZNIK NR 3 – WYMOGI DOTYCZĄCE BAZY DANYCHI ŚRODOWISKA SERWEROWEGO
Zamawiający przeznaczy na system bazodanowy obsługujący SSI dwa serwery kasetowe, każdy o
następujących parametrach: 2 procesory 4 rdzeniowe zgodne z architekturą x86, wspierające
rozszerzenia 64 bitowe o wydajności ocenianej na co najmniej 29,4 w teście SPECInt2006 lub 33,6 w
teście SPECfp2006 oraz co najmniej 16 GB RAM. Serwery te będą posiadały możliwości rozbudowy
RAM do min. 96 GB. Pamięć masową tych serwerów stanowić będzie macierz dyskowa podłączona
interfejsem FC 4Gb/s. Oferowane systemy operacyjne i bazodanowe muszą wykorzystywać pełny
potencjał tych maszyn możliwy do osiągnięcia.
Zamawiający wymaga utworzenia środowiska bazodanowego w postaci klastra składającego się z
dwóch maszyn. Zamawiający wymaga zastosowania homogenicznego środowiska bazodanowego w
oferowanym rozwiązaniu.
W ramach umowy Dostawca dostarczy bezterminowe licencje oraz komplet nośników na system
operacyjny oraz silnik bazy danych. Nie dopuszcza się licencji czasowych. Licencje powyższe mają
zawierać min. 1 rok wsparcia technicznego producenta. Dostarczone licencje muszą umożliwiać
Zamawiającemu wykorzystanie ich w innych aplikacjach będących aktualnie, bądź w przyszłości w
jego posiadaniu.
Opis funkcjonalności silnika bazy danych:
1. Dostępność oprogramowania na współczesne 64-bitowe platformy Unix (HP-UX dla
procesorów PA-RISC i Itanium, Solaris dla procesorów SPARC, IBM AIX), Intel Linux 64-bit, MS
Windows 64-bit. Identyczna funkcjonalność serwera bazy danych na w/w platformach
2. Niezależność platformy systemowej dla oprogramowania klienckiego / serwera aplikacyjnego
od platformy systemowej bazy danych.
3. Możliwość przeniesienia (migracji) struktur bazy danych i danych pomiędzy ww. platformami
bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego.
4. Przetwarzanie transakcyjne wg reguł ACID (Atomicity, Consistency, Independency, Durability)
z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności.
5. Możliwość zagnieżdżania transakcji – powinna istnieć możliwość uruchomienia niezależnej
transakcji wewnątrz transakcji nadrzędnej. Przykładowo – powinien być możliwy następujący
scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w
tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana.
6. Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).
7. Możliwość migracji zestawu znaków bazy danych do Unicode.
8. Możliwość redefiniowania przez klienta ustawień narodowych – symboli walut, formatu dat,
porządku sortowania znaków.
9. Wsparcie protokołu XA.
10. Wsparcie standardu JDBC 3.0
11. Motor bazy danych powinien umożliwiać wskazywanie optymalizatorowi SQL preferowanych
metod optymalizacji na poziomie konfiguracji parametrów pracy serwera bazy danych oraz
dla wybranych zapytań. Powinna istnieć możliwość umieszczania wskazówek dla
optymalizatora w wybranych instrukcjach SQL.
12. Brak formalnych ograniczeń na liczbę wierszy w tabelach.
13. Możliwość wykorzystania min. 4 TB pamięci RAM.
14. Możliwość wykorzystania min. 64 procesorów na serwer.
15. Brak formalnych ograniczeń na wielkość bazy danych.
16. Obsługiwana liczba użytkowników bazy danych min. 40 mln.
17. Możliwość rozbudowy klastra o co najmniej 2 dodatkowe maszyny o parametrach nie
gorszych niż użyte do budowy środowiska bazodanowego (parametr ten może wymagać od
Zamawiającego jedynie zakupu licencji związanych z dodatkowymi procesorami w
serwerach). Nie dopuszcza się rozwiązania w którym wymagany będzie upgrade (migracja do
wyższej wersji) już posiadanych licencji.
Strona 1 z 3
EDZ.242-66/10 Załącznik nr 3 – Wymogi dotyczące bazy danych i środowiska serwerowego
18. Wsparcie dla procedur i funkcji składowanych w bazie danych. Język programowania
powinien być językiem proceduralnym, blokowym (umożliwiającym deklarowanie zmiennych
wewnątrz bloku), oraz wspierającym obsługę wyjątków. W przypadku, gdy wyjątek nie ma
zadeklarowanej obsługi wewnątrz bloku, w razie jego wystąpienia wyjątek powinien być
automatycznie propagowany do bloku nadrzędnego bądź wywołującej go jednostki
programu.
19. Procedury i funkcje składowane powinny mieć możliwość parametryzowania za pomocą
parametrów prostych jak i parametrów o typach złożonych, definiowanych przez
użytkownika.
20. Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT,
UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez
instrukcję DML W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd
zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza,
wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych,
zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w
której wystąpił ww. błąd lub wyjątek.
21. Baza danych powinna umożliwiać wymuszanie złożoności hasła użytkownika, czasu życia
hasła, sprawdzanie historii haseł, blokowanie konta przez administratora bądź w przypadku
przekroczenia limitu nieudanych logowań.
22. Przywileje użytkowników bazy danych powinny być określane za pomocą przywilejów
systemowych (np. prawo do podłączenia się do bazy danych - czyli utworzenia sesji, prawo
do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu /
modyfikacji tabeli, wykonania procedury). Baza danych powinna umożliwiać nadawanie ww.
przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W
danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.
23. Silnik bazy danych umożliwia szybkie przywracanie systemu bazodanowego do stanu sprzed
wprowadzenia zmiany bez potrzeby odwołania się do uprzednio wykonanej kopii
bezpieczeństwa i bez potrzeby zatrzymywania systemu.
24. Możliwość integracji z powszechnie stosowanymi systemami backupu (Legato, Veritas, Tivoli,
OmniBack, ArcServe itd.). Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie
offline oraz w trybie online.
25. Możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer
bazy danych. Możliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy
zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki
nadmiarowości backup'ów.
26. Silnik bazy danych umożliwia skalowanie procesu wykonywania / odtwarzania kopii
zapasowej poprzez równoległe uruchomienie kilku procesów dzielących między siebie
zadania skracając tym samym czas wykonania procesu i zmniejszając obciążenie bazy
27. Odtwarzanie powinno umożliwiać odzyskanie stanu danych z chwili wystąpienia awarii bądź
cofnąć stan bazy danych do punktu w czasie. W przypadku odtwarzania do stanu z chwili
wystąpienia awarii odtwarzaniu może podlegać cała baza danych.
28. W przypadku, gdy odtwarzaniu podlegają pojedyncze pliki bazy danych, pozostałe pliki baz
danych muszą być dostępne dla użytkowników.
29. Wbudowana obsługa wyrażeń regularnych dostępna z poziomu języka SQL jak i
procedur/funkcji składowanych w bazie danych.
30. Możliwość zaimplementowania polityki bezpieczeństwa regulującej dostęp do danych na
poziomie pojedynczych wierszy w tabelach. Mechanizm ten powinien być realizowany za
pomocą mechanizmów motoru bazy danych i powinien być przezroczysty dla aplikacji.
31. Motor bazy danych powinien udostępniać możliwość zrównoleglenia operacji SQL (zapytania,
instrukcje DML, ładowanie danych, tworzenie indeksów, przenoszenie tabel/indeksów
pomiędzy przestrzeniami danych)
32. Motor bazy danych powinien umożliwiać wykonywanie niektórych operacji związanych z
utrzymaniem bazy danych bez konieczności pozbawienia dostępu użytkowników do danych.
Strona 2 z 3
EDZ.242-66/10 Załącznik nr 3 – Wymogi dotyczące bazy danych i środowiska serwerowego
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
W szczególności dotyczy to tworzenia / przebudowywania indeksów oraz reorganizacji bądź
redefinicji tabel.
Umożliwienie wymuszenia zastosowania przez optymalizator SQL metody wskazanej przez
administratora bazy danych.
Możliwość profilowania instrukcji SQL przez motor bazy danych. Uzyskany rezultat
profilowania może być zapisany w repozytorium bazy danych oraz wykorzystany przez
optymalizator do optymalizacji zapytań bez wprowadzania zmian do tekstu instrukcji SQL.
Możliwość automatycznego diagnozowanie wydajności i wąskich gardeł w konfiguracji bazy
danych na podstawie prekonfigurowanych i możliwych do modyfikacji parametrów (np.
obciążenie procesora, zajętość dysków itp.) oraz konfigurowalne powiadamianie o
odchyleniach od wartości oczekiwanej.
Możliwość analizy zapytań wykonywanych w bazie danych oraz obiektów bazy danych i
propozycja na podstawie przeprowadzonej analizy dostrojenia nieoptymalnych zapytań
używanych w bazie danych oraz reorganizacja obiektów bazy danych (tabele, indeksy).
Silnik bazy danych umożliwia zarządzanie przydziałem zasobów obliczeniowych dla
użytkowników bazy danych.
Możliwość zwiększenia przepustowości bazy danych poprzez uruchomienie dodatkowych
serwerów obsługujących klaster bazy danych.
Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę danych nie
może powodować konieczności reorganizacji fizycznej (zmiana organizacji plików danych)
oraz logicznej struktury baz danych (tabel / indeksów).
Unieruchomienie jednego z serwerów bazy danych nie może powodować braku dostępu do
jakiejkolwiek części danych – baza danych musi być nadal dostępna za pośrednictwem
funkcjonujących dalej serwerów.
Możliwość kontynuacji pracy użytkowników podłączonych do serwera klastrowej bazy
danych, który uległ awarii. Powinna istnieć możliwość przeniesienia sesji na inny serwer oraz
automatycznego powiadomienia aplikacji o wykonaniu przełączenia.
Obraz bazy danych (metadane, obiekty bazy danych, stan danych) w klastrowej bazie danych
musi być niezależny od serwera do którego zostało nawiązane połączenie
Użycie którejkolwiek z powyższych funkcji nie może wymagać poniesienia dodatkowych kosztów po
stronie Zamawiającego, takich jak zakup dodatkowych modułów, konieczność podniesienia wersji
silnika bazy danych itd.
Zamawiający wymaga uruchomienia całego systemu od razu na docelowej bazie danych.
Zamawiający zapewni odpowiedni sprzęt do uruchomienia systemu informatycznego. W przypadku
udostępnienia sprzętu o niższych parametrach niż deklarowany koszty migracji na sprzęt docelowy
ponosi Zamawiający. Nie przewiduje się zmiany terminów wdrożenia poszczególnych modułów
oprogramowania w związku z ewentualną migracją.
Zamawiający określił w SIWZ parametry środowiska serwerowego, które zostanie przeznaczone na
potrzeby wdrażanego systemu. Decyzje dotyczące konieczności ewentualnej rozbudowy tych
serwerów Zamawiający podejmie w trakcie normalnej eksploatacji systemu.
Środowisko serwerowe dla serwerów aplikacyjnych, niezbędne serwery plików oraz system kopii
zapasowych zapewnia Zamawiający. Nie są one przedmiotem bieżącego postępowania.
Strona 3 z 3