Sådan får du Oracle XE i luften igen efter en Amazon AWS Cloud nedlukning

En af fordelene ved skyen er at man smidigt kan skalere sit brug efter behov, inklusiv helt at lukke sin løsning ned i perioder, og samtidig kun betale for det forbrug man har. Dette er dog ikke nødvendigvis helt problemfrit, hvilket jeg vil give et real-life eksempel på her.

Vi har tre kunder der næsten på samme tid kom til os med en opgave omkring etablering af et medio-miljø, som skulle være en præcis kopi af deres produktionsmiljø, hvori der kører en version af det software vi har udviklet til dem. Medio-miljøet skulle bruges til integrationstest med en fælles central service i EU, når der kom nye videreudviklede versioner af det format, der skulle udveksles og det var blevet bygget ind i softwaren.

Tidligere havde vi kunnet nøjes med vores interne testservere, så kravet om et selvstændigt medio miljø, der kunne køre uforstyrret i dagevis nogle få gange om året var nyt. Men det var et krav fra EU og det kom så sent i processen, at ingen af kunderne havde budget til at indkøbe og få hostet servere, hverken fysiske eller virtuelle for at løse opgaven.

Så valget faldt naturligt på at lægge dem i skyen. Der var ingen oppetidskrav, der ville kun være tale om testdata, og kunderne ville så kun skulle betale for den periode hvor testene skulle køre. Vi valgte sammen med kunderne Amazons AWS cloud som platform, da deres IAAS baserede sky ikke ville kræve nogen ændringer af softwaren. Vi launchede to servere pr. kunde som hhv. frontend og backend og installerede vores software sammen med en gratis Oracle 11g XE database, kørte tests, lagde efterfølgende i produktion på normal vis, slukkede AWS serverne og alle var glade – lige indtil nu ca. 6 måneder senere, hvor serverne skal startes igen for at teste næste version af softwaren.

Det er nemlig i et simpelt Amazons AWS server setup ikke muligt at beholde en unik identifikation for sin serverinstans, hvis den lukkes ned i en periode. Rent teknisk nedlægges den af Amazon, og en ny med dit image oprettes når du starter den igen. Så både serverens navn, det eksterne DNS navn, det interne DNS navn, den eksterne IP og den interne IP er nye. En evt. fast IP fra Amazon hjælper ikke, da den blot er en pegepind der skal tilknyttes til serveren ved hver opstart.

Oracle XE databasen er ikke så vild med at alt hvad den burde kunne stole på omkring servernavn og evt. IP ændres omkring den. Selve databaseinstansen kører fint videre, men dens lytteproces gør ikke og dermed er det ikke længere muligt at logge på den, med mindre man selv er på serveren.

Hvad gør man så?

I mange tilfælde vil man så blot droppe lytteprocessen og bygge en ny med den tilhørende konfigurations software – det tager kun 1 minut, men den er ikke med i den gratis Oracle XE. Man er derfor nødt til at gå tilbage til fortiden og gøre det i hånden. Heldigvis er det ikke svært og det tager kun 3 minutter, når man finder ud af, hvilke af AWS’ navne der kan bruges som identifikatorer i hvert tilfælde. Desværre skal det så gøres hver gang man har haft serveren stoppet. Dette kan man dog muligvis scripte sig ud af.

Her er de få trin der skal til:

  1. Ret din SQLNET.ORA fil til i så den får old-school setup. Dvs. at den ved hvilken database den er tilknyttet ved opstart i stedet for, at bruge den mere moderne automatiske tilknytning. Det gøres ved at tilføje følgende som tredje punkt i filen:
    (SID_DESC=
    (GLOBAL_DBNAME=XE)
    (ORACLE_HOME = C:\oraclexe\app\product\11.2.0\server)
    (SID_NAME=XE)
    )Stien skal naturligvis ændres til den rigtige
  2. Ret yderligere din SQLNET.ORA fil til i så den får sit nye interne navn som sit eget navn. Det vil så se omtrent således ud:
    (ADDRESS = (PROTOCOL = TCP)(HOST = ip-10-2-65-212.ec2.internal)(PORT = 1521))
  3. Genstart listeneren enten med “lsnrctl stop / start”, eller ved at genstarte services. Det er ikke nok at køre ”lsnrctl reload”
  4. Ret også gerne din TNSNAMES.ORA til at bruge det nye interne servernavn, så connections internt på serveren kører uden problemer

Det er det hele. Databasen accepterer igen connections på sædvanlig vis, så nu mangler man blot at tilrette konfigurations-filerne i den software der tilgår databasen for at det hele kører igen. Da man typisk kører både frontend og backend i det samme Amazon cloud center, kan man med fordel også bruge det interne DNS navn til dette.

Så når man blot kender den gamle listener syntax og ved at man skal bruge det interne AWS DNS navn er det ikke det store problem, at få Oracle XE i luften igen på en Amazon AWS instans, der har været lukket ned i en periode. Men det vil bestemt være en god ting hvis Amazon ville ændre deres setup, så de tillod blot én server identifikator at bestå på tværs af nedlukninger!

I have been working as a system developer, data modeler and DBA on the Oracle platform using SQL, Pl/SQL, Forms, Reports, JSP, HTML and Javascript since 1996, and have been involved in both client/server and web-based projects for 25+ different customers. I'm normally known as a problem solver