Porzucamy MS SQL

Dzięki uprzejmości warszawskiej firmy ComPress, otrzymaliśmy tekst poświęcony migracji z Microsoft SQL na działający również pod Linuksem produkt firmy Sybase – Adaptive Server Enterprise.

Mam nadzieję, że jego pojawienie się na naszych łamach wpłynie na napisanie przez kogoś z was podobnego artykułu, poświęconego migracji na w pełni otwarte środowisko bazodanowe. Tymczasem porzucających MS SQLa na rzecz produktu firmy Sybase zapraszam do lektury.

1. Historia
Sybase Adaptive Server Enterprise i Microsoft SQL Server i mają wspólne pochodzenie. Do wersji 4.2, Microsoft licencjonował serwer Sybase. W zasadzie były to dwie oddzielne ścieżki marketingowe dla tego samego produktu. Później pojawiły się różnice. Microsoft wprowadził na rynek samodzielnie wersje 6.0, 6.5, 7.0 i 2000 serwera podczas, gdy Sybase nazywał swój produkt wersją 4.8, 4.9, System 10 i System 11 SQL Servera i 11.5, 11.9, 12 i 12.5 serwera Adaptive Server Enterprise.

Migracja
Wspólna historia spowodowała, że oba serwery pod względem standardu SQL, interfejsów programowych, podstawowych zasad administracji są bardzo podobne. Stąd, jeśli zachodzi potrzeba migracji systemu bazodanowego z Microsoft SQL Servera, migracja na produkt Sybase będzie najprawdopodobniej najprostsza i najszybsza. Wiele może być powodów do migracji: potrzeba wymiany systemu operacyjnego na Unix/Linux, potrzeba użycia architektury sprzętowej niedostępnej dla oprogramowania Microsoft, potrzeba przeniesienia systemu do zaawansowanej architektury rozproszonej, integracja oraz różne powody wynikające z polityki handlowej, marketingowej etc.

W większości przypadków proces migracji jest zadaniem łatwym i niewymagającym wiele doświadczenia. Czasem jednak zdarzają się drobne trudności wynikające stąd, że podobne zadania funkcjonalne serwera wyraża się nieco inną składnią lub konstrukcjami programowymi. Dlatego też warto przejrzeć niniejszy dokument, aby zapoznać się z najważniejszymi różnicami. Więcej szczegółów można znaleźć w opracowaniu „Microsoft SQL Server to Adaptive Server(R) Enterprise Migration Guide for Microsoft SQL Server 2000 and Adaptive Server Enterprise 12.5”, na podstawie którego opracowano ten skrócony opis.

2. Najważniejsze różnice
2.1. Cechy serwerów

W ASE występuje wiele różnic, które mają wpływ na administrację i wydajność, ale które nie mają wpływu na działanie aplikacji. Najważniejsze z nich:

• Systemowe bazy danych – procedury wbudowane są przechowywane w ASE w bazie sybsystemprocs, w MSSQL w master. W MSSQL dodatkowo istnieją bazy msdb – z informacjami o alarmach, zadaniach, historią kopii archiwalnych. Ponadto w MSSQL istnieje baza obsługująca replikację. W ASE baza sybsystemdb zarządza rozproszonymi transakcjami, baza dbccdb – zarządza testami bazy danych, sybsecurity – zarządza bezpieczeństwem. Ponadto w ASE możliwe jest definiowanie wielu tymczasowych baz danych.
• Układ logiczny składowania danych. W MSSQL strona bazy danych ma rozmiar 8KB. W ASE może mieć 2 KB, 4 KB, 8 KB, 16 KB
• Zarządzanie procesami – ASE zawiera Logical Process Manager, który pozwala podzielić moc procesorów dla poszczególnych użytkowników, aplikacji, procedur.
• Kontrola wykorzystania zasobów – ASE zawiera Resource Governor, który pozwala administratorowi ustawić ograniczenia na wykonywanie operacji. Resource Governor może śledzić zarówno aktualne jak i planowane (szacunkowe przed wykonaniem) wykorzystanie zasobów (operacje I/O, liczbę wierszy, czas obliczeń) i podejmować akcje odpowiednio zdefiniowane przez administratora (ostrzeżenie, przerwanie transakcji, przerwanie połączenia). Ograniczenia mogą być ustawione niezależnie dla poszczególnych użytkowników, aplikacji, przedziałów czasowych.
• Równoległość – oba serwery potrafią złożone zapytania dzielić na prostsze i wykonywać je równolegle. ASE – posiada ten mechanizm bardziej rozbudowany uwzględniający stopień równoległości, fizyczne rozmieszczenie danych, dostępność zasobów.
• Platformy. MSSQL jest dostępny tylko na platformy Windows. ASE jest dostępny poza systemami Windows także na Intel Linux, Sun Solaris, Hewlett Packard HP-UX, IBM AIX, Compaq, Tru64 Unix, Silicon Graphics IRIX, Mac OS X.
• Skalowalność. MSSQL może działać na 32 procesorach na Windows 2000 Data Center lub 8 na Windows 2000 Advanced Server. Większe systemy mogą być obsłużone poprzez rozwiązanie Federated Database Servers, które polega na partycjonowaniu poziomym tabel przez administratora i dostęp do nich poprzez specjalne rozproszone widoki. ASE może pracować na maszynach unixowych do 256 procesorów. MSSQL może używać 64 GB RAM na Windows 2000 Data Center, (z AWE [64-bitowe adresowanie], bez dynamicznego zarządzania pamięcią). ASE – kilka terabajtów (na 64-bitowych Unixach [Solaris, HP-UX, AIX], z dynamicznym zarządzaniem pamięcią).

2.2. Różnice programistyczne
Pomiędzy serwerami występują różnice, które przy migracji mogą wymagać interwencji programisty. Najważniejsze z nich:

• Polecenia DDL (np. CREATE TABLE…..) w transakcjach – w MSSQL domyślnie stanowią część transakcji (obniżając wydajność serwera), w ASE domyślnie polecenia DDL nie są częścią transakcji, ale mogą nią być poprzez włączenie opcji „allow ddl in tran”.
• Zmienianie niektórych obiektów (ALTER PROCEDURE…etc.) są niedostępne w ASE (wymaga to usunięcia obiektu i stworzenie go jeszcze raz)
• Rozpoznawanie nazw w procedurach wbudowanych – w ASE obiekty musza istnieć w momencie tworzenia procedury. W MSSQL mogą powstać później (przed wywołaniem procedury). [Kompilacja w ASE odbywa się w momencie tworzenia, a nie wykonania.]
• Identyfikatory obi
  ektów. MSSQL dopuszcza 128 znaków
  w identyfikatorze. ASE, w zgodzie ze specyfikacja SQL92, pozwala na 30 znaków.

• Złączenia. MSSQL pozwala na 256 tablic w złączeniu, ASE – 64.
• Kolumny wyliczane. MSSQL pozwala na tworzenie kolumn, których wartościami są wyrażenia na danych w innych kolumnach. Funkcjonalność ta będzie dostępna w kolejnych wersjach ASE, obecnie można ja zrealizować zwykłymi kolumnami i trigerami.
• Funkcje – w serwetach dostępny jest nieco inny zestaw funkcji i zmiennych systemowych. Jeśli aplikacja ich używa należy je wymienić na odpowiedniki. Szczegóły można znaleźć w dodatku A „Microsoft SQL Server to Adaptive Server(R) Enterprise Migration Guide for Microsoft SQL Server 2000 and Adaptive Server Enterprise 12.5”.

3. Proces migracji
Migracja składa się z kilku etapów. Na początku należy zainstalować serwer, skonfigurować, założyć bazę danych, przydzielić obszar dyskowy na dane i dziennik transakcyjny. Następnym etapem jest przeniesienie schematu bazy danych, a dalej migracja samych danych. Pozostaje jeszcze przełączenie w aplikacji, aby korzystała z nowej bazy danych. W międzyczasie należy założyć konta użytkownikom i przydzielić im odpowiednie uprawnienia. Często taka migracja jest świetną okazją do uporządkowania bazy danych, usuwamy wtedy zbędne tablice i kolumny, modyfikujemy typy danych, aby bardziej odpowiadały bieżącym wymaganiom, pozbywamy się nieaktualnych i niepoprawnych danych weryfikujemy prawa dostępu, unowocześniamy aplikację, etc.

Poszczególne etapy można przeprowadzić na wiele sposobów. Jednym z nich jest wykorzystanie narzędzia Sybase do modelowania danych i aplikacji – PowerDesigner, szczególnie wzbogaconego o plug-in PowerTransfer. PowerDesigner wykorzystuje interfejs ODBC do podłączenia się do bazy danych i rewersowania schematu, pozwalając na wykonanie tej operacji na około 30 różnych systemach baz danych, włączając w to między innymi: MS SQL, Access, Oracle, DB2, FoxPro i inne. PowerTransfer przenosi schemat i dane do ASE używając odpowiedniej biblioteki OpenClienta (OpenClient bulk library). Migracja po kolei:

3.1. Migracja struktur Serwera
W kroku tym powinna zostać utworzona struktura serwera, która jest w stanie wspierać istniejące aplikacje MS SQL w środowisku ASE. Na szczęście, ponieważ struktura dwóch produktów jest bardzo podobna, występuje małe prawdopodobieństwo, by mogło to sprawić jakieś problemy podczas migracji.

Serwer ASE powinien zostać stworzony, by przejąć rolę serwera MS SQL. Jest to prosty krok, który powinien zostać wykonany przy wykorzystaniu programu Server Config (w przypadku systemu operacyjnego Windows) czy też asecfg (na platformie Unix).

Opcje na poziomie serwera ASE powinny zostać ustawione przy wykorzystaniu procedury sp_configure lub programu Sybase Central. Opcje te powinny zasadniczo odpowiadać tym w istniejącym serwerze MS SQL.

3.2. Alokacja miejsca do przechowywania danych
Miejsce dla baz danych powinno zostać zaalokowane w nowym serwerze ASE. Standardowo wymaga to utworzenia skryptu z komendą DISK INIT, z odpowiednimi ustawieniami. Urządzenia powinny zostać stworzone zarówno dla obszaru danych jak i dla dziennika transakcyjnego. Można te operacje wykonać także za pomocą Sybase Central.

3.3. Tworzenie pustej bazy danych
Krok ten ma na celu przeniesienie baz danych z MS SQL na ASE. Wynikiem tego kroku powinna być w pusta struktura bazy danych, która jest gotowa do obsługi aplikacji.

Bazy danych mogą być stworzone przy wykorzystaniu skryptów z serwera MSSQL, o ile są takie dostępne (z poprawionymi klauzulami zarządzania przestrzenią składowania dostosowanymi dla ASE lub za pomocą Sybase Central, lub nakazując PowerDesignerowi tworzenie bazy danych przed tworzeniem tablic.

Odpowiednie opcje dla nowo stworzonych baz danych powinny zostać ustawione przy wykorzystaniu procedury sp_dboption. Wiele z opcji bazodanowych może być ustawianych poprzez proste przekopiowanie z serwera MS SQL.

3.4. Migracja schematu bazy danych
Krok ten ma na celu stworzenie schematu bazy danych, który może zostać wypełniony danymi aplikacji i wykorzystywany następnie w aplikacjach.

W pierwszej kolejności powinniśmy utworzyć skrypt DDL, który zostanie wykorzystany do tworzenia obiektów bazy danych. Jeżeli skrypty oryginalne nie są dostępne, odpowiednie narzędzie administracyjne (np. Microsoft SQL Enterprise Manager czy też Embarcadero DB-Artisan) czy też narzędzie CASE (np. PowerDesigner) może zostać użyte do ich zrewersowania.

Skrypty DDL uzyskane z serwera Microsoftu powinny zostać sprawdzone pod względem specyficznych dla MS SQL wyrażeń i opcji, i ewentualnie odpowiednio zmodyfikowane. Różnice są szczegółowo opisane w opracowaniu „Microsoft SQL Server to Adaptive Server(R) Enterprise Migration Guide for Microsoft SQL Server 2000 and Adaptive Server Enterprise 12.5”

Poprawione skrypty należy uruchomić na serwerze ASE.

3.5. Migracja danych
Krok migracji danych wymaga ekstrakcji danych z tabel MS SQL i wstawienia tych danych do nowoutworzonych tabel ASE.

Jest kilka metod ekstrakcji danych z MS SQL, w prosty sposób pomiędzy dwoma serwerami. Wybrana metoda zależy od ilości danych, które będą przenoszone i budżetu dostępnego na narzędzia wspomagające ten proces.

Wśród możliwych do zastosowania można wymienić:

• Wykorzystanie narzędzia dostarczanego z ASE – PowerTransfer, pozwalającego na przeniesienie danych z MS SQL do ASE
• Wykorzystanie bcp w MS SQL, by wyładować dane z każdej z tabeli do pliku tekstowego, w trybie znakowym (w opcją `-c’ i `-6′) i następnie użycie narzędzia bcp w ASE by załadować dane z pliku do serwera
• Wykorzystanie narzędzia firmy Sybase – InfoMaker i jego obiektu Data Pipeline do przeniesienia danych bezpośrednio z MS SQL do ASE
• Wykorzystanie MS DTS do przeniesienia danych z MS SQL, bezpośrednio do ASE
• Wykorzystanie produktów firm trzecich do ekstrakcji danych do plików lub też przeniesienia danych bezpośrednio z MS SQL do ASE
• Wykorzystanie ASE/CIS i Enterprise Connect / Data Access (ECDA) do ekstrakcji danych z MS SQL i bezpośredniego wstawienia ich do ASE

W przypadku niektórych z wymienionych wyżej możliwości eksportu danych (np. wykorzystanie bcp), kroki importu i eksportu są rozdzielne. Ogólnie, przed wykonaniem importu, indeksy, trigery i reguły poprawości powinny zostać usunięte z tabel na serwerze ASE, by pozwolić importowi na zadziałanie tak szybko, jak to możliwe. Odpowiednie mechanizmy sprawdzające więzy integralności mogą zostać założone, indeksy przebudowane i wyzwalacze stworzone ponownie, po tym, gdy import zostanie zakończony.

3.6. Migracja programów aplikacji (zapytań i interfejsów)
Krok ten dotyczy migracji samej aplikacji, która wymaga zapewnienia, że wyrażenia SQL aplikacji (DML) będą pracowały na nowej bazie danych i interfejsy programowania aplikacji będą dostępne dla nowego serwera bazodanowego.

Etap ten przebiega w różny sposób w zależności od technologii, w jakiej opracowano aplikację. W przypadku nowoczesnych środowisk budowy aplikacji, biblioteki systemowe odpowiadają z tłumaczenie różnic występujących pomiędzy bazami danych. W
tedy wystarczy ustawić w parametrach aplikacji rodzaj serwera bazodanowego. Więk
sze problemy możemy spotkać wtedy, jeśli programiści budując aplikację bezpośrednio w kodzie posługiwali się konstrukcjami SQL właściwymi tylko dla MS SQL Servera. Należy wówczas przetestować jak działają te konstrukcje w Sybase Adaptive Server Enterprise i ewentualnie zmodyfikować je tak, aby realizowały założona funkcjonalność. Na szczęście różnice w serwerach nie dotyczą fundamentalnych rzeczy i dlatego miejsc w aplikacji, w których wstępują niezgodne konstrukcje jest najczęściej bardzo mało. Przy poprawianiu warto posłużyć się dodatkiem A do dokumentu „Microsoft SQL Server to Adaptive Server(R) Enterprise Migration Guide for Microsoft SQL Server 2000 and Adaptive Server Enterprise 12.5”.

Jeszcze jednym aspektem migracji aplikacji jest jej podłączenie do Sybase Adaptive Server Enterprise, zamiast Microsoft SQL Servera. Dla programów napisanych przy wykorzystaniu środowisk 4GL, jak np. Visual Basic czy też PowerBuilder wystarczy zmienić parametry połączenia. Dla klientów napisanych w językach takich jak `C’, należy je przekompilować i zlinkować ich przy wykorzystaniu Sybase DB-Library (odpowiednika dla Microsoft DB-Library).

Aplikacje, które używają interfejsów OLE DB i ODBC do dostępu do bazy danych, mogą być uruchamiane na serwerze ASE bez zmian, ponieważ ASE OLE DB oraz sterowniki ODBC wspierają wywołania funkcji wykonywane przez aplikację.

(Sybase Polska)
Archiwalny news dodany przez użytkownika: honey.
Kliknij tutaj by zobaczyć archiwalne komentarze.