A forrásrendszer optimalizálása – speciális
Oracle Row ID tábla felosztása
Az SAP kiadta az SAP Note #1043380 fájlt, amely egy szkriptet tartalmaz, amely a WHR-fájl WHERE záradékát SORazonosító értékké alakítja. Másik lehetőségként az SAPInst legújabb verziói automatikusan létrehoznak sorazonosító felosztott WHR-fájlokat, ha az SWPM az Oracle-hez van konfigurálva az Oracle R3load migrálására. Az SWPM által létrehozott STR- és WHR-fájlok függetlenek az operációs rendszer és az adatbázistól (ahogyan az operációs rendszer/adatbázis áttelepítési folyamatának minden aspektusa).
Az OSS-megjegyzés tartalmazza a "ROWID tábla felosztása NEM használható, ha a céladatbázis nem Oracle-adatbázis". Az R3load memóriaképfájlok technikailag függetlenek az adatbázistól és az operációs rendszerétől. Van azonban egy korlátozás, a csomagok importálás közbeni újraindítása nem lehetséges az SQL Serveren. Ebben a forgatókönyvben a teljes táblát el kell dobni, és a tábla összes csomagja újra kell indítani. Mindig ajánlott az R3load-feladatok leállítása egy adott felosztott táblához, TRUNCATE a táblázat, és indítsa újra a teljes importálási folyamatot, ha egy felosztott R3load megszakad. Ennek az az oka, hogy az R3load-ba beépített helyreállítási folyamat egyetlen sorról sorra történő DELETE utasításokkal távolítja el a megszakított R3load-folyamat által betöltött rekordokat. Ez lassú, és gyakran blokkolási/zárolási helyzeteket okoz az adatbázisban. A tapasztalatok azt mutatják, hogy az adott tábla importálása az elejétől gyorsabb, ezért az SAP Megjegyzés # 1043380 nem korlátozás.
A SORazonosító hátránya, hogy az állásidő során el kell végezni a felosztások kiszámítását – lásd : SAP Note #1043380.
A forrásadatbázis több "klónjának" létrehozása és párhuzamos exportálása
Az exportálási teljesítmény növelésének egyik módja, ha ugyanazon adatbázis több példányából exportál. Ha a mögöttes infrastruktúra , beleértve a kiszolgálókat, a hálózatot és a tárolást skálázható, akkor ez a megközelítés általában lineárisan skálázható. Ugyanabból az adatbázisból két példányból való exportálás kétszer olyan gyors, négy példány négyszer olyan gyors. A Migration Monitor úgy van konfigurálva, hogy az adatbázis minden egyes "klónjából" kiválasztott számú táblát exportáljon. Az alábbi esetben az exportálási számítási feladat körülbelül 25%-ot oszt el a négy adatbázis-kiszolgáló mindegyikén.
- DB server 1 & export server 1 – a legnagyobb 1-4 táblához dedikált (attól függően, hogy az adateloszlás mennyire ferde a forrásadatbázison)
- DB server 2 & export server 2 – táblaeloszlással rendelkező táblákhoz dedikált
- DB server 3 & export server 3 – táblaeloszlással rendelkező táblákhoz dedikált
- DB server 4 & export server 4 – az összes fennmaradó tábla
Ügyelni kell arra, hogy az adatbázisok pontosan szinkronizálva legyenek, különben adatvesztés vagy adatelkonzisztenciák fordulhatnak elő. Ha a megadott lépéseket pontosan követik, az adatintegritás megmarad.
A technika egyszerű és olcsó a szabványos, hagyományos Intel hardverekkel, de a saját fejlesztésű UNIX hardvert futtató ügyfelek számára is lehetséges. A jelentős hardvererőforrások az operációs rendszer/adatbázis migrálási projektje felé ingyenesek, amikor a tesztkörnyezet, a fejlesztés, a QAS, a betanítás és a DR rendszerek már átkerültek az Azure-ba. Nincs szigorú követelmény, hogy a "klón" kiszolgálók azonos hardvererőforrásokkal rendelkezzenek. A megfelelő processzor-, RAM-, lemez- és hálózati teljesítmény mellett az egyes klónok hozzáadása növeli a teljesítményt.
Ha további exportálási teljesítményre van szükség, nyisson meg egy SAP-incidenst a BC-DB-MSS-ben az exportteljesítmény növelésének további lépéseihez (csak speciális tanácsadók esetén).
A több párhuzamos exportálás implementálásának lépései a következők:
- Biztonsági másolatot készít az elsődleges adatbázisról, és állítsa vissza az "n" számú kiszolgálóra (ahol n = klónok száma). Ebben a példában feltételezzük, hogy n = 3 kiszolgáló, amely összesen négy DB-kiszolgálót hoz létre.
- Biztonsági mentés visszaállítása három kiszolgálóra.
- Hozzon létre naplószállítást az elsődleges forrásadatbázis-kiszolgálóról három cél "klón" kiszolgálóra.
- Több napig monitorozza a naplószállítást, és győződjön meg arról, hogy a naplószállítás megbízhatóan működik.
- Az állásidő kezdetén állítsa le az összes SAP-alkalmazáskiszolgálót a PAS kivételével. Győződjön meg arról, hogy az összes kötegelt feldolgozás le van állítva, és az összes RFC-forgalom le van állítva.
- Az SM02 tranzakcióban írja be a "Checkpoint PAS Running" szöveget. Ez frissíti a TEMSG táblát.
- Állítsa le az elsődleges alkalmazáskiszolgálót. Az SAP most le van állítva. A forrásadatbázisban nem fordulhat elő több írási tevékenység. Győződjön meg arról, hogy egyetlen nem SAP-alkalmazás sem csatlakozik a forrásadatbázishoz (soha ne legyen, de ellenőrizze a nem SAP-munkameneteket a db szintjén).
- Futtassa ezt a lekérdezést az elsődleges ADATBÁZIS-kiszolgálón:
SELECT EMTEXT FROM [schema].TEMSG; - Futtassa a natív DBMS-szintű utasítást:
INSERT INTO [schema].TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss”(a pontos szintaxis a forrás DBMS-től függ. IN Standard kiadás RT az EMTEXT-be) - Az automatikus tranzakciónapló biztonsági mentésének leállítása. Futtasson manuálisan egy végleges tranzakciónapló biztonsági mentését az elsődleges DB-kiszolgálón. Győződjön meg arról, hogy a rendszer a napló biztonsági másolatát a klónkiszolgálókra másolja.
- Állítsa vissza a végleges tranzakciónapló biztonsági mentését mindhárom csomóponton.
- Állítsa helyre az adatbázist a 3 "klón" csomóponton.
- Futtassa a következő Standard kiadás LECT utasítást mind a négy csomóponton:
SELECT EMTEXT FROM [schema].TEMSG; - Rögzítse a Standard kiadás LECT utasítás képernyőeredményeit mind a négy DB-kiszolgálóhoz (az elsődleges és a három klónhoz). Ügyeljen arra, hogy gondosan adja meg az egyes gazdagépneveket, hogy bizonyítsa, hogy a klónozási adatbázis és az elsődleges azonos, és ugyanabból az időpontból származó adatokat tartalmazza.
- Indítsa el export_monitor.bat-t minden Intel R3load-exportálási kiszolgálón.
- Indítsa el a memóriaképfájl-másolást az Azure-folyamatba (AzCopy vagy Robocopy).
- Indítsa el import_monitor.bat-t az R3load Azure-beli virtuális gépeken.
Az alábbi ábra egy meglévő üzemi ADATBÁZIS-kiszolgáló naplójának "klónozott" adatbázisokba történő szállítását mutatja be. Minden DB-kiszolgáló egy vagy több Intel R3load-kiszolgálóval rendelkezik.
