Preparations before Datapump data migration

Preparations before Datapump data migration

In fact, for Datapump migration, if you have participated in XTTS, OGG, Veritas SF, External table increments, and other migration methods, you will find that Datapump is simple and clear. one advantage is that the operation is simple and clear, it must be better than imp in terms of performance. So don't underestimate this migration method. It doesn't mean which migration methods are the best, and there is no silver bullet in data migration. The most suitable one is the best.

Before migration, we still need to make some preparations to avoid temporary troubles and reduce the probability of errors. We need to know that the upgrade and migration are both in the morning and evening, and they are all in poor energy, if there is not enough preparation before migration, it will be a mess. Therefore, it is necessary to have a detailed check list at this point.

In the following scenario, we have a completely new hardware environment with a small amount of data. We need to upgrade it to the 11g environment and consider the Datapump solution.

I thought a lot about the preparations before the migration, And I summarized it as a practical solution. Some friends may wonder if it seems unnecessary to upgrade a database, in fact, in one case, the upgrade is performed by multiple nodes, so it is easy to leave some preparation work behind. In another case, you have done a lot of preparation work, however, in an emergency, you certainly won't be so calm. At this time, these preparations are well organized and you will save a lot of effort to strictly follow the plan.

Test the host machine and check whether sysbench processes exist. Generally, it takes about a week to test the host machine. If there is any hardware problem, you can eliminate it in time.
Ensure that the master and slave machines are not in the same Rack Space. the servers in the data center must confirm that they are not in the same Rack Space in advance to eliminate the extreme situation caused by power failure.
Configure password-free communication between two servers to facilitate dump Transmission
Optimize kernel parameters (for example, set HugePage), disable NUMA, and set resource memlock.
Synchronize Firewall Information of two servers
Synchronize/etc/hosts information and modify the Host IP Address
Synchronize the information of listener. ora tnsnames. ora. The host is the host name instead of the IP address.
Change the host name root and Oracle password to security mode.
Check database logs and ORA-related errors. Check logs to check whether the large page is enabled.
Set NTP Time Synchronization
If DB Link exists, you need to activate related firewall permissions to ensure smooth access.
If other servers have related DB links, you need to prepare tnsnames. ora for connecting to the new database in advance.
Check the graphic interface to ensure that the image is displayed normally. If you can perform some operations, you can use the graphic tool.
Check whether the listener ports enabled by the master/Slave database are consistent.
Database parameter adjustment and optimization (Disable password expiration 60 days, some new features)
Set the database temp and undo size on the target server
Check whether the character set of the Master/Slave database is consistent
Check invalid objects in the database
Confirm the data problems during the drill and the data problems related to Foreign keys.
Check whether the slave database can be started to read-only status
Install the zabbix Client
Check whether the source server has sufficient disk space.