Troubleshooting SQL*Loader Sessions
Oracle SQL*Loader provides a method of loading data from different sources into the Oracle Database. This section analyzes some of the features of the SQL*Loader utility as it pertains to the SQL Apply engine.
由于SQL*Loader同样采用SQL Apply engine的机制，故SQL*Loader脚本文件的不同也会影响到逻辑standby应用日志的速度。
我们知道SQL*Loader装载数据库时有如下3种方式。
LOAD DATA
INTO TABLE LOAD_STOK APPEND????????????? #在 LOAD_STOK后追加数据
LOAD DATA
INTO TABLE LOAD_STOK REPLACE ???????????? #在同一事务中，先delete LOAD_STOK中的数据后，导入数据
LOAD DATA
INTO TABLE LOAD_STOK TRUNCATE ? ? ? ? ? #先truncate LOAD_STOK，然后导入数据 ，需事先禁用相关约束，否则会报错
采用replace关键字比起truncate关键字更有可能引起逻辑备库上产生性能问题。

设想一个场景，如果主库上表A有10000条数据，当使用delete表A的数据时，主库能够对 表A执行delete语句将10000行数据库直接删除，但备库的SQL Apply engine需要对表A进行逐行删除，也就是执行10000次delete。如果表A上没有索引的话，那么就意味着备库需要对表A进行10000次全表扫 描。同时由于操作的行数较多，备库上对表A进行操作的事务将会被定义为"eager transaction"。 Eager Transaction是dml超过200行数据的事务，从10g R1开始，更新行数超过200行的事务都被定义为 Eager Transaction 。Eager Transaction的目的主要是为了当超过200行的数据操作时，可以及时同步到备库中，而不必等待事务被完整建立(笔者个人看法，应该是当dml超过200行时，不必等待该dml操作结束即同步到备库上，待考证)。

因此如果采用SQL*Loader装载数据库时需要删除原表的数据，建议采用truncate关键字。
Troubleshooting Pageouts
逻辑备库需要将redo记录解析成LCR，会在shared pool里分配一部分空间来作为LCR Cache，如果cache太小，就会像OS的虚拟内存管理一样，需要做page out，这会严重影响应用日志的性能。默认情况下，LCR Cache为Shared pool的四分之一，最少不少于30M，否则SQL Apply不能启动。如果机器的内存足够，建议将LCR Cache尽量设大一点，当然，同时share pool也要足够大。如果机器内存有限，那可以考虑将buffer cache减少一点来给LCR Cache腾出空间。
当SQL Apply engine想要创建大事务时，将会先使用"lcr cache"，而不是立即报类似于ORA-4031的错误。lcr cache的作用类似于操作系统上的swap，可以通过下列SQL查看是否发生了SQL Apply pageouts
SQL> select value
???? from v$logstdby_stats
???? where name like '%paged%';
VALUE
------------
358706176

上例中，SQL Apply engine启动后产生了358706176字节的换页。如果换页频繁出现在日常操作中，我们可以考虑加大逻辑备库的MAX_SGA
和操作系统的swap换页一样，SQL Apply engine会将换出的数据页写入到DBMS_LOGMNR_D.SET_TABLESPACE指定的表空间中，如果没有指定，默认为SYSAUX表空 间。oracle会在该表空间创建、命名lob段存储换出的数据页。如果指定的表空间没有足够的空余空间将会报ORA-1691错 误，alertSID.log里的报错如下
Tue Feb? 8 06:23:22 2005
Errors in file /u01/app/oracle/admin/TPCC_BOSTON/bdump/tpcc1_lsp0_9052.trc:
ORA-12801: error signaled in paralle