Oracle Database 11gR2 "neliels" apskats - speciāli LVOUG ;)

[Edgars R.]

Sveicināti!

Jau kādu laiku atpakaļ man bija iespēja iepazīties ar 11gR2 beta versiju, bet nebija iespējas izteikties. Tagad šāda iespēja ir parādījusies kopā ar 11gR2 oficiālo iznākšanu.  Uzreiz jāsaka, ka viss rakstītais varētu arī nebūt taisnība ;), jo pirmkārt, apraksts ir balstīts uz beta versiju, otrkārt, par daudzām lietām esmu tikai lasījis/dzirdējis, un treškārt, kļūdīties ir cilvēcīgi ;). Tie, kas tiks līdz apskata beigām, būs pelnījuši patiesu apbrīnu par izturību. Jebkurā gadījumā es aicinu ikvienu izteikt savu viedokli un dalīties arī ar savu pieredzi par 11gR2! Kā jau iepriekš minētju, tad oktobra sākumā tiek plānots arī Oracle 11g Release 2 pasākums Rīgā, kur būs iespēja plašāk iepazīties ar jaunumiem. Sekojiet informācijai LVOUG.

Instalācija

Jāsaka, ka 11gR2 instalācijas uzlabojumi ir vairāk saistīti ar vizuālām izmaiņām. OUI vizuāli ir stipri mainījies. Tagad, piemēram,  vizuāli  ir iespējams redzēt iepriekšējos instalācijas soļus kā arī nākamos jebkurā instalācijas posmā.  Tāpat ir nedaudz pamainīta soļu secība un ievadinformācijas daudzums. Kā vēl viens sīks, bet samērā noderīgs uzlabojums ir iespēja noģenerēt skriptus, kas izmaina OS konfigurāciju (pamatā kernel parametrus) saskaņā ar „prerequisites checks” ieteiktiem labojumiem. Pēc šo izmaiņu veikšanas ir iespējams turpināt instalācijas procesu no tās pašas vietas. Es instalēju uz Oracle Enterprise Linux 5, pirms tam izpildot oracle-validated rpm, kas pieinstalēja visas nepieciešamās OS komponentes un veica OS konfigurācijas izmaiņas saskaņā ar Oracle prerequisites,  tomēr vienam kernel parametram man uzrādīja neatbilstību un varēju notestēt šo iespēju. Maza, bet patīkama izmaiņa. Par instalācijas procesa ātrdabības rādītājiem grūti spriest, jo instalēju uz virtuālās mašīnas ar 1GB guest RAM, paralēli veicot citus uzdevumus.

Kā diezgan būtisku 11gR2 jaunumu var minēt Grid Infrastructure. Grid Infrastructure ir viens no instalācijas tipiem, kas instalējas atsevišķā ORACLE_HOME un satur Automatic Storage Management (ASM) un Oracle Restart (RAC gadījumā „clusterware”).  Oracle Restart procesi atbild par Oracle resursu (listener, db instance,db servisi,  asm) pieejamību, piemēram, servera avārijas/reboot gadījumā Oracle Restart automātiski „piestartēs” visus Oracle resursus pareizā secībā.  Tāpat Oracle Restart periodiski monitorē minētos resursus, un avārijas gadījumā tos pārstartē. Principā darbojas kā integrēta „clusterware” (tā arī ir „clusterware” – tikai „apgriezta” versija)  Oracle resursu uzraudzībai viena servera gadījumā.  Es sākumā instalēju db, un tikai pēc tam veicu Oracle Grid Infrastructure instalāciju, kas nav pareizā secība ;). Rezultātā dabūju diezgan nočakarēties, lai reģistrētu ASM resursus ar Oracle Restart, kamēr pašu db un tās „listeneri” ļoti viegli var reģistrēt, izmantojot Enterprise Manager (EM). Ja  instalācija tiek veikta pareizā secībā - vispirms tiek instalēta Grid Infrastructure un tikai pēc tam db, tad resursu reģistrācija ar Oracle Restart tiek veikta  automātiski (nepārbaudīju, bet tā vajadzētu būt ;).  Tāpat SQL*Plus, LSNRCTL un ASMCMD ir integrēti ar Oracle Restart. Tas ir, ja jūs apstādināsiet kādu no resursiem ar iepriekš minētiem utility, Oracle Restart to neuzskatīs kā avāriju un nepārstartēs automātiksi minēto resursu. Rezumējot, ja jūs plānojat izmantot Oracle Restart, tiek rekomendēts izmantot SRVCTL  manuālai Oracle resursu pārvaldībai.  Rezumējot, Grid Infrastructure (standalone)  ir nepieciešams instalēt divos gadījumos:

·         Ja tiek plānots izmantot ASM (Oracle Restart šajā gadījumā ir obligāts)

·         Tiek plānots izmantot tikai Oracle Restart bez ASM

Kā vēl vienu nosacītu jaunumu saistībā ar instalāciju var minēt „deinstall utility”, kas pieejams  visās ORACLE_HOME un paredzēts ORACLE_HOME „deinstall” ar saistītiem konfigurācijas failiem. Tāpat ir diezgan daudz jaunu „feature” RAC instalācijas procesā. Piemēram, Cluster Verification Utility ir integrēts OUI + SCAN konfigurācija (par to citreiz).

Turpmāk nedaudz par 11gR2 jaunām iespējām. Jāsaka, ka 11gR2 satur vairāk kā 100 jaunu „feature”, tapēc šoreiz apskatīšu tikai dažas,  un ļaušu jums izteikties par pārējām ;)  Manuprāt, būtiskākie 11gR2 jaunumi  ir saistībā ar RAC, Clusterware un ASM.  Apgalvojums, protams, ir ļoti subjektīvs, tapēc būtu interesanti uzzināt arī jūsu viedokli. Par RAC uzrakstīšu citu reizi, jo tā ir ļoti apjomīga tēma R2 kontekstā, bet tagad par visu pēc kārtas un sākšu ar ASM jaunumiem.

ASM un ACFS

ASM klastera failsistēma (ASM Cluster Filesystem - ACFS) ir viens no interesantākiem jaunumiem. ACFS ir Oracle izstrādāta „general purpose” failsistēma ar dinamisku volume management un „read only snapshot” atbalstu, kas balstīta uz ASM tehnoloģiju. Tā ir pieejama, izmantojot NAS protokolus (NFS, CIFS) un sākotnēji būs pieejama Win un Linux OS. Lai arī failsistēmas nosaukumā ir „clustered”, to var izmantot arī  kā  „parastu” failsistēmu standalone servera gadījumā, kas papildus nodrošina dinamisku volume manager + read only snapshot iespējas. ACFS pārvaldībai ir pieejami vairāki veidi – OS failsistēmas komandas ar paplašinājumiem (piemēram, mkfs -t acfs -b 4k /dev/asm/volume1  - izveido acfs uz ASM volume), ASM Configuration Assistant  un Enterprise Manager  ar dažiem ierobežojumiem, piemēram, darbībām, kas prasa root privilēģijas. Tā kā ACFS ir balstīta uz ASM, tad ACFS nodrošina gan mirroring, gan striping, izmantojot ASM tehnoloģijas.  Nedaudz patestējot ACFS iespējas, kā vienu no nepilnībām varētu minēt to, ka Oracle Restart konfigurācija neatbalsta ACFS resursu uzraudzību, piemēram, automātisku  failsistēmas “mountēšanu”  pēc  ASM instances avārijas un tās pārstaertēšanas. No otras puses tas nav nekāds lielais trūkums, jo, piemēram,  visas definētās acfs failsistēmas ir iespējams  “piemountēt” ar vienu komandu –  “mount –t acfs –o all”. Apskatoties dokumentācijā, secināju, ka šie ierobežojumi neattiecas uz pilnu clusterware versiju, kas tiek instalēta kā Oracle Grid Infrastructure klastera gadījumā, tapēc primāri acfs tomēr ir domāta kā klastera failsistēma.

 Interesanti, ka ASM tagad atbalsta tā saucamo “intelligent data placement” (Oracle lietotais termins ;), tas ir, ASM failiem ir iespējams norādīt, vai tie būs “hot” vai “cold”. Cik saprotu, tad “hot” tipa faili tiek novietoti uz diska “ārējiem” sektoriem, kas uzrāda labāku i/o statistiku. Varbūt kāds var pakomentēt, vai  šāda pieeja tiešām var uzlabot i/o ? To pašu var norādīt, izveidotjot jaunu Volume ar acfs.

Tāpat būtiski ir papildināta ASMCMD (ASM komandrindas interfeiss) funkcionalitāte. Man personīgi ASMCMD likās daudz ērtāks veids darbam ar ASM (failu un disku grupu pārvaldība, pieejas tiesību kontrole, volume pārvaldība) nekā SQL Plus un šī noteikti būs laba alternatīva sysadmin-iem. Kā vēl vienu jaunu ASM “feature” var minēt ASM failu pieejas tiesību kontroli.

Starp citu, RAC gadījumā, OCR un Voting diskus tagad ir iespējams glabāt uz ASM. Šajā gadījumā tiek nodrošināta automātiska Voting Disk backup uz OCR pie jebkurām RAC klastera izmaiņām. Tāpat ASM veiks automātisku Voting disk atjaunošanu bojājumu gadījumā. Var teikt, ka Oracle ir atkal spēris soli uz priekšu storage management virzienā, lai pēc iespējas samazinātu nepieciešamību pēc 3-šo pušu “storage management” risinājumiem. Piemēram, ja jūs plānojat izmantot Oracle Clusterware “ne-Oracle” resursu augstas pieejemības nodrošināšanai, piemēram, veidojot cold-failover apache web serveru klasteri, tad ACFS jūs varat izmantot kā universālu klastera failsistēmu, kas saturēs klastera koplietošanas (shared) failus.

Oracle Clusterware

Oracle Clusterware ir piedzīvojusi salīdzinoši daudz uzlabojumu un jaunumu, tapēc minēšu tikai dažus, manuprāt, interesantākos. Viens no uzlabojumiem ir  klastera tipa komandas (crsctl komandas), kas  tagad darbojas klastera ietvaros nevis tikai konkrētā mezgla ietvaros, piemēram, crsctl check cluster –all. Vēl viens jaunums ir Enterprise Manager (EM) kā “clusterware”  GUI, jo līdz šim bija pieejams tikai komandas interfeiss - crsctl/srvctl (db resursiem).

11gR2 “clusterware”  ir ieviests jauns “koncepts” – server pools, kas nodrošina politikas bāzētu (policy-based) klastera serveru resursu  pārvaldību . Šī koncepta mērķis ir nodrošināt dinamisku klastera resursu piešķiršanu/pārdalīšanu lietojumiem, balstoties uz iepriekš definētu politiku vai tās izmaiņām.  Principā runa ir par klastera serveru resursu dinamisku “partitioning”, izmantojot Server Pools.  

DB gadījumā, definējot  server pool, tiek norādīta kardinalitāte, kas nosaka DB instanču (serveru) skaitu konkrētajā pool-ā (definējot server pool, tas nekādā veidā netiek  piesaistīts pie fiziskiem klastera serveriem). Tāpat tiek definēts, kāda ir konkrētā pool prioritāte un minimālais pieļaujamais DB  instanču skaits, kas tam jāgarantē.  Definējot DB Service, tiek norādīts pool, kurā Service tiks izvietots, pie kam, katrs DB Service var atrasties tikai vienā pool-ā.  Startējot DB Service, datubāzes instances tiks izvietotas pa klastera serveriem dinamiski saskaņā ar definēto server pool politiku. Ja gadījumā kāds no konkrētā pool serveriem avarē, tad saskaņā ar politiku ir iespējama servera “migrācija” no viena pool-a uz citu, lai nodrošinātu definētās politikas izpildi, piemēram, nodrošinātu minimālo DB instanču (serveru) skaitu konkrētajā pool-ā, kurā ir avarējis viens no serveriem. Tāpat, palielinot kāda server pool minimumu, piemēram, ja nepieciešama lielāka skaitļošanas jauda kādam batch uzdevumam, ir iespējama situācija, ka serveris no pool ar mazāku prioritāti tiks migrēts uz pool, kur jānodrošina nepieciešamais serveru minimums saskaņā ar definēto politiku. Lai atbalstītu šādu dinamisku RAC resursu pārvaldību, RAC ir virkne jaunumu, lai pēc iespējas izvairītos no “hard-coded” RAC parametriem, piemēram, SIDi tagad ir iespējami  dinamiski, bet par to citu reizi.

Server pool pieeja varētu būt efektīva gadījumos, kad tiek veikta datubāžu konsolidācija, izvietojot tās uz centralizēta klastera ar salīdzinoši lielu serveru  skaitu (noteikti vairāk kā 2 nodes). Protams, šajā gadījumā ir viens “mazs” priekšnosacījums – visām DB ir jābūt 11gR2…Šī tehnoloģija, manuprāt, ieskicē Oracle nākotnes grid vīziju. Noslēgumā gribu piebilst, ka viss iepriekšminētais ir tikai teorētisks izklāsts, jo  praksē man vēl nav bijusi iespēja pārliecināties, kā tas strādā.

Starp citu, neliela serveru klastera gadījumā, ja tiek konsolidētas vairākas DB, kurām nepieciešams nodrošināt augstu pieejamību, pastāv iespēja izmantot RAC ONE, bet par to citu reizi.

Instance Caging (IG)

Burtiski tulkojot Instance Caging, sanāk instances ielikšana būrī ;), kas to daļēji arī nozīmē.  IG pamatā ir iespēja DB instancei  norādīt pieejamo procesoru  skaitu, kas tai būs pieejams. Tas varētu būt noderīgi, piemēram, gadījumos, ja uz viena servera tiek darbinātas vairākas Oracle instances. Šajā gadījumā būtu iespējams “virtualizēt” katras instances pieejamos procesora resursus. Protams, līdzīgu pieeju var nodrošināt ar virtualizācijas risinājumiem, bet ja nepieciešams CPU resursus sadalīt tikai starp Oracle instancēm, tad IG varētu būt risinājums ar mazāku administrēšanas “overhead”. Lai izmantotu IG, nepieciešams uzstādīt paramteru CPU_COUNT un aktivizēt Resource Manager ar cpu direktīvām.

Smart Flash Cash (SFS)

SFS varētu uzskatīt par Oracle buffer cache paplašinājumu, kas balstīts uz SSD (solid-state disk) tehnoloģiju.  Tā kā SSD diski ir vidēji 100x ātrāki uz lasīšanas operācijām nekā „parastie” un, ņemot vērā, ka tie maksā stipri mazāk kā RAM (apmēram $50 par GB), tas ir salīdzinoši efektīvs un lēts  veids kā paplašināt Oracle buffer cache.  Lai izmantotu SFS, ir pieejami divi jauni parametri: db_flash_cache_file=<filename>, db_flash_cache_size=<size>.  Kā redzms no paramteriem, tad SFS jābūt pieejamam kā failam, kas novietots uz SSD diskiem. SSD var izmantot PCI, SCSI, DIMM pieslēgumus, ja vien tie no Oracle/OS viedokļa „izskatās” kā diski. SFS droši vien būtu efektīvs gadījumos, ja , piemēram, oracle izteikti gaida  uz „db file sequential read”.

Edition based redefinition (EBR)

Lai arī šo „feature” varētu uzskatīt par maznozīmīgu, EBR viennozīmīgi ir mans favorīts 11gR2. EBR ir augstas pieejamības tehnoloģija, kuras mērķis ir nodrošināt datubāzes objektu  (tabulas, skatījumi, PL/SQL, ...)  „upgrade” vai „patching”, neapstādinot aplikāciju.   Vieglāk būtu šo tehnoloģiju nodemonstrēt nekā izstāstīt, bet es mēģināšu to raksturot pāris teikumos ar piemēru. Pieņemsim, ka  tiek plānotas aplikācijas izmaiņas, mainot tabulas struktūru – tiek plānots pievienot jaunu kolonnu un līdz ar to mainīt arī saistīto PL/SQL loģiku, kas referencējās uz šo tabulu. Lai veiktu šādas izmaiņas, visticamāk tiktu sagatavots skripts, kura izpildes laikā tiktu veiktas minētas izmaiņas un konkrētā aplikācija šajā laikā lietotājiem nebūtu pieejama.  Savukārt, EBR nodrošina iespēju veikt šāda veida izmaiņas bez lietojuma „apstādināšanas”.  Lai apraksītu, kā tas tiek nodrošināts, man būtu nepieciešama vēl viena A4 lapa, bet idejas pamatā ir iespēja uzturēt datubāzes objektus „pre-upgrade” un „post-upgrade”  versijās (editions). Citiem vārdiem sakot, nepieciešamās datubāzes objektu izmaiņas (pievienota tabulas kolona un aizpildīta ar datiem, izmainīts PL/SQL) tiek veiktas „post-upgrade” versijas ietvaros, kamēr vienlaicīgi lietotāju sesijas strādā ar „pre-ugrade” sākotnējās versijas datubāzes objektiem. Kad nepieciešamās izmaiņas ir veiktas , jaunās lietotāju sesijas tiek pārslēgtas uz „post-upgrade” datubāzes objektu versijām.  Droši vien daudziem rodas jautājums, kā vienlaicīgi ir iespējams mainīt tabulas struktūru un nodrošināt esošo PL/SQL  izpildi „pre-upgrade” versijas ietvaros. To iespējams nodrošināt ar tā saucamo „editioning view”, kas no aplikāciju viedokļa reprezentē tabulu, kuras struktūru ir plānots mainīt. Papildus vēl tiek izmantoti „cross-edition” trigeri, kas nodrošina tabulas datu uzturēšanu starp versijām. Ja kādam interesē tehniskais izpildījums, varu nosūtīt papildus informāciju. Interesanti, vai izmantojot EBR kādreiz būs iespēja upgreidot arī Data Dictionary ? ;).

Hybrid Columnar Compression (HCC)

Izskatās, ka  „hybrid columnar compression tagad ir pieejams tikai Oracle Exadata Storage Server. Jebkurā gadījumā ļoti ineresanta saspiešanas tehnoloģija. HCC gadījumā datu organizācija datubāzes blokos tiek balstīta uz tabulas kolonnām nevis rindām, kā tas ir realizēts līdz šim, panākot augstāku kompresijas pakāpi. Tabulai ir iespējams definēt divus kompresijas režīmus- „query mode”  vai „archival mode”, kas nosaka kompresijas algoritmu. Pirmajā gadījumā tas ir optimizēts pieprasījumiem, kamēr otrajā gadījumā tiek panākta pēc iespējas augstāka kompresijas pakāpe. HCC atbalsta tikai  „direct –load”operācijas (paralēlos DML,  insert /* +append */), tapēc visticamāk, šī tehnoloģija pārsvarā būs pielietojama DWH risinājumos.  Ja pēc HCC kompresijas tabulai  tiek pievienoti jauni  ieraksti, tie tiek kompresēti ar standarta OLTP kompresijas algoritmu (pieejams kopš 11gR1). Tas pats notiek ar tabulas rindām, kuras tiek izmainītas ar UPDATE.  Es HCC notestēju uz sample datiem, izmantojot tabulu  SH.CUSTOMERS. Kompresējot „query” režīmā, ieguvums bija 8x un „archive” režīmā 12x, salīdzinot ar nekompresētiem tabulas datiem.  Rezultāti, protams, tikai ieskatam, jo nopietnāku testēšanu un analīzi neveicu. Pieļauju, ka table scans varētu būt ātrāki samazināta i/o dēļ, bet indeksu „lookup” noteikti strādās lēnāk. Jebkurā gadījumā 11gR2 ir pieejama advanced compression OLTP kompresēšanas tehnoloģija, kas ir pieejama kopš 11gR1.

Database File System (DBFS)

Droši vien daudzi no jums atceras Oracle Internet File System (iFS), kas bija pieejama Oracle 8i versijas ietvaros kaut kad 90-to gadu beigās. Pagājuši gandrīz 10 gadi un Oracle atkal ir izstrādājis datubāzes failsistēmu.  Ar Oracle 11gR1 parādījās jauna LOB datu tipa realizācija SecureFiles (nesaprotu, kapēc tieši šāds nosaukums ;), kas tika izstrādāta pilnīgi no jauna, lai būtiski uzlabotu veiktspēju darbam ar LOB. Esmu redzējis benchmarkus, kas apgalvo, ka SecureFiles (LOB) lasīšanas/rakstīšanas veiktspējas rādītāji  ir samērojami ar failsistēmu. 11gR2 Oracle ir gājis vienu soli uz priekšu, nodrošinot failsistēmas interfeisu darbam ar LOB datu tipiem. DBFS varētu uztvert kā datubāzes NFS interfeisu. Lai izmantotu DBFS, nepieciešams instalēt DBFS klientu, kas interpretē failsistēmas izsaukumus, kas , savukārt, tālāk tiek apstrādāti ar atbilstošu PL/SQL pakotni. Faili datubāzē tiek glabāti kā LOB, izmantojot SecureFiles. Cik saprotu, tad DBFS klients sākotnēji būs pieejams tikai Linux. Šis risinājums varētu būt ineterants lietojumiem, kas strādā ar LOB datu tipiem, un, kuriem nepieciešams failsistēmas interfeiss uz datubāzi.  Ja kādam sanāk praktiski padarboties ar DBFS, man būtu interesanti uzzināt jūsu pieredzi un komentārus.

Vēl daži jaunumi

Nobeigumā minēšu vēl pāris jaunumu, un viens no tiem ir Automated Degree of Paralelism (ADP). Kā jau pats nosaukums saka priekšā, tad runa ir par SQL pierpasījumu paralēlu izpildi, kur paralēlisma pakāpe tiek noteikta  automātiski, balsoties uz izpildes plānu un nepieciešamajiem resursiem. Iepriekšējās versijās tas bija manuāls process, definējot paralēlisma pakāpi vai nu tabulas līmenī, vai arī izmantojot noklusēto. Kā strādā  ADP ? Pēc SQL pieprasījuma „parsēšanas”, tiek izveidots seriālās izpildes plāns. Ja izveidotā plāna prognozētais izpildes laiks (elapsed time) ir mazāks par noteiktu slieksni, tad plāns tiks izpildīts seriāli. Savukār, ja prgnozētais izpildes laiks pārsniedz norādīto slieksni, tad plāns tiks „pārstrādāts” paralēlai izpildei un optimizators noteiks paralēlisma pakāpi, balsoties uz nepieciešamajiem resursiem visām „scan” operācijam. Visbeidzot paralēlisma pakāpe tiek noteikta, salīdzinot noklusēto paralēlisma pakāpi ar optimizatora ieteikto, un tiek izvēlēta mazākā.  Faktiski šī iespēja nozīmē, ka daudz vairāk pieprasījumu potenciāli varētu tikt izpildīti paralēli, kas savukārt, nozīmē, ka pastāv risks „aizsist” sistēmas resursus. Lai no tā izvairītos, visi pieprasījumi pirms izpildes tiek ielikti FIFO rindā un izpildīti (izņemti no rindas) tikai tad, kad ir pieejams nepieciešamais PQ procesu skaits, lai izpildītu pieprasījumu.

RAC gadījumā  paralēlo pieprasījumu veiktspēju varētu būtiski uzlabot tāda tehnoloģija kā In-Memory Parallel Execution . Šajā gadījumā optimizators izlems, vai pirms pieprasījuma izpildes nav nepieciešams tabulas fragmentus ielasīt RAC mezglu buffer cache atmiņā, balstoties uz tabulas lielumu, lasīšanas biežumu u.c. parametriem. Ja tabulas lielums pārsniegs visu mezglu pieejamo buffer cache apjomu, tad objekts tiks lasīts, izmantojot „direct read” no diska.

Vēl viena interesanta „fīča” ir Automatic Block Repair, kas Oracle Data Guard  konfigurācijas gadījumā veiks automātiski bojātā datu bloka atjaunošanu no primārās vai standby datubāzes atkarībā no tā, vai bojāto bloku saturēs Primary database vai Standby Database.

Sekojot tendencēm industrijā, tagad arī Oracle Secure Backup (t.sk. RMAN) atbalsta rezerves kopēšanu uz Amazon Simple Storage Server (S3) Cloud. Tāpat ir pieejamas jauns kompresijas atbalsts  RMAN.

Tas arī viss! Mans sākotnēji plānotais nelielais apraksts ir sasniedzis nieka  15,000 rakstu  zīmes, aplūkojot tikai nelielu daļu no 11gR2 jaunajām iespējām. Ceru, ka kādam bija arī interesanti. Pat ja nebija interesanti, ar pacietību Tev viss ir kārtībā ;)

Edgars