Rozwój systemu informatycznego Urzędu Miasta Oleśnicy konieczny do obsługi e-usług: e-Urząd III etap – zakup, instalacja i konfiguracja Hardware na doposażenie serwerowni oraz Zakup, instalacja i konfiguracja Software narzędziowego – Dostawa licencji na system bazy danych na dwa procesory fizyczne wraz z rocznym wsparciem producenta oraz instalacja w środowisku Zamawiającego
Opis przedmiotu przetargu: Dostawa licencji na system bazy danych na dwa procesory fizyczne wraz z rocznym wsparciem producenta oraz instalacja w środowisku Zamawiającego. Wymaganie ogólne. Dostarczone systemy i licencje muszą być nowe, nie przypisane wcześniej do innego użytkownika, zakupione w oficjalnym kanale dystrybucji producenta, przeznaczone dla użytkownika z terytorium Polski oraz będącego jednostką sektora finansów publicznych (Gmina Miasto Oleśnica oraz jej jednostki budżetowe). Zapewnione musi być co najmniej roczne wsparcie dla dostarczonego systemu co najmniej w zakresie prawa do instalacji nowych wersji systemu, poprawek funkcjonalności i poprawek bezpieczeństwa oraz możliwość przedłużania tego wsparcia. Zamawiający uzna, że zaoferowane rozwiązanie posiada cechy zgodne z opisem przedmiotu zamówienia jeżeli będzie ono zawierało funkcjonalności co najmniej tożsame lub lepsze od określonych w niniejszym opisie przedmiotu zamówienia w zakresie posiadanej funkcjonalności i będzie kompatybilne w 100% z oprogramowaniem posiadanym przez Zamawiającego, o którym mowa w niniejszym opisie przedmiotu zamówienia. Wykonawca zobowiązany będzie załączyć lub uzupełnić ofertę o opis i dane techniczne zaproponowanego rozwiązania umożliwiające porównanie go z wszystkimi parametrami wymaganymi niniejszym opisem przedmiotu zamówienia, w tym zgodność posiadanego oprogramowania z zaproponowanym rozwiązaniem. Zamawiający zastrzega sobie po wyborze oferty najkorzystniejszej a przed zawarciem umowy prawo do zweryfikowania funkcjonalności, wydajności i kompatybilności zaoferowanego rozwiązania poprzez analizę jego możliwości. W przypadku skorzystania przez Zamawiającego z ww. uprawnienia wykonawca jest zobowiązany w terminie wskazanym przez Zamawiającego do dostarczenia testowej wersji zaproponowanego rozwiązania i uruchomienia tego rozwiązania w siedzibie Zamawiającego oraz dokonania przeniesienia na testową wersję danych co najmniej 1 aplikacji wymienionych w opisie przedmiotu zamówienia na dostarczone środowisko testowe w celu zweryfikowania funkcjonalności, wydajności i kompatybilności aplikacji użytkowanych przez Zamawiającego z zaoferowanym rozwiązaniem. W przypadku, gdy zaoferowane przez Wykonawcę oprogramowanie nie będzie właściwie współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego lub spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo-programowego u Zamawiającego, Wykonawca pokryje wszystkie koszty związane z przywróceniem i sprawnym działaniem infrastruktury sprzętowo-programowej Zamawiającego oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe działanie środowiska sprzętowo-programowego Zamawiającego, również po odinstalowaniu oprogramowania równoważnego. Zamawiający posiada 1 licencję na system bazy danych Oracle Database Standard Edition One Processor Perpetual, rodzaj licencji Full Use oraz podpisaną umowę na wsparcie producenta w postaci asysty technicznej na poziomie Software Update License & Support o numerze CSI 16346221. Zamawiający użytkuje następujące aplikacje wykorzystujące ten system bazy danych: OO Document Manager firmy Rodan Systems S.A., PB USC, Eksport US firmy TECHNIKA IT Sp. z o.o., Ewidencja Ludności KSAT 2000i firmy COIG S.A., aplikacje Budzet, Umowy, Ewka, Alkon, Wiwa, Wiwa_r, Wiwa_t, Stresbis, Faktury, KTRM, Emka, Zapas, Zamek, Zasys firmy Sputnik Software sp. z o.o. W ramach dostawy należy dostarczyć bezterminowe licencje na komercyjny system bazodanowy w najnowszej wersji, bez ograniczenia dostawcy aplikacji korzystających z systemu bazy danych, w ilości wystarczającej do prawidłowego zalicencjonowania dwóch procesorów fizycznych tj licencje typu Standard Edition 2 Processor Perpetual Full Use (z uwzględnieniem licencji i wsparcia do licencji posiadanej dotychczas przez Zamawiającego) oraz dokonać instalacji dostarczonego systemu bazodanowego w środowisku Zamawiającego. Należy również zapewnić (dostarczyć) wsparcie producenta na cały dostarczony system bazy danych co najmniej na poziomie takim jak w ramach obowiązującej umowy, na okres nie krótszy niż 12 miesięcy, z możliwością jego przedłużenia. Wsparcie i licencje powinny być potwierdzone dokumentem wystawionym przez producenta systemu bazodanowego. Jeżeli będzie to konieczne, Zamawiający udzieli stosownego upoważnienia do zawarcia nowej lub zmiany obowiązującej umowy na wsparcie. Dostarczone licencje oraz wsparcie mają dawać Zamawiającemu prawo do instalacji starszych wersji dostarczonego systemu. Wymagane funkcjonalności dostępne w ramach dostarczonej licencji: – Możliwość instalacji systemu na serwerach o pojemności gniazd CPU nie przekraczających – Dostępność oprogramowania na współczesne 64-bitowe platformy Intel/AMD i systemów operacyjnych Unix, Linux, MS Windows. Identyczna funkcjonalność serwera bazy danych na ww. platformach. – Dostarczone licencje nie mogą ograniczać liczby użytkowników końcowych korzystających z oprogramowania ani liczby przetwarzanych lub przechowywanych dokumentów, plików, rekordów, żądań, etc. Licencje nie mogą być ograniczone czasowo ani do konkretnego dostawcy aplikacji (licencja typu Full Use). – Oferowany zestaw licencji powinien być jednorodny (w szczególności obie licencje powinny być na takich samych warunkach użytkowania i wsparcia producenta). – Dostępność narzędzi migracji baz danych pomiędzy platformami na poziomie fizycznym (kopiowanie / konwersja plików danych) oraz logicznym (narzędzia eksportu / importu). – Oprogramowanie klienckie, za pomocą którego można łączyć się do bazy danych musi być dostępne na wielu platformach systemowo-sprzętowych (minimalny zakres platform taki jak dla oprogramowania serwera bazy danych). – Wsparcie protokołu XA. – Wsparcie standardu JDBC 3.0. – Zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym. – Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych. – RDBMS musi zapewniać niezależność platformy systemowej dla oprogramowania klienckiego od platformy systemowej bazy danych. – RDBMS musi zapewniać przetwarzanie transakcyjne wg reguł ACID z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Mechanizm izolowania transakcji musi pozwalać na spójny odczyt modyfikowanego obszaru danych bez wprowadzania blokad, spójny odczyt nie może blokować możliwości wykonywania zmian. – RDBMS musi posiadać możliwość zagnieżdżania transakcji – możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. – Dostępność nieblokującego poziomu izolowania transakcji „tylko do odczytu” (Read Only) pozwalający na uzyskanie w wielu kolejnych następujących po sobie zapytaniach rezultatów odzwierciedlających stan danych z chwili rozpoczęcia ww. transakcji. – Dostępność poziomu serializowanego poziomu izolowania transakcji (Serializable). – Możliwość zmiany domyślnego trybu izolowania transakcji (Read Commited) na inny (Read Only, Serializable) za pomocą komend serwera bazy danych. – Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode) zarówno po stronie serwera bazy danych jak i oprogramowania klienckiego. Wsparcie dla polskich stron kodowych – ISO-8859-2, MS Windows Code Page 1250 oraz PC 852. Automatyczna konwersja znaków pomiędzy różnymi ustawieniami stron kodowych po stronie klienta i serwera bazy danych. – Możliwość migracji bazy danych utrzymujących dane znakowe w 8-bitowej stronie kodowej do Unicode. – Możliwość definiowania w przestrzeni danych (plików) dla danych użytkownika obszarów o innym niż domyślny rozmiarze bloku. – Możliwość (bez dodatkowych ograniczeń) przechowywania wierszy, których rozmiar przekracza rozmiar bloku bazy danych. – Możliwość budowania indeksów o strukturze B-drzewa. Baza danych powinna umożliwiać założenie indeksu jednej lub większej liczbie kolumn tabeli, przy czym ograniczenie liczby kolumn na których założony jest 1 indeks nie powinno być mniejsze niż 16. – Możliwość budowania widoków zmaterializowanych odzwierciedlających stan danych zdefiniowanych przez zapytanie SQL. Widok zmaterializowany przechowuje rezultat zapytania, którego aktualizacja odbywa się w jednej z dostępnych strategii – na żądanie, okresowo bądź po każdym zatwierdzeniu transakcji modyfikującej tabele, na której oparty jest widok zmaterializowany. – Możliwość szybkiego odświeżania danych w widoku zmaterializowanym na podstawie mechanizmu identyfikacji zmian w danych źródłowych. – Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy). – Kosztowy model optymalizacji instrukcji SQL. – Model statystyk optymalizatora kosztowego musi pozwalać na odwzorowanie nierównomierności rozkładu danych (składowanie informacji o rozkładzie wartości występujących w kolumnach za pomocą histogramu bądź porównywalnego funkcjonalnie modelu odwzorowania). – Możliwość uwzględnienia korelacji wartości występujących w niezależnych kolumnach tabeli w modelu statystyk optymalizatora kosztowego. – RDBMS 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. – 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. – 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. Funkcje powinny mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowe powinny umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury). – Możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej). – Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DML, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views). – 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. – Możliwość wykonania równoczesnych operacji DML (Insert/Update/Delete) na tej samej tabeli. – Powinna istnieć możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych bądź mechanizmu zewnętrznego w stosunku do bazy danych. – 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. – 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. Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online(hot backup). – 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 bądź pojedyncze pliki danych. – Możliwość uruchomienia bazy danych w środowisku klastra wielu aktywnych serwerów bazy danych. Ilośc socketów CPU w klastrze nie przekracza 2. – Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę danych nie może powodować konieczności reorganizacji fizycznej bazy danych (struktura plików danych). – Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę danych nie może powodować konieczności reorganizacji logicznej struktury baz danych (tabel / indeksów) – Unieruchomienie jednego z serwerów klastra 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. Wymagana jest możliwość przeniesienia sesji na inny serwer oraz automatycznego powiadomienia aplikacji o wykonaniu przełączenia. – Każdy z serwerów klastra musi mieć możliwość uspójnienia lub odtworzenia całej bazy danych w sytuacji awarii nośników lub nagłego zatrzymania innego serwera, który utrzymywał w buforze bazy danych zmodyfikowane ale niezapisane bloki danych. – 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. – Ze względu na konieczność zapewnienia wysokiej wydajności, bezpieczeństwa i dostępności system bazodanowy ma posiadać wbudowany własny system automatycznego zarządzania pamięcią masową, zarządzania dyskami, grupami dyskowymi, plikami niezależny od mechanizmów oferowanych przez system operacyjny serwera. – System ma zapewniać automatyczne zarządzanie pamięcią masową co najmniej w zakresie datafiles, log-files, system files, control files i innych struktur bazy danych, automatyczne rozkłądanie na wszystkie dyski w grupie dyskowej. Grupa dyskowa funkcjonuje jako grupa woluminów Menedżera woluminów logicznych - z plikiem odpowiadającym woluminowi logicznemu. Oprócz istniejących procesów w tle, otwiera się i tworzy dyski w grupie dysków, zapewnia funkcjonalność przenoszenia danych między dyskami w grupie dysków. Wszystkie operacje dyskowe mogą być wykonywane bez przerywania dostępu do danych. Należy zainstalować i wstępnie skonfigurować dostarczony system w środowisku Zamawiającego (2 CPU, System operacyjny Windows 2019, instalacja z wykorzystaniem funkcji automatycznego zarządzania pamięcią masową, uruchomienie i skonfigurowanie konsoli zarządzania) oraz dostarczyć dokumentację powykonawczą zawierającą co najmniej informacje o: - loginach i hasłach dla potrzeb administrowania wszystkimi funkcjami zainstalowanego systemu, - sposobach uruchamiania i zatrzymywania usług zainstalowanego systemu, - wywoływaniu konsoli zarządzania (w tym: zarządzania pamięcią masową, instancją bazy, etc), - sposobach monitorowania przy użyciu dostarczonego systemu zajętości pamięci i procedury rozbudowy o kolejne dyski w grupie dyskowej, Informacje ogólne i zastrzeżenia: Zamawiający wymaga, aby dostawy w ramach realizacji umowy pochodziły z oficjalnego kanału sprzedaży producenta. Oznacza to, że będą posiadały stosowny pakiet usług kierowanych do użytkowników z obszaru Rzeczpospolitej Polskiej.
Gość Zamawiający | Ogłoszenie nr 510136806-N-2019 z dnia 04-07-2019 r. Miasto Oleśnica: Rozwój systemu informatycznego Urzędu Miasta Oleśnicy konieczny do obsługi e-usług: e-Urząd III etap – zakup, instalacja i konfiguracja Hardware na doposażenie serwerowni oraz Zakup, instalacja i konfiguracja Software narzędziowego – Dostawa licencji na system bazy danych na dwa procesory fizyczne wraz z rocznym wsparciem producenta oraz instalacja w środowisku Zamawiającego OGŁOSZENIE O UDZIELENIU ZAMÓWIENIA - Dostawy Zamieszczanie ogłoszenia: obowiązkowe Ogłoszenie dotyczy: zamówienia publicznego Zamówienie dotyczy projektu lub programu współfinansowanego ze środków Unii Europejskiej tak Nazwa projektu lub programu Rozwój systemu informatycznego Urzędu Miasta Oleśnica koniczny dla obsługi e-usług: e-Urząd III Etap, nr RPDS.02.01.01- 02-0041/17 Zamówienie było przedmiotem ogłoszenia w Biuletynie Zamówień Publicznych: tak Numer ogłoszenia: 551014-N-2019 Ogłoszenie o zmianie ogłoszenia zostało zamieszczone w Biuletynie Zamówień Publicznych: nie SEKCJA I: ZAMAWIAJĄCY I. 1) NAZWA I ADRES: Miasto Oleśnica, Krajowy numer identyfikacyjny 93193473300000, ul. Rynek-Ratusz , 56-400 Oleśnica, woj. dolnośląskie, państwo Polska, tel. 717 982 100, e-mail b.strzala@um.olesnica.pl, faks 717 982 117. Adres strony internetowej (url): www.olesnica.pl I.2) RODZAJ ZAMAWIAJĄCEGO: Administracja samorządowa SEKCJA II: PRZEDMIOT ZAMÓWIENIA II.1) Nazwa nadana zamówieniu przez zamawiającego: Rozwój systemu informatycznego Urzędu Miasta Oleśnicy konieczny do obsługi e-usług: e-Urząd III etap – zakup, instalacja i konfiguracja Hardware na doposażenie serwerowni oraz Zakup, instalacja i konfiguracja Software narzędziowego – Dostawa licencji na system bazy danych na dwa procesory fizyczne wraz z rocznym wsparciem producenta oraz instalacja w środowisku Zamawiającego Numer referencyjny (jeżeli dotyczy): ZP/PN/6/2019 II.2) Rodzaj zamówienia: Dostawy II.3) Krótki opis przedmiotu zamówienia (wielkość, zakres, rodzaj i ilość dostaw, usług lub robót budowlanych lub określenie zapotrzebowania i wymagań ) a w przypadku partnerstwa innowacyjnego - określenie zapotrzebowania na innowacyjny produkt, usługę lub roboty budowlane: Dostawa licencji na system bazy danych na dwa procesory fizyczne wraz z rocznym wsparciem producenta oraz instalacja w środowisku Zamawiającego. Wymaganie ogólne. Dostarczone systemy i licencje muszą być nowe, nie przypisane wcześniej do innego użytkownika, zakupione w oficjalnym kanale dystrybucji producenta, przeznaczone dla użytkownika z terytorium Polski oraz będącego jednostką sektora finansów publicznych (Gmina Miasto Oleśnica oraz jej jednostki budżetowe). Zapewnione musi być co najmniej roczne wsparcie dla dostarczonego systemu co najmniej w zakresie prawa do instalacji nowych wersji systemu, poprawek funkcjonalności i poprawek bezpieczeństwa oraz możliwość przedłużania tego wsparcia. Zamawiający uzna, że zaoferowane rozwiązanie posiada cechy zgodne z opisem przedmiotu zamówienia jeżeli będzie ono zawierało funkcjonalności co najmniej tożsame lublepsze od określonych w niniejszym opisie przedmiotu zamówienia w zakresie posiadanej funkcjonalności i będzie kompatybilne w 100% z oprogramowaniem posiadanym przez Zamawiającego, o którym mowa w niniejszym opisie przedmiotu zamówienia. Wykonawca zobowiązany będzie załączyć lub uzupełnić ofertę o opis i dane techniczne zaproponowanego rozwiązania umożliwiające porównanie go z wszystkimi parametrami wymaganymi niniejszym opisem przedmiotu zamówienia, w tym zgodność posiadanego oprogramowania z zaproponowanym rozwiązaniem. Zamawiający zastrzega sobie po wyborze oferty najkorzystniejszej a przed zawarciem umowy prawo do zweryfikowania funkcjonalności, wydajności i kompatybilności zaoferowanego rozwiązania poprzez analizę jego możliwości. W przypadku skorzystania przez Zamawiającego z ww. uprawnienia wykonawca jest zobowiązany w terminie wskazanym przez Zamawiającego do dostarczenia testowej wersji zaproponowanego rozwiązania i uruchomienia tego rozwiązania w siedzibie Zamawiającego oraz dokonania przeniesienia na testową wersję danych co najmniej 1 aplikacji wymienionych w opisie przedmiotu zamówienia na dostarczone środowisko testowe w celu zweryfikowania funkcjonalności, wydajności i kompatybilności aplikacji użytkowanych przez Zamawiającego z zaoferowanym rozwiązaniem. W przypadku, gdy zaoferowane przez Wykonawcę oprogramowanie nie będzie właściwie współdziałać ze sprzętem i oprogramowaniem funkcjonującym u Zamawiającego lub spowoduje zakłócenia w funkcjonowaniu pracy środowiska sprzętowo-programowego u Zamawiającego, Wykonawca pokryje wszystkie koszty związane z przywróceniem i sprawnym działaniem infrastruktury sprzętowoprogramowej Zamawiającego oraz na własny koszt dokona niezbędnych modyfikacji przywracających właściwe działanie środowiska sprzętowo-programowego Zamawiającego, również po odinstalowaniu oprogramowania równoważnego. Zamawiający posiada 1 licencję na system bazy danych Oracle Database Standard Edition One Processor Perpetual, rodzaj licencji Full Use oraz podpisaną umowę na wsparcie producenta w postaci asysty technicznej na poziomie Software Update License & Support o numerze CSI 16346221. Zamawiający użytkuje następujące aplikacje wykorzystujące ten system bazy danych: OO Document Manager firmy Rodan Systems S.A., PB USC, Eksport US firmy TECHNIKA IT Sp. z o.o., Ewidencja Ludności KSAT 2000i firmy COIG S.A., aplikacje Budzet, Umowy, Ewka, Alkon, Wiwa, Wiwa_r, Wiwa_t, Stresbis, Faktury, KTRM, Emka, Zapas, Zamek, Zasys firmy Sputnik Software sp. z o.o. W ramach dostawy należy dostarczyć bezterminowe licencje na komercyjny system bazodanowy w najnowszej wersji, bez ograniczenia dostawcy aplikacji korzystających z systemu bazy danych, w ilości wystarczającej do prawidłowego zalicencjonowania dwóch procesorów fizycznych tj licencje typu Standard Edition 2 Processor Perpetual Full Use (z uwzględnieniem licencji i wsparcia do licencji posiadanej dotychczas przez Zamawiającego) oraz dokonać instalacji dostarczonego systemu bazodanowego w środowisku Zamawiającego. Należy również zapewnić (dostarczyć) wsparcie producenta na cały dostarczony system bazy danych co najmniej na poziomie takim jak w ramach obowiązującej umowy, na okres nie krótszy niż 12 miesięcy, z możliwością jego przedłużenia. Wsparcie i licencje powinny być potwierdzone dokumentem wystawionym przez producenta systemu bazodanowego. Jeżeli będzie to konieczne, Zamawiający udzieli stosownego upoważnienia do zawarcia nowej lub zmiany obowiązującej umowy na wsparcie. Dostarczone licencje oraz wsparcie mają dawać Zamawiającemu prawo do instalacji starszych wersji dostarczonego systemu. Wymagane funkcjonalności dostępne w ramach dostarczonej licencji: – Możliwość instalacji systemu na serwerach o pojemności gniazd CPU nie przekraczających – Dostępność oprogramowania na współczesne 64-bitowe platformy Intel/AMD i systemów operacyjnych Unix, Linux, MS Windows. Identyczna funkcjonalność serwera bazy danych na ww. platformach. – Dostarczone licencje nie mogą ograniczać liczby użytkowników końcowych korzystających z oprogramowania ani liczby przetwarzanych lub przechowywanych dokumentów, plików, rekordów, żądań, etc. Licencje nie mogą być ograniczone czasowo ani do konkretnego dostawcy aplikacji (licencja typu Full Use). – Oferowany zestaw licencji powinien być jednorodny (w szczególności obie licencje powinny być na takich samych warunkach użytkowania i wsparcia producenta). – Dostępność narzędzi migracji baz danych pomiędzy platformami na poziomie fizycznym (kopiowanie / konwersja plików danych) oraz logicznym (narzędzia eksportu / importu). –Oprogramowanie klienckie, za pomocą którego można łączyć się do bazy danych musi być dostępne na wielu platformach systemowo-sprzętowych (minimalny zakres platform taki jak dla oprogramowania serwera bazy danych). – Wsparcie protokołu XA. – Wsparcie standardu JDBC 3.0. – Zgodność ze standardem ANSI/ISO SQL 2003 lub nowszym. – Wbudowana obsługa wyrażeń regularnych zgodna ze standardem POSIX dostępna z poziomu języka SQL jak i procedur/funkcji składowanych w bazie danych. – RDBMS musi zapewniać niezależność platformy systemowej dla oprogramowania klienckiego od platformy systemowej bazy danych. – RDBMS musi zapewniać przetwarzanie transakcyjne wg reguł ACID z zachowaniem spójności i maksymalnego możliwego stopnia współbieżności. Mechanizm izolowania transakcji musi pozwalać na spójny odczyt modyfikowanego obszaru danych bez wprowadzania blokad, spójny odczyt nie może blokować możliwości wykonywania zmian. – RDBMS musi posiadać możliwość zagnieżdżania transakcji – możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej. – Dostępność nieblokującego poziomu izolowania transakcji „tylko do odczytu” (Read Only) pozwalający na uzyskanie w wielu kolejnych następujących po sobie zapytaniach rezultatów odzwierciedlających stan danych z chwili rozpoczęcia ww. transakcji. – Dostępność poziomu serializowanego poziomu izolowania transakcji (Serializable). – Możliwość zmiany domyślnego trybu izolowania transakcji (Read Commited) na inny (Read Only, Serializable) za pomocą komend serwera bazy danych. – Wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode) zarówno po stronie serwera bazy danych jak i oprogramowania klienckiego. Wsparcie dla polskich stron kodowych – ISO-8859-2, MS Windows Code Page 1250 oraz PC 852. Automatyczna konwersja znaków pomiędzy różnymi ustawieniami stron kodowych po stronie klienta i serwera bazy danych. – Możliwość migracji bazy danych utrzymujących dane znakowe w 8-bitowej stronie kodowej do Unicode. – Możliwość definiowania w przestrzeni danych (plików) dla danych użytkownika obszarów o innym niż domyślny rozmiarze bloku. – Możliwość (bez dodatkowych ograniczeń) przechowywania wierszy, których rozmiar przekracza rozmiar bloku bazy danych. – Możliwość budowania indeksów o strukturze B-drzewa. Baza danych powinna umożliwiać założenie indeksu jednej lub większej liczbie kolumn tabeli, przy czym ograniczenie liczby kolumn na których założony jest 1 indeks nie powinno być mniejsze niż 16. – Możliwość budowania widoków zmaterializowanych odzwierciedlających stan danych zdefiniowanych przez zapytanie SQL. Widok zmaterializowany przechowuje rezultat zapytania, którego aktualizacja odbywa się w jednej z dostępnych strategii – na żądanie, okresowo bądź po każdym zatwierdzeniu transakcji modyfikującej tabele, na której oparty jest widok zmaterializowany. – Możliwość szybkiego odświeżania danych w widoku zmaterializowanym na podstawie mechanizmu identyfikacji zmian w danych źródłowych. – Brak formalnych ograniczeń na liczbę tabel i indeksów w bazie danych oraz na ich rozmiar (liczbę wierszy). – Kosztowy model optymalizacji instrukcji SQL. – Model statystyk optymalizatora kosztowego musi pozwalać na odwzorowanie nierównomierności rozkładu danych (składowanie informacji o rozkładzie wartości występujących w kolumnach za pomocą histogramu bądź porównywalnego funkcjonalnie modelu odwzorowania). – Możliwość uwzględnienia korelacji wartości występujących w niezależnych kolumnach tabeli w modelu statystyk optymalizatora kosztowego. – RDBMS 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. – 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. – 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. Funkcje powinny mieć możliwość zwracania rezultatów jako zbioru danych, możliwego do wykorzystania jako źródło danych w instrukcjach SQL (czyli występujących we frazie FROM). Ww. jednostki programowepowinny umożliwiać wywoływanie instrukcji SQL (zapytania, instrukcje DML, DDL), umożliwiać jednoczesne otwarcie wielu tzw. kursorów pobierających paczki danych (wiele wierszy za jednym pobraniem) oraz wspierać mechanizmy transakcyjne (np. zatwierdzanie bądź wycofanie transakcji wewnątrz procedury). – Możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej). – Możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELETE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DML, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views). – 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. – Możliwość wykonania równoczesnych operacji DML (Insert/Update/Delete) na tej samej tabeli. – Powinna istnieć możliwość autoryzowania użytkowników bazy danych za pomocą rejestru użytkowników założonego w bazie danych bądź mechanizmu zewnętrznego w stosunku do bazy danych. – 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. – 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. Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie offline oraz w trybie online(hot backup). – 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 bądź pojedyncze pliki danych. – Możliwość uruchomienia bazy danych w środowisku klastra wielu aktywnych serwerów bazy danych. Ilośc socketów CPU w klastrze nie przekracza 2. – Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę danych nie może powodować konieczności reorganizacji fizycznej bazy danych (struktura plików danych). – Zwiększenie bądź zmniejszenie liczby serwerów obsługujących klastrową bazę danych nie może powodować konieczności reorganizacji logicznej struktury baz danych (tabel / indeksów) – Unieruchomienie jednego z serwerów klastra 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. Wymagana jest możliwość przeniesienia sesji na inny serwer oraz automatycznego powiadomienia aplikacji o wykonaniu przełączenia. – Każdy z serwerów klastra musi mieć możliwość uspójnienia lub odtworzenia całej bazy danych w sytuacji awarii nośników lub nagłego zatrzymania innego serwera, który utrzymywał w buforze bazy danych zmodyfikowane ale niezapisane bloki danych. – 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. – Ze względu na konieczność zapewnienia wysokiej wydajności, bezpieczeństwa i dostępności system bazodanowy ma posiadać wbudowany własny system automatycznego zarządzania pamięcią masową, zarządzania dyskami, grupami dyskowymi, plikami niezależny od mechanizmów oferowanych przez system operacyjny serwera. – System ma zapewniać automatyczne zarządzanie pamięcią masową co najmniej w zakresie datafiles, log-files, system files, control files i innych struktur bazy danych, automatyczne rozkłądanie na wszystkie dyski w grupie dyskowej. Grupa dyskowa funkcjonuje jako grupa woluminów Menedżera woluminów logicznych - z plikiem odpowiadającym woluminowi logicznemu. Oprócz istniejących procesów w tle, otwiera się i tworzy dyski w grupie dysków, zapewnia funkcjonalność przenoszenia danych między dyskami w grupie dysków. Wszystkie operacje dyskowe mogą być wykonywane bez przerywania dostępu do danych. Należy zainstalować i wstępnie skonfigurować dostarczony system w środowisku Zamawiającego (2 CPU, System operacyjny Windows 2019, instalacja z wykorzystaniem funkcji automatycznego zarządzania pamięcią masową, uruchomienie i skonfigurowanie konsoli zarządzania) oraz dostarczyć dokumentację powykonawczą zawierającą co najmniej informacje o: - loginach i hasłach dla potrzeb administrowania wszystkimi funkcjami zainstalowanego systemu, - sposobach uruchamiania i zatrzymywania usług zainstalowanego systemu, - wywoływaniu konsoli zarządzania (w tym: zarządzania pamięcią masową, instancją bazy, etc), - sposobach monitorowania przy użyciu dostarczonego systemu zajętości pamięci i procedury rozbudowy o kolejne dyski w grupie dyskowej, Informacje ogólne i zastrzeżenia: Zamawiający wymaga, aby dostawy w ramach realizacji umowy pochodziły z oficjalnego kanału sprzedaży producenta. Oznacza to, że będą posiadały stosowny pakiet usług kierowanych do użytkowników z obszaru Rzeczpospolitej Polskiej II.4) Informacja o częściach zamówienia: Zamówienie było podzielone na części: nie II.5) Główny Kod CPV: 48800000-0 SEKCJA III: PROCEDURA III.1) TRYB UDZIELENIA ZAMÓWIENIA Przetarg nieograniczony III.2) Ogłoszenie dotyczy zakończenia dynamicznego systemu zakupów nie III.3) Informacje dodatkowe: SEKCJA IV: UDZIELENIE ZAMÓWIENIA
IV.9) UZASADNIENIE UDZIELENIA ZAMÓWIENIA W TRYBIE NEGOCJACJI BEZ OGŁOSZENIA, ZAMÓWIENIA Z WOLNEJ RĘKI ALBO ZAPYTANIA O CENĘ IV.9.1) Podstawa prawna Postępowanie prowadzone jest w trybie na podstawie art. ustawy Pzp. IV.9.2) Uzasadnienie wyboru trybu Należy podać uzasadnienie faktyczne i prawne wyboru trybu oraz wyjaśnić, dlaczego udzielenie zamówienia jest zgodne z przepisami. | ||||
Copyright © 2010 Urząd Zamówień Publicznych |
Dane postępowania
ID postępowania BZP/TED: | 551014-N-2019 |
---|---|
ID postępowania Zamawiającego: | ZP/PN/6/2019 |
Data publikacji zamówienia: | 2019-05-22 |
Rodzaj zamówienia: | dostawy |
Tryb& postępowania [PN]: | Przetarg nieograniczony |
Czas na realizację: | - |
Wadium: | - |
Oferty uzupełniające: | NIE |
Oferty częściowe: | NIE |
Oferty wariantowe: | NIE |
Przewidywana licyctacja: | NIE |
Ilość części: | 1 |
Kryterium ceny: | 60% |
WWW ogłoszenia: | www.olesnica.pl |
Informacja dostępna pod: | https://idumolesnica.bip.gov.pl/zamowienia-publiczne/ |
Okres związania ofertą: | 30 dni |
Kody CPV
48800000-6 | Systemy i serwery informacyjne |