Oracle Datenbank 12c In-Memory Cache Option Architektur ... · Datenbanken sind unsere Welt Oracle...

DatenbankensindunsereWeltwww.dbmasters.at

OracleDatenbank12cIn-MemoryCacheOption

Architektur,Einführung,HighlightsundPOCErfahrungen

DOAGWebinar10.März2017


IngChristianPfundtnerOCA,OCP,OCE,OCM,ACE● OracleDatenbankSpezialistseit1993

● Über23JahreErfahrungimOracleDatenbankHighEndConsultingundTroubleshooting

● 20JahreErfahrungalsOracleDatenbankTrainerimHighEndBereich

– https://www.dbmasters.at– https://www.youtube.com/channel/UCj2tIsTtnZWcQSbX2aVRssQ– https://www.xing.com/profile/Christian_Pfundtner

DOAGWebinarOracle12cInMemory


WeristDBMasters?

● GegründetDez2010,2016über1.6Mio EuroUmsatz● 8Mitarbeiter,davon6Techniker,fünfOCMs● OracleSpezialisierungenimBereichOracle11gDatenbank,Oracle11gReal

Application ClusterundOracle11gPerformanceTuning

WirunterstützenSievonderApplikation/DatenbankbishinunterzurInfrastruktur/StorageundhabendamiteinenganzheitlichenAnsatzzumThemaPerformance.



AuszugausderKundenliste



Themenübersicht

● Architektur– OracleIn-MemoryCacheOption● EinführungundUmsetzungvonIn-MemoryCacheOption● RealWorldBeispieleundErgebnisse● VergleichSAPHANAversusOracleIn-MemoryDatabaseCacheOption



● VoraussetzungenfürsinnvolleIn-MemoryCacheNutzung● SGABereichfürIn-MemoryCache● WoistIn-Memorybesondersschnell● Oracle12cRelease2InMemoryNeuheiten● ZusammenspielmitanderenOptionenundStrukturen

Architektur– OracleIn-MemoryCacheOption



VoraussetzungenfürdieIn-MemoryCacheNutzung

● Hauptspeicher● NochmehrHauptspeicher● NochvielmehrHauptspeicher

(aktuelleServerkönnenmehrereTBHauptspeicherenthalten)– WirhabenaberauchbeieinemPOCaufeinemServermit16GBMemorygezeigt,

dassdasausreichenkann,soferndiebenötigtenTabelleninsMemorypassen.● Größenordnung:25-50%derSegmentSizederTabellen/Partitionendieman

imIn-MemoryCachehabenmöchte● UndimFallevonVirtualisierung:esmussdieHWVirtualisierungderCPU

eingeschaltetsein(beiIntelVT-x,VT-d)



SGABereichfürIn-MemoryCache

● InderSGAwirdeinzusätzlicherBereich–derIn-MemoryColumnStorebereitgestellt

● SobaldaufdenTabellendefiniertist,dasssieIn-Memorynutzensollen,landendieseauchimColumnStore

● InnerhalbdesColumnStoresgibtes1MBgroßeColumnUnitsindenendieDatenabgelegtwerden.

● Verwaltungsstruktur(Transaktionsbereich)umfasstca.15%desColumnStores



WieistderColumnStoreaufgebaut

● JedeColumnUnitgehörtzueinerbestimmtenTabelle(eineTabellebelegtmehrere/vieleColumnUnits)undenthältdieDatenvonaufeinanderfolgendenDaten(Rows)

● DieDatenwerdenabernicht„zeilenweise“(Row)sondern„spaltenweise“(Column)abgelegt– dabeiwerdendiesenachderSpaltesortiertundproCUundSpaltegibteseinenMAXundMINInformationà hilftbeiQueries,CUsauszulassen,diekeinerelevantenDatenenthalten.



DMLundColumnStore

● DMLmussdieDateninbeidenBereichen(Row,Column)pflegen.● ImRow Bereichändertsichnichts● FürdenColumnBereichwirdetwas„geschummelt“

– WährenddesDMLswerdendieentsprechendenDatenimColumnStoreauf„Stale“gesetzt.– DieÄnderungsinformationwirdim

TXJournal „zwischengespeichert“– BeiQueries imColumnStoreerkenntder

OptimizerdenZustand„Stale“undgreiftentsprechendaufdasTXJournalund/oderdenBuffer Cachezu

– Besonders„heiße“Tabellensinddahernichtoptimal



NeueHintergrundprozessefürIn-Memory

● IMCO InMemoryCoordinator Prozess● SMCO SpaceManagementCoordinator Prozess

verteiltdieArbeitaufdieWnnnAuchfürFlashbackDataArchive,TemporalHistory,…

● Wnnn WorkerProzessesInMemoryPopulate ServerProzessesbefüllen/aktualisierendenColumnStore

Neu



WasistimColumnStorebesondersschnell?

● Zugriffeaufeinige(wenige)SpaltenvonsehrgroßenTabellen– VorallemmitSUM,AVG,…undGROUPBY

● MitEinschränkungenmit=,>,<undIN● DataWarehouseAbfrage(FACT,DIMENSIONTabellen)● DortwoinQueries „Full TableScan“,„Full IndexScan“,„FastFull IndexScan“

und„IndexRangeScan“übergroßeRangesvorkommen.● Wowirdesgenerellschneller:

Dortwoman„unnötige“Indexeseliminierenkann!



In-MemoryColumnStoreversusandereStrukturen

DieFrageist:WaskannmirderIn-MemoryColumnStoreersparenundwomitkooperiertersehrgut?Struktur Zusammenarbeit

PK,UK,FKIDX Werdenfürdierelationale Verarbeitungbenötigt,sinddemColumnStoresoweitegal. belassen

IDXfürQuery KannmanindenmeistenFällenlöschen (=DMLwirdschneller),derColumnStoreistmeistschneller weg

Bitmap Index Hiergiltdasgleichewiefür„IDXfürQuery“ weg

MView MView +ColumnStore=genialePerformanceMankanndenDetailgradimMView sogarerhöhenunddiePerformancepasstimmernoch(Beispiel:TagesdatenstattMonatsdaten,dadurchsindauchdetailliertereAnalysenperformantmöglich!)

optimal

Partitioning Speziell,wenndamitaktuelle vonnichtaktuellenDatensepariertwerdenkönnen,spartColumnStoreeineMengePlatzà IdealeKombination

optimal

RAC VollerRAC Support– esbenötigtnureinenentsprechendschnellenInterconnect(>=10GBit),sonstwirdIn-MemoryimRACausgebremst.

Vorsicht



● Faster Joins● Join Groups● Expressions● JSONSupport● Heat Map Integration● Active DataGuard support● OracleHardwareIntegration


Oracle12cRelease2InMemoryNeuheiten


Faster Join


● InderQuerykommtnurSTORES.TYPE='OUTLET'sowiederJoinselbstvor,daskannOracleentsprechendumsetzen...


Join Groups


● DurchJoin GroupswerdendieMetadatenderJoin Spalte(n)indergleichenStrukturabgelegt.DieDatenindenIMCUswerdenentsprechendabgelegt.– ReduziertdenDecompress-

AufwandbeimDatascan– SchnelleresFindender

Daten(HASHING)beimJoinCREATE INMEMORY JOIN GROUP

vehicles_sales_jg(VEHICLES (NAME),SALES (NAME))


In-MemoryExpressions


● Expressions wurdenfürnormaleTabellenschoninOracle12cR1eingeführt.

● In12cR2funktioniertdasjetztauchfürIn-MemoryCREATE TABLE SALES (.... NETTO_PREIS NUMNER, STEUER NUMNER,....

BRUTTO_PREIS AS (NETTO_PREIS * STEUER));

SELECT ...FROM SALESWHERE BRUTTO_PREIS = 1200;


JSON


● JSONistjetztTeilderIn-MemoryFunktionalität.● DadurchsollenJSONQueries biszu60malschnellerwerden.


In-MemoryundHeat Map


● TabelleSALESistInterval partitioniert(monatlich)● FürIn-MemorystehtnichtgenugSpeicherzurVerfügungum

mehrals2-3MonateOnlinezuhalten.● DieFrageistnur:welche?

HEAT_MAP = ON

Automatisch durch Oracle:INMEMORY_ADO_ENABLED = TRUE

Manuell durch ILM Policy:alter table sales ilm add policyno inmemory after 31 days of

no access | of creation | of no modification;


Offload In-Memoryto Active DataGuard


● In-MemorykannnunaufderActive DataGuard Instanzlaufen– Redo (DML&DDL)

wurdeumIn-MemoryInfoserweitert

– Syntax:INMEMORYDISTRIBUTEFORSERVICE


In-MemoryundHardware


● Exadata– In-MemoryinFlash

§ In-MemoryIMCUskönnenimStorageFlashgespeichertwerden,dadurchkeine„Populierungszeiten“nacheinemRestart derInstanzen.

● SPARC– In-MemoryinSilicion

§ SchnellereJoins§ InHardwareDecompress


WasistderVorteilvonIn-MemorygegenüberanderenLösungen? (Marketingeinschaltung?!)● InMemoryeinschalten,TabellenIn-Memoryaktivieren,fertig● Applikationsanpassungen: keine(außerdrop Index)● Funktionseinschränkungen:keine,alleFeaturessindunterstützt● Migrationsaufwand:keiner● ÄnderungenBackup/Recovery:keine

Nein,dasistkeinMarketing!WirhabenPOCsteilweiseinwenigenStundenabgeschlossen!



● In-MemoryKonfigurieren● Tabellen,MViews aufIn-Memoryumstellen● In-MemoryOption– möglichesFeintuning● Wokannmannachsehen(Session,InstanceEbene)● Execution PlanmitIn-MemoryVerarbeitung

EinführungundUmsetzungvonIn-MemoryCacheOption



In-MemoryKonfigurieren

● Esistwirklicheinfach:alter system set compatible=12.1.0.0.0 scope=spfile;alter system set INMEMORY_SIZE=200G scope=spfile;shutdown immediate;startup;



In-MemoryKonfigurieren(12cR1)EsgibtaberaucheinigeweitereParameter

Parameter Zweck

INMEMORY_SIZE Größe desColumnStores+TXJournals

INMEMORY_FORCE DEFAULT |OFF…deaktivierenvonINMEMORY

INMEMORY_MAX_POPULATE_SERVERS

AnzahlderHintergrundprozesse,dieden ColumnStorebefüllen/aktualisieren.Default=CORE/2

INMEMORY_QUERY ENABLE |DISABLE(Sess +Instance)

INMEMORY_TRICKLE_REPOPULATE_SERVERS_PERCENT

0..1 ..50wievielProzentderPOPULATESERVERSdürfenfüraktualisierengenutztwerden.

INMEMORY_CLAUSE_DEFAULT Default=keineINMEMORY |NOINMEMORYNOMEMCOMPRESS|MEMCOMPRESSFOR{DML|QUERY [HIGH|LOW ]|CAPACITY[LOW|HIGH]PRIORITY{LOW|MEDIUM|HIGH|CRITICAL|NONE}RAConly:DISTRIBUTE[AUTO|BYROWIDRANGE|BYPARTITION|BYSUBPARTITION]NODUPLICATE|DUPLICATE|ALL

OPTIMIZER_INMEMORY_AWARE TRUE |FALSE



Tabellen,MViews aufIn-Memoryumstellen

● NeuesObjekt(Tabelle,MView):create table new(x number) INMEMORY;

● BestehendesObjektändern:alter table new INMEMORY;

● MitallenOptionenaus„INMEMORY_CLAUSE_DEFAULT“– Compression (Deduplizierung – abwobrauchtmandieCompression Option?)– Priority – wiewichtigistdasObjekt,wieschnellsollesnacheinemRestart der

Instanzgeladenwerden(CRITICAL=sofortnachopen)– Distribute (RAC)- wiesollendieDatenindenColumnStoresverteiltwerden– Duplicate (RAC)– nurineineInstanz,inzweioderinalle.



Tabellen,MViews aufIn-MemoryumstellenundMemorysparen● DurchAngabe,welcheSpaltennichtindenColumnStoresollen

create table emp (first_name varchar2(16), last_name varchar2(16), CV varchar2(4000),…)INMEMORY NO INMEMORY (CV);

● BeipartitioniertenTabellen– INMEMORYproPartitioneinstellbar● MEMCOMPRESSEinstellunganpassen



InMemoryCompress

● DerPlatzverbrauchhängtnatürlichdavonab,wieviele„distinctvalues“esgibtundwelcheDatentypenessind.

● BeispieleinesSAPPOCs

Objekt DISK FORQUERYLOW

FORQUERYHIGH

Remark

RSRWBSTORE 17.3GB 14.4GB 14.2GB 4Spalten+BLOB

/BIC/ECOPA_01 6.9G 1.7G 1.2G VieleSpalten,meistNumber, Row ca.300Bytes

/BIC/EEG_BCO_12 1.8G 0.97G 0.65G VieleSpalten,meistNumber,Row ca. 160Bytes



Wokannmannachsehen?InMemoryV$ViewsV$VIEW Inhalt

V$IM_SEGMENTS InformationenüberdieSegmente imColumnStoreinkl.denINMEMORYStorageEinstellungen

V$IM_SEGMENTS_DETAIL Etwasmehr DetailinfozuV$IM_SEGMENTS

V$IM_USER_SEGMENTS WieV$IM_SEGMENTS,abernurfür dieeigenenTabellen

V$IM_COLUMN_LEVEL InfosimFalle einerAbweichungderSpalteneinstellungvonderdesSegments

V$IM_HEADER DetailinfoszudenIMCUs(welches Segment,wievieleDatensätze,wievielPlatz,…)

V$IM_COL_CU DetailinfoszujederSpalteimIMCU (Platzbedarf,MinVal,MaxVal,…)

V$IM_SMU_HEAD TXJournal– Header fürjedeIMCU

V$IM_SMU_CHUNK TXJournal– Detail fürjedeIMCU

V$IM_TBS_EXT_MAP WelcheDatenblöckewerdeninwelcherIMCUangelegt

V$IM_SEG_EXT_MAP InterneInformationenzudenIMCUinkl.NUMA (CPU– MemoryZuordnung)



Wokannmannachsehen?

● DBA_TABLES …inMemoryStorageInfos● V$SESSTAT/V$MYSTAT

select sn.name, ss.valuefrom v$mystat ss, v$statname snwhere ss.statistic#=sn.statistic# and sn.name like 'IM%' /* oder 'IM scan%' */;

● V$SYSSTAT● V$SEGMENT_STATISTICS

select owner, object_name, subobject_name, statistic_name, value from v$segment_statisticswhere statistic_name like 'IM%' and (owner, object_name, nvl(subobject_name,' ')) in

(select owner, segment_name, nvl(partition_name,' ') from v$im_segments);



HilfreicheQueries fürIn-Memory(1)

● In-MemoryDefinitionen aufTabellenselect table_name, inmemory, inmemory_distribute,

inmemory_compression, inmemory_priority, inmemory_distribute, inmemory_duplicate

from dba_tableswhere inmemory='ENABLED';

● Segmente aktuell schon im ColumnStoreselect * from v$im_segments;

select segment_name, partition_name, POPULATE_STATUS, inmemory_size,bytes, bytes_not_populated

from v$im_segments;



HilfreicheQueries fürIn-Memory(2)

● WelchevondenIn-MemorydefiniertenTabellensindschonIn-Memory?

select t.owner, table_name, t.inmemory, t.inmemory_distribute,t.inmemory_compression, t.inmemory_priority, t.inmemory_duplicate, i.populate_status, i.inmemory_size,i.bytes as bytes_on_disk,trunc(100/i.bytes*i.inmemory_size,2) as compress_pct

from dba_tables t, v$im_segments i where table_name=segment_name(+)

and t.inmemory='ENABLED';

● GrößeaufDiskversusIn-MemoryColumnStoreselect owner, segment_name, partition_name,

bytes/1024/1024/1024 GB_DISK,inmemory_size/1024/1024/1024 GB_INMEMORY,100/bytes*inmemory_size as COMP_PCT

from v$IM_SEGMENTS;



DBMS_COMPRESSION. GET_COMPRESSION_RATIO

PROCEDURE GET_COMPRESSION_RATIOArgument Name Type In/Out Default?------------------------------ ----------------------- ------ --------SCRATCHTBSNAME VARCHAR2 INOWNNAME VARCHAR2 INOBJNAME VARCHAR2 INSUBOBJNAME VARCHAR2 INCOMPTYPE NUMBER INBLKCNT_CMP BINARY_INTEGER OUTBLKCNT_UNCMP BINARY_INTEGER OUTROW_CMP BINARY_INTEGER OUTROW_UNCMP BINARY_INTEGER OUTCMP_RATIO NUMBER OUTCOMPTYPE_STR VARCHAR2 OUTSUBSET_NUMROWS NUMBER IN DEFAULTOBJTYPE BINARY_INTEGER IN DEFAULT



DBMS_COMPRESSION.GET_COMPRESSION_RATIOBeispielaufrufset serverout on

declareblk_cmp binary_integer;blk_uncmp binary_integer;row_cmp binary_integer;row_uncmp binary_integer;cmp_ratio number;comptype varchar2(80);begindbms_compression.get_compression_ratio('PSAPEBI','SAPEBI','RSRWBSTORE',null,

DBMS_COMPRESSION.COMP_INMEMORY_NOCOMPRESS,blk_cmp, blk_uncmp, row_cmp,row_uncmp, cmp_ratio, comptype, 100000,1);

DBMS_OUTPUT.PUT_LINE('Block Cnt NONCOMP =' || blk_uncmp);DBMS_OUTPUT.PUT_LINE('Block Cnt COMP =' || blk_cmp);DBMS_OUTPUT.PUT_LINE('Row Cnt NONCOMP =' || row_uncmp);DBMS_OUTPUT.PUT_LINE('Row Cnt COMP =' || row_cmp);DBMS_OUTPUT.PUT_LINE('COMP Ratio =' || cmp_ratio);DBMS_OUTPUT.PUT_LINE('COMP Type =' || comptype);end;/



Execution PlänemitIn-Memory

ZugriffaufIn-Memorymittels„TABLEACCESSINMEMORYFULL“

SupportfürpartitionierteTabellen

JOINFILERCREATE&USE=BLOOMFiler

Join istbeiIn-MemoryimmereinHASHJoin



Execution PlanIn-MemoryundnormaleTabellen

HiereinFTSaufeinenormaleTabelleIndexzugriffesindnatürlichauchmöglich



● Beispiele,woIn-Memorygutodernichtsogutabschneidet● RealWorldDataWarehouseApplikationErgebnisse● TestsmitSAPHRundSAPBI

RealWorldBeispieleundErgebnisse



BeispielewoIn-Memorysehrgutabschneidet

● WennimExecution Planfolgendeszufindenist:– Full TableScanaufTabellen>1M

select count(*) from (select /*+ FULL(s) */ * from SAPEBI."/BIC/EEG_BCO_12" s ); -- Disk: 11G, In-Memory: 3.8G, ca. 60 Mio Records-- nur Buffer Cache: ca. 3 Sekunden mit In-Memory: 660ms, das ist ein Faktor 5

In-Memory ist nicht nur schneller, sondern benötigt in diesem Beispiel nur 1/3 desHauptspeichers im Vergleich zu Buffer Cache, zusätzlich kann man sich Indexes sparen!

– „FastFull IndexScanaufIndex“bzw.„Full IndexScanaufIndex“>1M,sofernzusätzlichaufdieTabellezugegriffenwird

– Große„IndexRangeScans“oder„IndexSkipScans“>1M,sofernzusätzlichaufdieTabellezugegriffenwird

– KlassischeDataWarehouseQuery(FACT,DIMENSION,GROUPBYs)– AggregationenaufeinzelneSpalten

select /*+ FULL(s) */ sum(KEY_EG_BCO_12P), sum(KEY_EG_BCO_127) from SAPEBI."/BIC/EEG_BCO_12" s;-- nur Buffer Cache: ca. 7 Sekunden mit In-Memory: 70ms, das ist ein Faktor 100!



BeispielewoIn-Memorynichtsogutabschneidet

● SehrkomplexeQueries,beidenenvieleDatenaufGrundvonWHEREaussortiertwerden,In-MemoryaberalleIMCUslesenmuss– SieheSAPBI,woeineQuerymitIn-Memorylangsamerwaralsohne.

● Queries,dievieleSpaltenverarbeiten/ausgeben● Queries,dieaktuellim(Milli)sekundenbereich laufen



BeispielewoIn-Memorynichtverwendetwird

● Queries mitPK,UK=● Queries,diekomplettüberIndexabgebildetwerdenkönnen



RealWorldDataWarehouseApplikationErgebnissePOCaufeinemRechnermit16GBMemory!

● DWHQueryeinesKundenselect PMATCH_MODEL_NAME, sum(price), avg(price), max(price), min(price)from offer_fact_client1 f, date_dim d, product_dim p

where f.extract_date_fk = d.dimension_keyand f.product_dim_fk = p.dimension_keyand d.day between '2014-05-01' and '2014-06-01'and p.PMATCH_MODEL_BRAND_NAME = 'IBM'

group by PMATCH_MODEL_NAMEorder by PMATCH_MODEL_NAME;

Buffer Cache 1GB: 80 Sekunden ## Alle Tabelle+Idx brauchen >3GB auf DiskInMemory 1GB: 0.33 Sekunden ## Es passt alles in 1GB im MemoryFaktor: 240 ... Aber ein unfairer Vergleich, da Buffer Cache zu klein war.

● WeitereErgebnisse– DurchschnittlicheQueries wurden(allesimMemory)umgeringeFaktorenschneller,aber

§ RefreshumFaktorenschnellerdakeineBITMAPIDXundvielwenigerIndexes§ JedeAbfrageistschnell,nichtnurdiefürdiegetuned wurde§ Column Storeoftdeutlichkleineralsvorhervermutet



POCTestsmitSAPHR

● SAPHR– DerSAPApplikationServerholtsichmeistnurEinzelrows vonder

Datenbank(QueryLaufzeit<1ms)– BeidengetestetenVerarbeitungen(LaufzeitimBereichvon5-15

Minuten)wardieDatenbankimSchnittdeutlichunter5%derVerarbeitungà selbstwennmanhiereinenFaktor10bekommenwürde,sinddasnurwenige%derLaufzeit

● SolangedieVerarbeitungaußerhalbderDatenbankdieZeitverbraucht,kannIn-Memorynichthelfen(undauchkeinSAPHANA).



POCTestmitSAPBI

● Wirhaben3TOPQueries vomKundeneingehendgetestet● BeieinerQueryhatIn-Memorydeutlichgeholfen

– Marketingwürdesagen:von2746Sekundenauf100SekundenQuerygleichnachStartderInstanz(20GBBC)versusIn-Memory

– Kundewürdesagen:vonca.1500Sekundenaufca 100SekundenQuerywenndieDatenbankwarmgelaufenist(20GBBC)versusIn-Memory

– Wirsagen:vonca.380Sekundenaufca.100SekundenDatenkomplettimBuffer Cache(256GBBC)versusIn-Memory

● BeidenbeidenanderenQueries wardasErgebnisFaktor0,5undFaktor2(bei256BCversusIn-Memory,mitzukleinemBuffer CacheimmernochzweistelligeFaktoren!)– Aber:wirkonntendieBitmapIndexesohnePerformanceunterschieddroppen,

dashatohneIn-MemoryzuFaktor>50längerenLaufzeitengeführt.DOAGWebinarOracle12cInMemory


TestmitSAPBI,aberselbstgeschriebenQueries

select count(*) from SAPEBI."RSRWBSTORE";Fast Full Scan auf PK

select count(distinct CLUSTR) from SAPEBI."RSRWBSTORE";Full Table Scan

select count(*) from (select WORKBOOKID, count(*), count(distinct OBJVERS) from SAPEBI."RSRWBSTORE" group by WORKBOOKID);

Fast Full Scan auf PK

select count(*) from (select WORKBOOKID, count(*), count(distinct OBJVERS) from SAPEBI."RSRWBSTORE" where WORKBOOKID like 'A%' group by WORKBOOKID);

Index Range Scan auf PK

select count(*) from (select WORKBOOKID, count(*), count(distinct OBJVERS) from SAPEBI."RSRWBSTORE" where WORKBOOKID like '%A' group by WORKBOOKID);

Fast Full Scan auf PK

select count(*) from (select WORKBOOKID, count(distinct CLUSTR) from SAPEBI."RSRWBSTORE" where WORKBOOKID like '%A%' group by WORKBOOKID);

Full Table Scan



TestmitSAPBI,aberselbstgeschriebenQueriesErgebnisse

Query BCzuklein BCgroßgenug

In-MemoryIndexbehalten

In-MemoryIndexgedropped

Q1:count(*) 200ms, FFS ident ident 62ms

Q2:count(distinct CLUSTR) >40sek,FTS ca 3Sek 31ms,InMemory FTS 31ms

Q3:WORKBOOKID,count(*) 650ms, FFS+group ident ident 470ms

Q4:WORKBOOKIDlike'A%' 125ms,IRS+group ident ident 62ms

Q5:WORKBOOKIDlike'%A' 560ms,FFS+group ident ident 787ms

Q6:WORKBOOKIDlike'%A%' >40Sek,FTS+group ca 3Sek 110ms,InMemory FTS 100ms



● WassagenOracleundSAPüberdiejeweiligeLösungdesMitbewerbers?

● ZertifizierungfürOracleIn-MemoryfürSAPHANA

VergleichSAPHANAversusOracleIn-MemoryDatabaseCacheOption



WassagenOracleundSAPüberdiejeweiligeLösungdesMitbewerbers?● Oracle:In-MemoryVersusSAPHANAhttp://www.oracle.com/technetwork/database/options/dbim-vs-sap-hana-2215625.pdf

● SAP:In-MemoryversusSAPHANA– the FACTshttp://www.saphana.com/community/blogs/blog/2014/06/11/oracle-in-memory-columnar-cache-vs-sap-hana-platform-the-facts

● BeidesfindenSieineinemArtikelaufunsererHomepagehttp://www.dbmasters.at/db/masters/artikel/oracle-12c-in-memory-database-versus-sap-hana-ein-vergleich



WassagenOracleundSAPüberdiejeweiligeLösungdesMitbewerbers?EinAuszugBusinessNeed OracleIn-Memory OraclezuSAPHANA SAPs„Facts“(=Antwort) DBMastersund

Kundenfeedback

Transparent fürdieApplikation

100%alleApplikationenlaufensofort ohneCodezuändern.

Muss aufHANAangepasstwerden(teilweiseneuschreiben!)

Viele 3rdPartyAppsundBIToolslaufengegenHANA.

FeedbackvonHANAKunden:massiveAnpassungen,vielSAPTeilelaufen(nochimmer)nicht.

Keine spezielleHardwarenötig

LäuftaufjederHardware

Brauchtspeziellzertifizierte- sehrteure-Hardware

Wir supporten IntelX86,Power,Vmware (abernurspeziellzertifizierteLösungen!)

Esgibteinige„PerformanceFeatures“dieOracleHWvoraussetzen,abersonstsindwirOracles Meinung

AnforderungenanDBA,Developer

KeineneuenAPIs,lediglicheinigewenigeEinstellungenfürDBAs

UmHANAoptimalzunutzenmussmanvielneueslernenundumsetzen

HANA kannmanschnelllernen– esistjaeineANSIstandard Datenbank.

Kundenfeedback: VielAufwand(undnochvieleBUGs)

HoheVerfügbarkeit

Die OracleDatenbankistsehrstabilundRAC,DataGuard,..sindverfügbar

KeinHA,restart dauertsehrlange,keintransparentes ausfallenvonKnotenmöglich,…

HANAkannHA(SystemReplikation,StorageReplikation,…)aberkeinWortzu„Restart dauertsehrlange“

Kundenfeedback:SAPHANAist(noch)nichtstabil undHAistimVergleichzuOracleaufwändigundkompliziert.



ZertifizierungfürOracleIn-MemoryfürSAP

● SAPlässtsichoftsehrvielZeitum„neueTechnologien“zuzertifizieren(sieheExadata,…)– imMomentgibtesvonSAPeine„SAPonOracleDatabase12cRoadmap“,indersteht,dassmitSAP7.XXderSupportfürOracle12.1.0.2kommenwird– keinWortzu„In-Memory“indiesemZusammenhang.

● EsgibtvonSeitender„OracleSAPKunden“einePetitionanSAP,dassdieOracleIn-MemoryOptionmöglichstschnellzertifiziertwird.

● BeiInteressediesePetitionzuunterschreiben,bittemitOracleÖsterreichKontaktaufnehmen.



Zusammenfassung(1)InMemoryistSUPER● ImplementierungistinwenigenMinutenerledigt● Queries teilweiseumhoheFaktorenschneller

– SAPBIQueries biszuFaktor14– UnsereTestQueries biszuFaktor1300– DWHQueries biszuFaktoren>50

● RichtigesIndexing istkeinThemamehr● Durchdroppen von„query only Indexes“dasDML(oderETL)schnellermacht● Durchdroppen von„BitmapIndexes“beimDatenladennichtmehrstören● Geradewennwirklich„Enduser“selbstQueryabsetzenkönnen,kommtdas

ErgebnisineinersinnvollenZeitzurück!



Zusammenfassung(2)InMemorybringtwenig/nichts● BeiOLTP,wenndieQueries (fast)alleinwenigenms fertigsind

– Queries mitPK=Value– Queries mitwenigenRows ErgebnisüberPK/UK/FKIndex

● BeischonoptimiertenDWHStrukturen,wennIn-Memorynichtvernünftigfilternkann(keineIMCUsauslassenkann)– EinigeSAPBIQueries imBereichvonFaktor0.5(doppeltsolange)bis2

● WenndieZeitaußerhalbderDatenbankliegenbleibt(sieheSAPHR)



Zusammenfassung(3)UnsereMeinungzuIn-Memory● ManndarfnichtÄpfelmitBirnenvergleichen!

– WennmandieDatenvomaktuellenSystem(dasseinezukleinenBuffer Cachehat)miteinemneuenSystemmitIn-Memoryvergleicht,kannIn-Memorynurgewinnen.

– DamitmansiehtobundwievielIn-Memorybringt,mussmanesmitdenLaufzeitenbeiausreichendgroßemBuffer Cachevergleichen

● EskommtaufdieAnwendungan– OLTP wenigsinnvoll,möglicherweisepunktuelleinsetzbar

großeTabellenmitvielenIndexesumdieIndexeszueliminieren– DWH/DSS HierhilftIn-Memorywirklich,oftwirdesschneller,

aberfallsnicht,istmandas„Indexing Thema“los!● WirempfehleneinePOCbevormanaufIn-Memoryumsteigt.



DBMastersEvent2017am14.März2017inWienAnmeldungviahttps://www.dbmasters.at


● Vorträge:– Oracle´s selfmanaging DatabaseVersprechen– OracleHighPerformanceDatenbankImplementierung– EUDatenschutzgrundverordnungfürDBAsundEntwickler– Row PatternMatching – DatenanalyseaufneuemLevel– OracleSystemStatistics undI/OCalibration– OracleRessourceManager– einmassivunterschätztesFeature– ADRCI,Log- undTracefile Management– Oracle12cR2undpNFS

● Teaser:https://youtu.be/PDxyqLfOAEs


Q&A


Oracle Datenbank 12c In-Memory Cache Option Architektur ... · Datenbanken sind unsere Welt Oracle...

Documents

Transcript of Oracle Datenbank 12c In-Memory Cache Option Architektur ... · Datenbanken sind unsere Welt Oracle...