Oracle Exadata er ikke veldig vanskelig å migrere til IBM Power Systems. Tvert imot.

Etter en migrering til Power Systems får du en bedre totalplattform enn før. Allerede i 2008 introduserte Oracle sin serie med «Engineered Systems» med «Oracle Exadata Database Machine». I 2010 ble dette fulgt av «Exalogic» og deretter i 2012 med «Exalytics».

Spesifikt fokus for systemene:

• Exadata spesialiserer seg på å kjøre Oracle-databaser.
• Exalogic spesialiserer seg på å kjøre Oracle-systemprogramvare.
• Exalytics beskrives som verdens første konstruerte system, spesielt utviklet for å levere høyytelsesanalyse, modellering og planlegging.

Oracle legger vekt på at dette er «designede systemer», med spesielt hensyn til hvordan de er designet, integrert og produsert av Oracle for Oracle.

Med andre ord, det høres ut som det er relativt vanskelig å endre og migrere til et annet system. Men er det virkelig slik?

I utgangspunktet er Exadata et x86-system som kjører Oracle Linux. En rød tråd i alle Oracle Engineered Systems er at serverne er bygget med industristandardkomponenter, inkludert:

• Intel x86-prosessorer
• Infiniband-nettverk
• Lagringsservere bygget med PCI flash-teknologi
• Exadata Smart Flash cache og harddisker
• Oracle RAC
• Andre produkter fra Oracle

Exadata kjører standard Oracle-databasen, den samme som kjøres på IBM Power Systems. Den kan også kjøre et hvilket som helst program som fungerer med Oracle-databaser, akkurat som Power gjør, selv om Oracle på det sterkeste fraråder å kjøre noe annet enn databaser på Exadata.

 De viktigste komponentene i Exadata er:

• Databaseserver
• Lagringsserver
• InfiniBand-nettverk

Det er viktig å huske at systemer ikke kommer med Oracle-programvarelisenser. Kunder må derfor kjøpe lisenser for Oracle-databasen og systemprogramvaren for Oracle Exadata separat. De aller fleste kunder oppfordres også til å skaffe lisenser for Oracle RAC og Oracle-partisjonering.

Hvilke funksjoner har Exadata som er unike og kan forårsake problemer under en migrering?

HCC (Hybrid Columnar Compression)

HCC er en spesiell type komprimering som bruker en kombinasjon av både rad- og kolonnemetoder for å lagre data. Denne funksjonen støtter bare "masselastede data" og er ikke laget for å brukes med data som endres ofte, for eksempel OLTP.

HCC-datalagring er organisert i logiske strukturer kalt komprimeringsenheter (CUs). Hver CU inneholder flere Oracle-blokker. HCC gjelder kun for tabellsegmenter og ikke indeks- eller loggsegmenter.

Denne komprimeringsmetoden muliggjør vanligvis større komprimering enn andre metoder som Oracle Advanced-komprimering (OLTP) og kan redusere mengden fysisk diskplass og dataskanningstid som kreves. Men det er verdt å huske at høy kompresjon eller dekompresjon kan ha en svært negativ innvirkning på ytelsen.

Før du flytter HCC-tabellene til en annen plattform, må de konverteres til vanlige tabeller. Dette gjøres enkelt via kommandoen "change table move". Konverteringen må imidlertid gjøres med nedetid, og varigheten avhenger av størrelsen på tabellene.

Selv om denne funksjonen kan føre til økt migreringskompleksitet, forhindrer den ikke vellykket databasemigrering. IBM har verktøy som hjelper til med å evaluere og analysere HCC-funksjonen samt de fleste funksjonene i Exadata.

Smart Flash Caching

Exadata Storage Server inneholder noe flash-lagring implementert som PCI-flash-kort. Denne funksjonen fungerer som en intelligent lese-/skrivebuffer over permanent lagring, og den skaper heller ikke migrasjonsproblemer. IBM Flash Storage for IBM Power og AIX-systemer brukes i stedet for denne funksjonen.

Smarte skanninger, celleavlastning og lagringsavlastning

 Å eliminere tiden det tar å overføre overflødige data mellom lagrings- og databasenivå er den store utfordringen med Oracle ettersom de har brukt Exadata til å løse dette.

Hovedkonseptet er lastfordeling ved å flytte behandlingen fra databasenodene (databaseserveren) til det intelligente lagringslaget. Relieffet, som kun kan brukes til full tabellskanning og rask indeksskanning, gjør at data kan filtreres så snart de er lastet inn fra lagring. Det reduserer mengden data som databaseverdier trenger å behandle. Dette er en av de største flaskehalsene i systemer med flere terabyte eller større databaser.

Ytelse er en nøkkelfaktor i Exadata for Power Systems. Det er viktig under evalueringsfasen å forstå og analysere antall I/O-avlastningsspørsmål som utfører komplette tabellskanninger da denne funksjonen ikke er tilgjengelig på Power Systems. Dette er problemer som kan håndteres på flere måter for å sikre at det ikke påvirker ytelsen når du kjører i et Power system.

Det er viktig å huske at relief er en Exadata-funksjon som kan forbedre ytelsen til Exadata-systemet. Det vil ikke forårsake noen problemer i tilfelle en migrering til et Power System.

I/O Resource Manager (IORM)

Designet for å forbedre funksjonaliteten til Oracle Resource Manager, begrenser I/O Resource Manager faktisk I/O på databaseinstansnivå. Det er alternative I/O-strupefunksjoner tilgjengelig på lagringsnivå i ikke-Exadata-miljøer. Ytterst få Exadata-kunder bruker denne funksjonen, men i så fall gir den ingen problemer med en eventuell migrering.

Lagringsindeks

Lagringsindekser er minnebaserte strukturer som bidrar til å redusere mengden fysisk I/U som kreves av en Exadata Storage Server. Lagringsindeksen vil ikke forårsake noen problemer ved migrering av Exadata Oracle-databasen til Power System.

Selv om Exadata har noen funksjoner som bare er tilgjengelige på disse systemene, kan de fleste av dem erstattes med mer vanlige Oracle-funksjoner og maskinvarealternativer ved migrering til IBM Power Systems.

Som tidligere nevnt har IBM spesifikke verktøy for å analysere, vurdere og forstå hvordan alle funksjonene til Exadata brukes for kundens arbeidsmengde. De gir innsikt og kunnskap om hvordan man best implementerer applikasjonene på IBM Power Systems.

Oppsummert er det ingen Exadata-funksjoner, spesifikke eller på annen måte, som vil forhindre en migrering til Power Systems.

Migreringsprosessen for Exadata til Power Systems – slik ser den ut!

1. Samlet vurdering er det første trinnet og er vanligvis helt gratis for klienten. 

2. Når evalueringen er fullført, velges riktig migreringsmetode basert på følgende databasestatistikk:

• Størrelse
• Versjoner
• Avbruddsvindu (nedetid)
• Brukte applikasjoner
• Kompleksitet (datatyper, databaselayout og så videre)
• Kilde- og målarkitektur/konfigurasjoner
• Tilkobling (plassering og tilkoblingshastighet mellom kilde og destinasjon)

3. Kundens operasjonelle krav, inkludert nedetid, applikasjonsavhengigheter og avbruddsperioder, er avgjørende for en vellykket migreringsplan.

4. Ulike migreringsverktøy kan brukes, inkludert standard Oracle-verktøy som eksport/import, transportable tablespaces (TTS), inkrementelle TTS, Golden Gate og andre replikeringsverktøy, og IBM XenoBridge-databasemigreringsverktøy.

5. Fjerntilgang er foretrukket, og migreringshjelp på stedet er tilgjengelig når det er nødvendig.

6. Kunden er ansvarlig for å teste migreringen.

Exadata for IBM Power Systems - To eksempler!

Nedenfor er to eksempler på organisasjoner som har migrert fra Exadata til Power Systems.

Største nærbutikkkjede i Latin-Amerika
Oppdrag: Migrer en 120 TB database • Arbeidsbelastning - DSS
Avbruddsvindu: 12 timer
Tidsområde: 8 uker
Metode/verktøy: varm/kald bruk med XenoBridge og Shareplex replikering
Fordeler: Høyere ytelse, mindre fotavtrykk, høyere pålitelighet og reduserte lisenskostnader

Skandinavisk strømselskap
Omfang: Migrer en 19 TB database • Arbeidsbelastning - OLTP
Avbruddsvindu: 3 timer
Tidsområde: 3 dager
Metode / verktøy: Transportable Table Spaces (TTS)
Fordeler: Doblet ytelse per kjerne, høyere utnyttelsesgrad, reduserte kostnader.

Oppsummert er det ingen funksjoner med Exadata som hindrer migrering til IBM Power Systems. Det åpner nye spennende dører for organisasjoner som ønsker å redusere kostnadene og samtidig ønsker å øke ytelsen.