sql >> Database teknologi >  >> RDS >> Oracle

CRS 11.2.0

Jeg arbejder på at opgradere vores eksisterende Oracle Cluster Ready Services fra 11.1.0.7 til 11gR2 (11.2.0.1). Tingene går ikke så glat, som jeg havde håbet, og jeg lærer meget om ændringerne i 11gR2. Dette er ikke en mindre opgradering, som forskellene i versionsnummeret antyder. Der har været mange ændringer i CRS 11gR2. De vigtigste ændringer er som følger (uden bestemt rækkefølge):

  • Cluster Ready Services (CRS aka Clusterware) kaldes nu Grid Infrastructure, eller forkortet GRID.
  • Hvis du bruger ASM, er det ikke længere installeret i et separat hjem. Oracle GRID inkluderer Clusterware og ASM i samme hjem nu.
  • Oracle GRID 11gR2 inkluderer nu en SCAN-lytter (Single Client Access Name). For at holde tingene enkle skal du lave en SCAN virtuel IP-adresse ligesom dine sædvanlige VIP'er og registrere dem med DNS. SCAN VIP'en skal være det samme navn som dit klyngenavn. SCAN VIP'en skal have 3 IP-adresser tilknyttet, da Oracle GRID vil starte op til 3 SCAN-lyttere.
  • Oracle GRID 11gR2 understøtter nu multi-casting. Jeg var nødt til at anvende patch 9974223, da min konfiguration brugte en sekundær port til multi-casting. Der er et mutli-cast-testværktøj, som kan hjælpe med at afgøre, om du er konfigureret til multi-casting eller ej.
  • Mens du kan genstarte CRS med "crsctl stop/start crs", var jeg altid vant til "/etc/init.d/init.crs stop/start". /etc/init.d/init.crs scriptet er ikke længere tilgængeligt. Det er blevet erstattet af /etc/init.d/init.ohasd i stedet.

Dette er blot nogle få ændringer, som jeg finder undervejs, mens jeg udfører mine opgraderinger og fejlfinder problemer, der opstår.

Denne opgradering har bevist for mig, at det er værdifuldt at have en RAC testbed, før du arbejder med disse opgaver i dine produktionsmiljøer. Det sidste sted, jeg arbejdede på, havde kun ét RAC-miljø, og det var vores produktionsdatabase. Det blev anset for at være for dyrt at oprette et andet RAC-miljø til udvikling/testning. Min nuværende medarbejder var klog nok til at oprette en RAC testbed, hvor jeg kunne fuldstændig ødelægge tingene og teste, teste, teste, før jeg forsøgte i produktion. Tingene har ændret sig i de senere år, hvor man kan bruge virtuelle maskiner til at opsætte testmiljøer meget billigere end tidligere, hvor vi skulle anskaffe hardware kun til test.

Når det er sagt, ville jeg ønske, at min nuværende RAC-testbed var i et VM-miljø. Hvis det var i en VM, kunne jeg tage et øjebliksbillede af VM'en med CRS 11.1.0 kørende, og hvis jeg løb ind i problemer, der var svære at genoprette, kunne jeg vende tilbage til snapshottet. Som det ser ud nu, hvis jeg løber ind i problemer med opgraderingen, og jeg virkelig laver noget rod, skal jeg manuelt afinstallere alt, geninstallere CRS 11.1.0 og genskabe en database, før jeg kan prøve en CRS 11.2.0 opgradering igen. Dette tager tid, og en VM kunne spare mig for en masse tid her.


  1. Brug for en datetime-kolonne i SQL Server, der automatisk opdateres, når posten ændres

  2. Fordele ved NoSQL-databaser – Alt hvad du behøver at vide

  3. Er der et Oracle svarende til SQL Servers OUTPUT INSERTED.*?

  4. Forbindelse til Db dør efter>4<24 i spring-boot jpa hibernate