Optimera källsystemet – avancerat
Tabelldelning för Oracle-rad-ID
SAP har släppt SAP Note #1043380, som innehåller ett skript som konverterar WHERE-satsen i en WHR-fil till ett RAD-ID-värde. Alternativt genererar de senaste versionerna av SAPInst automatiskt delade WHR-filer med RAD-ID om SWPM har konfigurerats för Oracle till Oracle R3load-migrering. STR- och WHR-filerna som genereras av SWPM är oberoende av operativsystem och databas (liksom alla aspekter av OS/DB-migreringsprocessen).
OSS-anteckningen innehåller instruktionen "ROWID-tabelldelning KAN INTE användas om måldatabasen är en icke-Oracle-databas". Tekniskt sett är R3load-dumpfilerna oberoende av databas och operativsystem. Det finns dock en begränsning, men det går inte att starta om ett paket under importen på SQL Server. I det här scenariot måste hela tabellen tas bort och alla paket för tabellen startas om. Vi rekommenderar alltid att du avbryter R3load-uppgifter för en specifik delad tabell, trunkerar tabellen och startar om hela importprocessen om en delad R3load avbryts. Anledningen till detta är att återställningsprocessen som är inbyggd i R3load innebär att ta bort instruktioner rad för rad för att ta bort de poster som läses in av R3load-processen som avbryts. Detta är långsamt och orsakar ofta blockerings-/låsningssituationer i databasen. Erfarenheten har visat att det går snabbare att starta importen av den här specifika tabellen från början, därför är den begränsning som nämns i SAP Note #1043380 inte en begränsning.
RAD-ID har en nackdel i den beräkningen av delningarna måste göras under stilleståndstid – se SAP Note #1043380.
Skapa flera "kloner" av källdatabasen och exportera parallellt
En metod för att öka exportprestandan är att exportera från flera kopior av samma databas. Om den underliggande infrastrukturen, inklusive servrar, nätverk och lagring, är skalbar tenderar den här metoden att vara linjärt skalbar. Att exportera från två kopior av samma databas är dubbelt så snabbt, fyra kopior är fyra gånger så snabbt. Migreringsövervakaren är konfigurerad att exportera på ett valfritt antal tabeller från varje "klon" av databasen. I följande fall distribueras exportarbetsbelastningen cirka 25 % på var och en av de fyra databasservrarna.
- DB-server 1 och exportserver 1 – dedikerad till de största 1–4 tabellerna (beroende på hur skev datadistributionen är på källdatabasen)
- DB-server 2 och exportserver 2 – dedikerad till tabeller med tabelldelningar
- DB-server 3 & exportserver 3 – dedikerad till tabeller med tabelldelningar
- DB-server 4 och exportserver 4 – alla återstående tabeller
Var noga med att se till att databaserna är exakt synkroniserade, annars kan dataförlust eller datainkonsekvenser uppstå. Om de angivna stegen följs exakt bevaras dataintegriteten.
Tekniken är enkel och billig med intel-standardmaskinvara men är också möjlig för kunder som kör egen UNIX-maskinvara. Betydande maskinvaruresurser är kostnadsfria mot mitten av ett OS/DB-migreringsprojekt när sandbox-, utvecklings-, QAS-, utbildnings- och DR-system redan har flyttats till Azure. Det finns inget strikt krav på att "klona" servrar har identiska maskinvaruresurser. Med tillräcklig processor-, RAM-, disk- och nätverksprestanda ökar tillägget av varje klon prestanda.
Om ytterligare exportprestanda fortfarande krävs öppnar du en SAP-incident i BC-DB-MSS för ytterligare steg för att öka exportprestanda (endast avancerade konsulter).
Stegen för att implementera en parallell export är följande:
- Säkerhetskopiera den primära databasen och återställ till "n" antal servrar (där n = antal kloner). I det här exemplet förutsätter du att n = 3 servrar gör totalt fyra DB-servrar.
- Återställ säkerhetskopieringen till tre servrar.
- Upprätta loggöverföring från den primära käll-DB-servern till tre målservrar för "klon".
- Övervaka loggöverföringen i flera dagar och se till att loggöverföringen fungerar på ett tillförlitligt sätt.
- I början av stilleståndstiden stänger du av alla SAP-programservrar utom PAS. Kontrollera att all batchbearbetning har stoppats och att all RFC-trafik stoppas.
- I transaktions-SM02 anger du texten "Checkpoint PAS Running". Detta uppdaterar tabellen TEMSG.
- Stoppa den primära programservern. SAP har nu stängts av. Ingen mer skrivaktivitet kan inträffa i källdatabasen. Se till att inget icke-SAP-program är anslutet till källdatabasen (det bör aldrig finnas det, men kontrollera om det finns några icke-SAP-sessioner på DB-nivå).
- Kör den här frågan på den primära DB-servern:
SELECT EMTEXT FROM [schema].TEMSG; - Kör den interna DBMS-nivåinstruktor:
INSERT INTO [schema].TEMSG “CHECKPOINT R3LOAD EXPORT STOP dd:mm:yy hh:mm:ss”(exakt syntax beror på käll-DBMS. INFOGA I EMTEXT) - Stoppa automatiska säkerhetskopieringar av transaktionsloggar. Kör en sista säkerhetskopiering av transaktionsloggen manuellt på den primära DB-servern. Kontrollera att loggsäkerhetskopian kopieras till klonservrarna.
- Återställ den slutliga säkerhetskopieringen av transaktionsloggen på alla tre noderna.
- Återställ databasen på de 3 "klonade" noderna.
- Kör följande SELECT-instruktion på alla fyra noderna:
SELECT EMTEXT FROM [schema].TEMSG; - Avbilda skärmresultaten för SELECT-instruktionen för var och en av de fyra DB-servrarna (den primära och de tre klonerna). Se till att noggrant inkludera varje värdnamn – att fungera som ett bevis på att klondatabasen och den primära är identiska och innehåller samma data från samma tidpunkt.
- Starta export_monitor.bat på varje Intel R3load-exportserver.
- Starta dumpfilkopian till Azure-processen (antingen AzCopy eller Robocopy).
- Starta import_monitor.bat på de virtuella R3load Azure-datorerna.
Följande diagram visar en befintlig Serverlogg för Production DB som skickas till "klona" databaser. Varje DB-server har en eller flera Intel R3load-servrar.
