Case:To reduce the burden on the core database, we adopt the logical STANDBY technology to separate the impact of physical reading on the core database. However, a report application uses a large number of intermediate tables. Generally, the basic data is saved to the intermediate table after calculation, and then the report is read to the intermediate table for presentation. Obviously, the best way to completely solve this problem is to push the computing process forward, that is, when the application inserts basic data, it actively inserts the computing data required by the report, or at least close to the report data. Otherwise, even if the intermediate table is used later, it will not be able to solve the massive IO overhead caused by temporary operations. However, the application is forced by manpower and time constraints and apparently does not dare to perform thorough Optimization in a short period of time. In the end, only the DBA opens the knife and starts the write function for the logical STANDBY, that is, the new table is used to write data. Obviously, this increases the maintainability of the logical STANDBY, but compared with reducing the pressure on the master database, our DBA would rather sacrifice some personal time.
Implementation Method:To improve maintainability and avoid confusion with the master database, we use completely independent users, tablespaces, and tables.
1. Create a user
2. Create a tablespace
3. Create a table
Key points:Modify parameters
1 stop logical applyalter database stop logical standby apply;
2. Define tables for which skip addresses are to be skeys)
Exec dbms_logstdby.skip ('schema _ ddls', 'test', 'test1', NULL );
Exec dbms_logstdby.skip ('yml', 'test', 'test1', NULL );
3 start logical applyalter database start logical standby apply immediate;
Alter database guard standby;
This article is from the "docker" blog, please be sure to keep this source http://yunlongzheng.blog.51cto.com/788996/1077943