Oracle leverer ikke et out-of-the-box aflæsningsværktøj.
Husk uden omfattende information om dit miljø (oracle version? server platform? hvor meget data? hvilke datatyper?) alt her er YMMV, og du vil gerne give det en chance på dit system for ydeevne og timing.
Mine punkter 1-3 er blot generiske ideer til databevægelse. Punkt 4 er en metode, der reducerer nedetid eller afbrydelse til minutter eller sekunder.
1) Der er 3. parts hjælpeprogrammer tilgængelige. Jeg har brugt et par af disse, men det er bedst for dig selv at tjekke dem ud til dit formål. Et par 3. parts produkter er angivet her:OraFaq . Desværre kører mange af dem på Windows, hvilket ville sænke dataudlæsningsprocessen, medmindre din DB-server var på Windows, og du kunne køre indlæsningsværktøjet direkte på serveren.
2) Hvis du ikke har nogle komplekse datatyper som LOB'er, kan du rulle dine egne med SQLPLUS. Hvis du lavede en tabel ad gangen, kan du nemt parallelisere den. Emne er blevet besøgt på denne side sandsynligvis mere end én gang, her er et eksempel:Linky
3) Hvis du er 10g+, kan eksterne tabeller være en effektiv måde at udføre denne opgave på. Hvis du opretter nogle tomme eksterne tabeller med samme struktur som dine nuværende tabeller og kopierer dataene til dem, vil dataene blive konverteret til det eksterne tabelformat (en tekstfil). Endnu en gang, OraFAQ til redning .
4) Hvis du skal holde systemer parallelt i dage/uger/måneder, så brug et ændringsdatafangst/anvend værktøj til næsten nul nedetid. Vær forberedt på at betale $$$. Jeg har brugt Golden Gate Softwares værktøj, der kan mine Oracle-redo-logfilerne og levere insert/update-sætninger til en MySQL-database. Du kan migrere størstedelen af dataene uden nedetid ugen før start. I løbet af din startperiode skal du lukke kildedatabasen ned, få Golden Gate til at indhente de sidste resterende transaktioner, og derefter åbne adgang til din nye måldatabase. Jeg har brugt dette til opgraderinger, og indhentningsperioden var kun et par minutter. Vi havde allerede en webstedslicens til Golden Gate, så det var ikke noget, der skulle betales for os.
Og jeg vil spille rollen som Cranky DBA her og sige, at hvis du ikke kan få Oracle til at præstere godt, ville jeg elske at se en oversigt over, hvordan MySQL løste dine særlige problemer. Hvis du har en applikation, hvor du ikke kan røre ved SQL, er der stadig masser af mulige måder at tune Oracle på. /sæbekasse