http://www.wss.pl/Search/Articles/2.aspx?q=migracja%20oracle/
Data: 2003-04-29 00:41:00
Dodane przez: Jacek Kolonko
Prezentujemy pierwszą część publikacji poświęconej migracji rozwiązań pomiędzy Oracle a Microsoft SQL Server 2000.
Data: 2003-04-29 11:06:00
Druga część publikacji omawia podstawowe różnice w architekturze i terminologii pomiędzy Oracle a Microsoft SQL Server 2000.
Data: 2003-05-05 01:57:00
Trzecia część publikacji pokazuje różnice w sposobie zabezpieczania dostępu do bazy danych pomiędzy rozwiązaniami Oracle a Microsoft.
Data: 2003-05-07 17:33:00
Część czwarta artykułu porównującego Oracle i Microsoft SQL Server pokazuje ogólne zasady definiowania obiektów w bazach danych oraz zasady nazewnictwa. Porównuje także ograniczenia każdej z baz danych.
Data: 2003-05-13 09:58:00
W części piątej zostały porównane składnie tworzenia tabel oraz widoków w SQL Server 2000 i w Oracle.
Data: 2003-05-16 09:25:00
W części szóstej pokazane są różnice w organizacji i zasadach działania indeksów w Oracle i Microsoft SQL Server 2000.
Data: 2003-05-19 10:06:00
Tabele tymczasowe w Microsoft SQL Server są znacznie wygodniejsze w użyciu niż w w przypadku baz Oracle. W części siódmej artykułu porównującego bazy danych, pokazane są różnice w mechanizmie tworzenia takich tabel i zarządzania nimi z poziomu aplikacji.
Data: 2003-05-20 19:04:00
Typy danych zarówno w Oracle jak i w Microsoft SQL Server są rozszerzeniem standardowych typów SQL. W tej części artykułu porównującego te dwie bazy danych pokazane są różnice w typach danych. Zaprezentowane są także sposoby odwzorowania typów Oracle na M
Data: 2003-05-26 01:30:00
W tej części omówione są różnice w konfiguracji praw dostępu.
Data: 2003-06-03 22:57:00
W każdej bazie danych bardzo ważne jest określenie zasad definiowania integralności. W tej części przedstawione są ogólne zasady porównania metody stosowanych w Oracle i w MSSQL Server.
Data: 2003-06-06 11:08:00
Jednym z bardziej pożytecznych mechanizmów wbudowanych w bazę danych jest umiejętność określania zasad integralności - i takie sterowanie mechanizmami wbudowanymi w bazę, by naprawdę ułatwić życie programiście. W tej części przedstawione porównane są możl
Data: 2003-06-13 23:52:00
W każdej bazie danych oprócz wbudowanych metod określania zasad integralności danych, programista może także zdefiniować własne metody. W tej części pokazane są możliwości tworzenia procedur wbudowanych, oraz triggerów w Microsoft SQL Server 2000 oraz Ora
Data: 2003-06-18 01:22:00
Niniejszy dział wyjaśnia sposób wykonywania transakcji zarówno w Oracle, jak i w SQL Server firmy Microsoft i prezentuje różnice między procesami blokowania oraz kwestie współbieżności w obu typach baz danych.
Data: 2003-06-27 14:29:00
W tej części pokazane są różnice w strategiach blokowania rekordów podczas wykonywania transakcji. Artykuł pokazuje także w jaki sposób pisać aplikację tak, by eliminować możliwości wystąpienia zakleszczeń w odwołaniach do bazy danych.
Data: 2003-07-09 16:44:00
W tym artykule pokazane są różnice w implementacji zdalnych transakcji (tj. np. rozproszonych pomiędzy kilka serwerów bazodanowych) w Oracle i Microsft SQL Server 2000.
Data: 2003-07-19 19:58:00
W niniejszym dziale naszkicowane są podobieństwa oraz różnice między składnią języków Transact‑SQL oraz PL/SQL oraz przedstawione strategie konwersji. W tym artykule omówione są różnice w podstawowych instrukcjach - SELECT, INSERT, UPDATE i DELETE.
Data: 2003-07-30 13:57:00
W tej części przedstawione są szczególne przypadki wyrażeń SQL - takie jak modyfikacja kolumn z atrybutem Identity, blokowanie wierszy, czy różnice w składniach złączeń w Oracle i Microsoft SQL Server 2000.
Data: 2003-08-08 01:12:00
W tej części przedstawione jest wyczerpujące porównanie funkcji wbudowanych w SQL Server oraz Oracle.
Data: 2003-08-15 19:04:00
W tej części pokazane są różnice w konstrukcjach kontrolujących przepływ (czyli np. kolejność wykonywania poleceń w skrypcie) pomiędzy Microsoft SQL Server 2000 oraz Oracle. Funkcjonalnie obie bazy danych dysponują podobnymi możliwościami, jednak występuj
Data: 2003-08-22 01:43:00
Mimo że język SQL i bazy relacyjne są dostosowane do wykonywania operacji na zbiorach danych, wielu programistów woli niektóre operacje wykonywać tak jak ma to miejsce w przypadku baz plikowych - przechodząc kolejno po rekordach w zbiorze wyników. W tej c
Data: 2003-09-06 17:44:00
W tej części przedstawione są różne sposoby optymalizacji Microsoft SQL Server 2000. Należy pamiętać, że ten serwer działa zwykle najlepiej wtedy, gdy optymalizację pozostawi się motorowi bazy danych.
Data: 2003-09-24 15:24:00
W tej części przedstawione są istotne uwagi opisujące różnice w obsłudze baz danych Oracle i Microsoft SQL Server przy uzyciu interfjesu ODBC. Równocześnie artykuł zawiera wiele interesujących uwag związanych z wykorzystaniem tego interfejsu we wł
Data: 2003-10-13 12:00:00
W niniejszym dziale wyjaśnione będą różnice między wsparciem replikacji w Oracle oraz w SQL Server firmy Microsoft.
Niniejszy rozdział przeznaczony jest dla programistów, którzy tworzyli aplikacje w systemie Oracle i chcieliby dokonać ich konwersji na Microsoft SQL Server 2000. Opisano tu narzędzia, procesy oraz techniki konieczne do przeprowadzenia pomyślnej konwersji. Podkreślono także istotne elementy projektu pozwalające na tworzenie wydajnych, wysoce współbieżnych aplikacji opartych na SQL Server.
Czytelnikiem docelowym może być nowicjusz, jeśli chodzi o SQL Server oraz jego działanie, ale który powinien mieć solidne podstawy w dziedzinie Systemu Zarządzania Relacyjnymi Bazami Danych (ang. Relational Database Management System - RDBMS) Oracle oraz ogólnych koncepcji związanych z bazami danych. Czytelnik powinien posiadać:
Solidną wiedzę o podstawach Oracle RDBMS.
Ogólną wiedzę na temat zarządzania bazami danych.
Znajomość języków Oracle SQL oraz PL/SQL.
Członkostwo w ustalonej roli serwera sysadmin.
Dla jasności niniejszej prezentacji przyjmuje się, że referencyjną platformą do tworzenia oraz uruchamiania aplikacji jest system operacyjny Microsoft Windows® 2000 oraz SQL Server 2000. Sterownik Visigenic Software ODBC jest używany wraz z Oracle, natomiast sterownik SQL Server ODBC ze SQL Server 2000. SQL Server 2000 zawiera sterownik OLE DB dla Oracle, ale nie będzie on szerzej omawiany w niniejszym rozdziale.
Proces migracji aplikacji może wydać się skomplikowany, gdyż istnieje wiele różnic w architekturze systemów RDBMS. W przypadku SQL Server firmy Microsoft określenia oraz terminologia używane w opisywaniu architektury Oracle mają często zupełnie inne znaczenia. Poza tym zarówno Oracle, jak i SQL Server wprowadziły wiele własnych rozszerzeń do standardu SQL-92.
Jednak z punktu widzenia twórcy aplikacji, Oracle oraz SQL Server obsługują dane w bardzo podobny sposób, a istniejące, dość istotne wewnętrzne różnice między Oracle oraz SQL Server - jeśli potraktować je we właściwy sposób - mają minimalny wpływ na aplikację poddawaną migracji.
Najistotniejszą kwestią zawiązaną z migracją, z którą będzie musiał poradzić sobie programista, jest implementacja standardu języka SQL - SQL-92 - oraz rozszerzeń oferowanych przez każdy RDBMS. Niektórzy programiści używają tylko wyrażeń ze standardowego języka SQL, ponieważ chcą, żeby ich kod był tak uniwersalny, jak to tylko możliwe. Zazwyczaj oznacza to ograniczenie kodu do podstawowego standardu SQL-92, konsekwentnie implementowanego w wielu produktach związanych z bazami danych, włącznie z Oracle oraz SQL Server .
Takie podejście może spowodować niepotrzebną złożoność kodu programu i istotnie wpłynąć na jego wydajność. Przykładowo, funkcja DECODE z Oracle jest niestandardowym rozszerzeniem SQL charakterystycznym dla Oracle. Wyrażenie CASE w SQL Server jest rozszerzeniem SQL-92 wykraczającym poza poziom podstawowy i jest implementowane nie we wszystkich produktach związanych z bazami danych.
Zarówno wyrażenie DECODE z Oracle, jak i wyrażenie CASE SQL Server mogą wykonywać złożone operacje w ramach zapytania. Alternatywą jest wykonywanie analogicznych operacji po stronie kodu w aplikacji klienckiej, co może wymagać pobrania z RDBMS znacznie większej ilości danych.
Także proceduralne rozszerzenia języka SQL mogą sprawiać kłopoty - język PL/SQL z Oracle oraz język Transact-SQL z SQL Server działają podobnie, mają jednak odmienną składnię. Nie ma też dokładnej symetrii między obydwoma RDBMS oraz ich rozszerzeniami proceduralnymi. W konsekwencji programista może się nie zdecydować na używanie procedury przechowywanych czy triggerów. Nie jest to zbyt fortunne, ponieważ mogą one dać istotne korzyści w dziedzinie wydajności oraz bezpieczeństwa, czego nie da się osiągnąć w żaden inny sposób.
Użycie własnych interfejsów programistycznych przysparza dodatkowych problemów. Konwersja programu wykorzystującego Oracle OCI (ang. Oracle Call Interface) często wymaga istotnej inwestycji w zasoby, dlatego w przypadku tworzenia aplikacji, która ma używać wielu RDBMS, należy wziąć pod uwagę wykorzystanie interfejsu ODBC (ang. Open Database Connectivity).
Interfejs ODBC zaprojektowano do współpracy z wieloma systemami zarządzania bazami danych. ODBC zapewnia spójny interfejs programowania aplikacji (API - ang. application programming interface) współpracujący w różnymi bazami danych dzięki sterownikom przeznaczonym dla konkretnych baz danych.
Spójny API oznacza, że wszystkie funkcje wywoływane przez program w celu nawiązania połączenia, wywołania polecenia oraz uzyskania wyników są identyczne - niezależnie od tego, czy program komunikuje się z Oracle czy z Serwerem SQL.
Ponadto ODBC definiuje także standaryzowany interfejs na poziomie wywołań oraz wykorzystuje standardowe sekwencje wyjścia (ang. escape sequences) do określenia funkcji SQL wykonujących wspólne funkcje, ale mających różną składnię w różnych bazach danych. Sterowniki ODBC potrafią dokonać automatycznej konwersji tej składni ODBC na składnię Oracle lub składnię Serwera SQL bez konieczności poprawiania kodu programu. W niektórych sytuacjach najlepszym podejściem jest napisanie jednego programu i pozwolenie ODBC na przeprowadzenie procesu konwersji podczas działania programu.
ODBC samo w sobie nie zapewnia całkowitej niezależności od bazy danych, pełnej funkcjonalności ani wysokiej wydajności dla wszystkich baz danych. Różne bazy danych oraz różni niezależni dostawcy zapewniają też różne poziomy wsparcia ODBC. Niektóre sterowniki implementują tylko funkcje rdzenia API mapowane na inne biblioteki interfejsów. Inne natomiast, np. sterownik ODBC SQL Server, oferują pełne wsparcie Poziomu 2 w rodzimym, wysoko wydajnym sterowniku.
Jeśli program używa tylko rdzenia API ODBC, prawdopodobnie nie wykorzysta możliwych funkcji oraz wydajności niektórych baz danych. Co więcej, nie wszystkie rodzime rozszerzenia SQL mogą być reprezentowane w postaci sekwencji wyjścia ODBC (między innymi wyrażenia DECODE z Oracle oraz CASE z SQL Server).
Powszechną praktyką jest pisanie wyrażeń SQL z wykorzystaniem optymalizatora bazy danych. Techniki i metody poprawiające wydajność w przypadku Oracle niekoniecznie jednak muszą być optymalne w przypadku SQL Server 2000, gdyż interfejs ODBC nie jest w stanie przetłumaczyć technik z jednego RDBMS do innego.
ODBC nie chroni również aplikacji przed użyciem charakterystycznych dla danej bazy danych funkcji oraz poprawek polepszających wydajność, ale by to osiągnąć aplikacja potrzebuje pewnych właściwych dla danej bazy danych fragmentów kodu. ODBC ułatwia zachowanie spójności struktury programu oraz zapewnia że większość elementów będzie niezależna od konkretnej bazy RDBMS.
SQL Server 2000 wykorzystuje OLE DB zawarte w samych komponentach SQL Server . Poza tym twórcy oprogramowania powinni brać pod uwagę OLE DB przy tworzeniu nowych projektów dla SQL Server 2000. Microsoft dołącza do pakietu SQL Server 2000 mechanizm zapewniający OLE DB do Oracle 8.
OLE DB to otwarta specyfikacja zaprojektowana do budowania na funkcjach ODBC, który stworzono do uzyskiwania dostępu do relacyjnych baz danych. Zaś OLE DB zaprojektowano do uzyskiwania dostępu do relacyjnych oraz nie-relacyjnych źródeł informacji, takich jak serwery ISAM/VSAM i hierarchiczne bazy danych, magazyny w postaci systemów plików oraz poczty elektronicznej, tekst, dane geograficzne oraz graficzne, a także własne obiekty biznesowe.
OLE DB definiuje kolekcję interfejsów COM "opakowujących" różne usługi systemów zarządzania bazami danych oraz umożliwiających tworzenie komponentów programowych implementujących takie usługi. Komponenty OLE DB składają się z dostawców danych (zawierających i ujawniających dane), konsumentów danych (wykorzystujących dane) oraz komponentów usługowych (przetwarzających i transportujących dane, na przykład procesory zapytań oraz mechanizmy kursora).
Interfejsy OLE DB są zaprojektowane tak, aby pomagały w łatwej integracji komponentów - tak by dostawcy komponentów OLE DB mogli szybko dostarczać na rynek wysokiej jakości komponenty OLE DB. Dodatkowo OLE DB zawiera "most" do ODBC. Dzięki temu można wykorzystać dostępne sterowniki ODBC z poziomu aplikacji, które korzystają z OLE DB.
W celu wspomożenia implementacji systematycznej migracji z Oracle do SQL Server, każdy dział obejmuje przegląd istotnych różnic między bazami danych Oracle oraz systemem Microsoft SQL Server 2000. Niniejszy rozdział obejmuje także okoliczności konwersji, zalety systemy SQL Server 2000 oraz wiele przykładów.
W publikacji znajdują się także odwołania do zewnętrznych źródeł opisujących dane zagadnienie bardziej szczegółowo.
Aby móc rozpocząć pomyślną migrację, należy najpierw dobrze poznać i zrozumieć podstawową architekturę oraz terminologię systemu SQL Server 2000.
W systemie Oracle mianem bazy danych określa się całe środowisko RDBMS Oracle. Pojęcie to obejmuje następujące komponenty:
Procesy bazy danych Oracle oraz bufory (instancje).
Przestrzeń tabel (ang. tablespace) SYSTEM zawierającą jeden scentralizowany katalog, który składa się z jednego lub więcej pliku danych.
Inne przestrzenie tabel zgodnie z definicją DBA (opcjonalnie) – z których każda składa się z jednego lub więcej plików danych.
Dwa lub więcej aktywnych Dzienników Powtórzeń (ang. online Redo Logs).
Zarchiwizowane Dzienniki Powtórzeń (opcjonalnie).
Różne inne pliki (plik kontrolny, init.ora, config.ora itd.).
Baza danych SQL Server zapewnia logiczną separację danych, aplikacji oraz mechanizmów bezpieczeństwa. Instalacja SQL Server (instancja) jest w stanie obsłużyć wiele baz danych. Aplikacje utworzone przy użyciu SQL Server mogą używać baz danych w celu logicznego podziału zakresów działalności firmy. Na jednym komputerze może znajdować się wiele instancji SQL Server, a każda instancja może posiadać wiele baz danych.
Każda baza danych SQL Server może obsługiwać grupy plików (ang. filegroup), które umożliwiają dystrybucję fizycznego rozmieszczenia danych. Grupa plików SQL Server dzieli na kategorie pliki systemu operacyjnego zawierające dane z pojedynczej bazy danych SQL Server, aby uprościć administrację bazą, np. tworzenie kopii zapasowych. Grupa plików jest właściwością SQL Server i nie może zawierać plików systemu operacyjnego więcej niż jednej bazy danych, choć pojedyncza baza danych może zawierać więcej niż jedną grupę plików. Do utworzonej bazy danych można dodawać grupy plików.
Porównanie organizacji Oracle i SQL Server
Serwer SQL standardowo instaluje także następujące bazy danych:
model – szablon dla wszystkich nowo tworzonych baz danych użytkownika;
tempdb, która jest bazą danych podobną do tymczasowej przestrzeni tabel systemu Oracle pod tym względem, że jest używana jako tymczasowy bufor operacyjny oraz do operacji sortowania. (W odróżnieniu od tymczasowej przestrzeni tabel systemu Oracle, użytkownicy SQL Server mogą tworzyć tymczasowe tabele, które są automatycznie porzucane w momencie wylogowania się użytkownika);
msdb – obsługa Agenta SQL Server (ang. SQL Server Agent) oraz jego zaplanowane zadania, alarmy oraz informacje o replikacji;
pubs oraz Northwind – jako przykładowe bazy danych służące do treningu i nauki.
Więcej informacji na temat standardowych baz danych można znaleźć w dokumentacji SQL Server Books Online.
Każda baza danych Oracle działa na jednym scentralizowanym katalogu systemowym lub słowniku danych znajdującym się w przestrzeni tabel SYSTEM. Każda baza danych SQL Server 2000 utrzymuje własny katalog systemowy, który zawiera informacje o:
obiektach bazy danych (tabelach, indeksach, procedurach przechowywanych, widokach, triggerach itd.);
ograniczeniach;
użytkownikach oraz zezwoleniach (prawach dostępu);
zdefiniowanych przez użytkownika typach danych;
definicjach replikacji;
...
P_i_C