Skalowalność bazy Oracle 10g to tylko jedna z wielu jej zalet. Kolejna odsłona czołowego motoru bazodanowego upraszcza zarządzanie i ułatwia życie programistom.

Zmiana konwencji nazewniczej czołowego produktu Oracle'a ma świadczyć o powadze, z jaką firma traktuje ideę przetwarzania rozproszonego. Zamiast słynnego "i" ery Internetu, mamy obecnie do czynienia z "g" nawiązującym do ery grid computing. Rozszerzona funkcjonalność w dziedzinie przetwarzania rozproszonego i interfejsy do komunikacji poprzez Web Services to jednak tylko część nowości, jakie niesie baza Oracle 10g.

W nowej edycji bazy Oracle zawarł wiele nowych funkcji. Firma położyła duży nacisk na uproszczenie zarządzania lub wręcz automatyzację wielu czynności administracyjnych. Zmiany na lepsze dotyczą współpracy bazy z systemami pamięci masowych, zabezpieczania danych przed uszkodzeniem, a także bezproblemowego cofnięcia zmian wprowadzonych do bazy omyłkowo. Udoskonalone mechanizmy wymiany danych z otoczeniem pozwalają na przenoszenie dużych ilości danych strukturalnych i metadanych bazy danych z prędkością dorównującą kopiowaniu plików. Nowa baza wnosi kilka eleganckich rozwiązań z punktu widzenia projektowania aplikacji, np. zmiennoprzecinkowe typy danych czy wprowadzenie funkcji parsowania wprost w motorze bazy danych. Skalowalność baz Oracle wzrosła do niewyobrażalnych 8 Exabajtów (8 mln TB).

Wariacje na temat "g"

Owo "g" w nazwie to zabieg w dużej mierze marketingowy, jako że funkcje przetwarzania rozproszonego istniały w ofercie Oracle'a od momentu pojawienia się RAC (Real Application Cluster). Klaster RAC 9i Release 2 umożliwiał rozłożenie przetwarzania na maksymalnie 4 węzły, a w niektórych sytuacjach 8 - choć nominalnie pozwalał na zbudowanie farmy liczącej 64 węzły. Ten rozdźwięk między możliwościami teoretycznymi a rzeczywistymi bierze się stąd, że zrównoleglenie intensywnego przetwarzania transakcyjnego wymaga szybkiej komunikacji między węzłami. Im więcej węzłów, tym mniejsze czasy opóźnień będą tolerowane. W praktyce maksymalna liczba węzłów klastra zależy od mechanizmu klastrowego na poziomie systemu operacyjnego.

Wraz z premierą bazy 10g Oracle przedstawił nową wersję technologii RAC, która pozwala na uruchamianie bazy danych na klastrze składającym się z więcej niż 64 węzłów. Dopóki jednak nie pojawią się pierwsze niezależne testy, dopóty liczbę tę należy uznawać za czysto teoretyczną. Jednak możliwość wykorzystania nawet 4 niezależnych węzłów (liczba węzłów uważana za "wykonalną" w przypadku Oracle 9i) może w pewnych zastosowaniach być atrakcyjna. RAC 10g ma pozwolić firmom "uwolnić się" od wysokich kosztów związanych z dużymi serwerami SMP na rzecz standardowych serwerów x86.

Skalowanie bazy przez dodawanie kolejnych serwerów może się wydawać tańsze, i w wielu sytuacjach zapewne rzeczywiście będzie. Na problem trzeba jednak patrzeć w szerszej perspektywie. Duże firmy kupujące serwery tej klasy co HP Superdome, IBM p690, Sun Star Fire 15000 doskonale wiedzą, dlaczego je kupują. Oprócz dużego bezpieczeństwa i łatwości zarządzania, chodzi im zwykle o możliwość dynamicznego przydzielania mocy obliczeniowej różnym aplikacjom korzystającym z różnych baz danych oraz, co nie jest bez znaczenia, o obniżenie kosztów budowy i przygotowania do działania zapasowego ośrodka przetwarzania (więcej na ten temat można przeczytać w CW32/2003 w bloku tematycznym o konsolidacji serwerów).

Wiele wskazuje na to, że podpierająca się koncepcją grid computing argumentacja Oracle'a jest wymierzona przede wszystkim w segment rynku, którego nie stać na potężne, drogie serwery SMP. W wykorzystywanych przez ten segment tanich serwerach intelowskich funkcje dynamicznej rozbudowy i przydzielania mocy obliczeniowej nie są na razie dostępne (posiadające je 16-procesorowe urządzenia IBM xSeries 440 czy 32-procesorowe serwery Unisys ES7000 trudno uznać za typowych przedstawicieli tej klasy). Szkoda tylko, że dostępne dzięki RAC łatwe skalowanie dotyczy jedynie aplikacji tworzonych w środowisku Oracle i korzystających z bazy danych Oracle.