Amit mindig is tudni akartál a Real Application Testing-ről. Földi Tamás Starschema Kft.

Átírás

1 Amit mindig is tudni akartál a Real Application Testing-ről Földi Tamás Starschema Kft.

2 Környezet Adattárház Oracle 9i, HPUX 13ezer tábla ~1400 betöltő folyamat ~8000 töltési lépés (mapping) Riportok BusinessObjects standard, 860 ad-hoc riport 1200 felhasználó (átlag konkurens)

3 BI Upgrade: projekt célok Üzemeltethetőség Nem támogatott verziók cseréje Üzleti területek támogatása Dashboard-ok és riportok korszerűsítése Teljesítmény Iparági best practice -ek alkalmazása Költségcsökkentés Sztenderd, konszolidált megoldások

4 BI Upgrade: projekt eszközök Oracle 11g BusinessObject XI 3.1 PL/SAP Connector Elemzői támogatás (OLAP) Instance összevonás Automatic Storage Management SQL Plan Management SQL Tuning, Parallel Query Áttérés az XI 13.1 verzióra Riportok migrálása WebI formátumra LiveOffice bevezetés Metadata Manager bevezetés Hatékony SAP interfész kialakítása Új érkeztető keretrendszer Supply Chain Commercial Finance Sales

5 Oracle akcióterv Konszolidáció Stage és DWH instance-k összevonása Kevesebb licensz, jobb teljesítmény Upgrade 9i-ről 11g-re SQL tuning (orainit, PX, SPM) Tábla tömörítés Tároló kezelés Táblaterek átrendezése (ASSM) Automatic Storage Management (ASM) Nem használt struktúrák törlése (audit alapján)

6 Oracle projektág kockázatok Nem várt hibák Szoftverhibák, inkompatibilitás Adatanomáliák Nem teljesülnek a célok Elmarad a teljesítmény a meghatározott szintektől

7

8

9

10 Real Application Testing Valós terhelési adatok Végrehajtott SQL-ek Időzítések Hálózati terhelés Kiértékelés Riportok SQL tuning set-ek

11 Tesztelési folyamat

12

13 RAT előkészületek Mit akarunk tesztelni Instance összevonás Táblatér és tároló változások Optimális paraméterek Patch-ek Oracle one-off patch Oracle one-off patch Tárhely Próba felvételek Nem támogatott API töltések

14 Éles környezetek Patchek installálása Időzítés RAT rendszer Új környezet telepítése Tuning setek Riportok Teljes backup Teljes backup Felvétel indítása Felvételek feldolgozása Lejátszás Visszaállítás

15 Felvétel Rec fájlok Több gigabájtos felvételek Lassulás ARCHIVE mód direct path kerülése Kb. 10%-os lassulás Érdekes időszak kiválasztása 24 órás felvétel Azonos időpontban indítva

16

17 Lejátszás előkészületek Konzisztens állapot Minden adat az élessel megegyezik Az óra visszaállítva a felvétel időpontjára Backup RMAN backup vagy Snapshot Standby Feldolgozás Egy feldolgozás, több lejátszás Szűrés Nem használt sémák (EM, AWR)

18 Konszolidáció A RAT hivatalosan nem támogatja több adatbázis összevont visszajátszását. Azonban van működő kerülőút. Több instance egyidejű lejátszása: A forrásokat azonos időpontban kell indítani Egy könyvtárba kell másolni a REC fájlokat, de csak az egyik adatbázis meta-adatait kell mellérakni Csak időzítés alapú lejátszás lehetséges, SCN alapú szinkronizálás nélkül

19 Lejátszás Többszöri iteráció Paraméterek, környezet beállítása Workload lejátszás Visszaállás a kiindulási állapotra AWR baseline-ok készítése Replay kliensek Négy kliens (2 ETL, 2 BI) Client Calibration Advisor Szinkronizáció megválasztása Több instance-nél kizárólag időzítés alapú

20 DB Replay Adat eltérés Töltési hibák Teljesítmény különbségek (ADDM, ASH, AWR) SQL Performance Analyzer Teljesítmények összehasonlítása (CPU, IO, stb.) Az SPA Riportok SQL szintig lefúrhatóak (jobban, rosszabbul teljesítő SQL-ek) Rosszabb SQL-ek tunningja SQL Tuning Advisor Riportok

21 Eredmények Konszolidáció A két adatbázis összevonása esetén is kielégítő a teljesítmény Csökkenti a licensz és üzemeltetési költségeket Adatintegritás Nincs adatszintű eltérés Optimalizálás Lassabban futó lekérdezések izolálása 10-15%-os teljesítmény növekedés

22 RAT vs. Saját célalkalmazás Erőforrás ráfordítás (Napok) Fejlesztés / RAT Installálás Szimulációs környezet kialakítása Workload generálás Run Test 10 Kiértékelés: hatástanulmány és tuning set készítése DB Replay Saját megoldás DB Replay: 2 hét Teljes tesztelési időtartam Saját megoldás: 10 hét

23 Összefoglalás Könnyen kezelhető, egyszerű eszköz Valós tesztadatok szintetikus helyett Minden fontos lépésnél ajánlott mentést készíteni Több szerver konszolidációjához elengedhetetlen AWR-rel együtt hatékony igazán Oda kell figyelni a nem támogatott operációkra (direct path) Ki kell szűrni a nem használt sémákat Érdemes a PL/SQL interfészt használni az EM helyett

24 Köszönjük a figyelmet!

25 Felhasznált képek