For ikke så længe siden havde jeg brug for at opgradere Oracle Clusterware og RDBMS fra 11.1.0.7 til 11.2.0.2. Jeg har masser af erfaring med Oracle RDBMS-softwaren, men jeg formoder, at jeg er som de fleste DBA'er, fordi min Clusterware-oplevelse ikke er på samme niveau som min RDBMS-oplevelse. Så selvom jeg ikke var bange for at opgradere RDBMS-softwaren, nærmede jeg mig Clusterware-opgraderingen med en vis grad af nervøsitet. Ganske vist er denne uro født ud af en lavere grad af erfaring med produktet. Så før jeg forsøgte i produktionen, testede jeg, testede og testede så meget, jeg kunne.
Opgraderingen af Clusterware gik problemfrit takket være masser af planlægning og test.
Efter opgraderingen reflekterede jeg over, hvad der gik rigtigt og hvad der gik galt, og hvad jeg kunne gøre anderledes i fremtiden. Det gik op for mig, at jeg kunne have skruet helt op for Clusterware-opgraderingen, blæst Clusterware-softwaren væk og stadig være i stand til at installere Clusterware fra bunden og være i stand til at få min RAC-database op at køre. Dette indlæg viser de trin, jeg tog i et testmiljø for at udføre denne opgave. Så hvis du finder dig selv med en totalt skruet opgradering eller installation af Clusterware, er der ingen frygt, for så længe du stadig har dine databasefiler, vil du være i stand til at få tingene op at køre. Hvis din Clusterware-opgradering mislykkedes, bliver du nødt til at rette årsagen til fejlen, før du fortsætter. Så hvis du havde en dårlig klyngeforbindelseskonfiguration eller ugyldig lagerplads til dine stemmediske, skal du løse disse problemer, og så kan du følge disse trin.
Jeg har en gyldig database med alle mine datafiler i delt lager tilgængelig for alle noder i klyngen. Min test har to noder til klyngen. Det antages også, at databasen blev lukket rent ned. Dette papir antager, at databasenavnet er ORCL.
Bemærk:Hvis din database, du tilføjer til RAC, allerede var en del af RAC, kan du springe trin 9-11 over. Trin 9-11 er påkrævet, hvis du også konverterer databasen fra en enkeltforekomstdatabase til en Oracle RAC-database, mens du tilføjer den til Clusterware.
Trin
1. Tag en kold backup af dine databasedatafiler. Hvis der sker noget, kan du altid gendanne fra sikkerhedskopien ved blot at kopiere filerne fra mediet.
2. Sørg for, at noderne er ryddet op fra Clusterware-installationen/-opgraderingen. Se Metalink Note 239998.1 for detaljerede instruktioner, hvis det er nødvendigt.
3. Installer Oracle Clusterware korrekt. Du burde have rettet de problemer, der fik dette trin til at mislykkes i første omgang.
a. Bekræft, at klyngen er oppe og kører.
i. $CRS_HOME/bin/crsctl statusserver
1. Alle noder i klyngen skal være ONLINE.
4. Installer Oracle RDBMS på klyngen.
a. OUI'en bør finde Clusterware og tilbyde at udføre en RAC-installation.
5. Tænd DBCA'en for at oprette en shell-database. Vi bruger DBCA til at konfigurere alt i CRS for os.
a. Vælg mulighederne for at oprette en RAC-database.
b. Brug samme navn som din eksisterende database.
c. Opret shell-databasen på alle noder i klyngen.
d. Brug en fælles placering for databasefilerne, men overskriv ikke dine eksisterende datafiler.
6. Luk skal-databasen
a. srvctl stop database –d orcl
7. Konfigurer din SPFILE
a. Hvis du har din gamle databases SPFILE:
i. Placer filen på delt disk.
ii. Opdater $ORACLE_HOME/dbs/initorcl.ora for at pege på den korrekte SPFILE-placering. Gør dette på alle noder
b. Hvis du ikke har en SPFILE, skal du oprette en PFILE fra bunden og derefter bruge kommandoen CREATE SPFILE FROM PFILE til at oprette en SPFILE.
i. Sørg for, at parameteren CONTROL_FILES peger på den korrekte placering, ikke shelldatabasens kontrolfiler.
c. (Valgfrit) Hvis du har en adgangskodefil, skal du kopiere den til delt lager og derefter opdatere softlinket i $ORACLE_HOME/dbs (på alle noder) for at pege på adgangskodefilen. Hvis du ikke har en adgangskodefil, kan du oprette en senere, hvis det ønskes.
8. Opdater CRS med SPFILE-placering (som root)
a. cd $CRS_HOME/bin
b. ./srvctl config database –d orcl
i. Outputtet skulle fortælle dig, at SPFILE er på placeringen af shell-databasen
c. ./srvctl ændre database –d orcl –p /correct_path/spfileorcl.ora
i. Udfør trin 8b for at bekræfte, at ændringen har fundet sted.
ii. Bekræft også ændringen på den anden node. Du skal kun køre denne modifikationskommando én gang for alle noder.
9. Rediger SPFILE'ens indhold.
a. sqlplus /nolog
b. forbinde / som sysdba
c. oprette pfile=’/home/oracle/pfile.txt’ fra spfile=’/path_to_spfile/spfileorcl.ora’;
d. Åbn p-filen i en teksteditor og foretag følgende ændringer:
i. Tilføj:
1. *.cluster_database=true
2. *.cluster_database_instances=2
3. orcl1.instance_number=1
4. orcl2.instance_number=2
5. orcl1.thread=1
6. orcl2.thread=2
ii. Skift parameteren *.undo_tablespace til orcl1.undo_tablespace
e. Brug p-filen til at ændre sp-filen
i. opret spfile=’/path_to_spfile/spfileorcl.ora’ fra pfile=’/home/oracle/pfile.txt’;
10. Opret et nyt UNDO tablespace for den anden instans.
a. eksport ORACLE_SID=orcl1
b. sqlplus / as sysdba
c. opstart
d. opret fortryd tablespace undotbs2-datafil '/path/undotbs02.dbf' størrelse 30m;
e. ændre systemsæt undo_tablespace=undotbs2 scope=spfile sid=’orcl2′;
11. Opret gentag-logs for den nye tråd
a. ændre database tilføj logfil tråd 2 gruppe 10 '/path/redo10.log' størrelse 50m;
b. ændre database tilføj logfil tråd 2 gruppe 11 '/path/redo11.log' størrelse 50m;
c. ændre database tilføj logfil tråd 2 gruppe 12 '/path/redo12.log' størrelse 50m;
d. ændre database aktiver offentlig tråd 2;
12. srvctl start database –d orcl
På dette tidspunkt har du nu installeret Clusterware fra bunden og tilføjet en eksisterende database til den. Nu hvor jeg har en gennemprøvet metode til at tage ethvert sæt databasefiler og tilføje dem til enhver clusterware-installation, har jeg sænket mine nervøsitetsniveauer, når jeg udfører Clusterware-opgraderinger på produktionssystemer. Selvom jeg laver en total rod af ting, kan jeg blæse Clusterware væk, geninstallere den og derefter tilføje databasen til Clusterware og få min RAC-database op at køre på ingen tid.