189 8069 5689
一般来说，减少索引和约束（比如如果是唯一索引insert时会进行验证，check也会验证），能提高一部分insert效率。
做网站、成都网站制作介绍好的网站是理念、设计和技术的结合。创新互联建站拥有的网站设计理念、多方位的设计风格、经验丰富的设计团队。提供PC端+手机端网站建设，用营销思维进行网站设计、采用先进技术开源代码、注重用户体验与SEO基础，将技术与创意整合到网站之中，以契合客户的方式做到创意性的视觉化效果。
append参数也有一定的作用。（与高水位标记线有关）
对于数据量很大的insert，进行分批，也有一定的作用。（减少内存征用的等待时间）
表分区也有一些作用。（因为可以同时执行多个insert，每个分区都可以执行一个自己分区的insert，相当于并行）
变插入为导入，比如变为文本然后利用外部表程序导入（这样走的是系统内存和程序内存，而且导入的操作，比dml语句操作快很多）
这些都是一般的想法，具体的选择要根据你的实际情况进行。
1、可以缩小到5张表，因为很多都是从一张表里取出来的数据；
2、不能子查询因为是要显示数据子查询只是查询条件；
3不能建立索引，因为这样会影响表的增删改，它里面都是导入进去的一次增加上千条都有可能；
4、定期结转是什么意思，表示没看懂。时间发的太长的话就算了；
5、定期结转的意思就是，将你要建立视图的几种表数据“转移”到一张新表里面去，不用视图查询。数据库全文检索是RDBMS自带的扩展功能，可以实现高速查询。全文检索建议搜索下关键字，什么lucene之类的就出来了。
需要用索引来解决，索引的创建规则如下：
1、表的
主键
、
外键
必须有索引；
2、数据量超过300的表应该有索引；
3、经常与其他表进行连接的表，在连接字段上应该建立索引；
4、经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；
5、索引应该建在选择性高的字段上；
6、索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；
7、复合索引的建立需要进行仔细分析；尽量考虑用单字段索引代替：
A、
正确选择
复合索引中的主列字段，一般是选择性较好的字段；
B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中？单字段查询是否极少甚至没有？如果是，则可以建立复合索引；否则考虑单字段索引；
C、如果复合索引中包含的字段经常单独出现在Where子句中，则分解为多个单字段索引；
D、如果复合索引所包含的字段超过3个，那么仔细考虑其必要性，考虑减少复合的字段；
E、如果既有单字段索引，又有这几个字段上的复合索引，一般可以删除复合索引；
8、频繁进行
数据操作
的表，不要建立太多的索引；
9、删除无用的索引，避免对执行计划造成负面影响；
以上是一些普遍的建立索引时的判断依据。一言以蔽之，索引的建立必须慎重，对每个索引的必要性都应该经过仔细分析，要有建立的依据。因为太多的索引与不充分、不正确的索引对性能都毫无益处：在表上建立的每个索引都会增加存储开销，索引对于插入、删除、更新操作也会增加处理上的开销。另外，过多的复合索引，在有单字段索引的情况下，一般都是没有
存在价值
的；相反，还会降低数据增加删除时的性能，特别是对频繁更新的表来说，负面影响更大。
几个简单的步骤大幅提高Oracle性能--我优化数据库的三板斧。
数据库优化的讨论可以说是一个永恒的主题。资深的Oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack，贴出数据库配置等等。还有的人认为要抓出执行最慢的语句来进行优化。但实际情况是，提出疑问的人很可能根本不懂执行计划，更不要说statspack了。而我认为，数据库优化，应该首先从大的方面考虑：网络、服务器硬件配置、操作系统配置、Oracle服务器配置、数据结构组织、然后才是具体的调整。实际上网络、硬件等往往无法决定更换，应用程序一般也无法修改，因此应该着重从数据库配置、数据结构上来下手，首先让数据库有一个良好的配置，然后再考虑具体优化某些过慢的语句。我在给我的用户系统进行优化的过程中，总结了一些基本的，简单易行的办法来优化数据库，算是我的三板斧，呵呵。不过请注意，这些不一定普遍使用，甚至有的会有副作用，但是对OLTP系统、基于成本的数据库往往行之有效，不妨试试。（注：附件是Burleson写的用来报告数据库性能等信息的脚本，本文用到）
一．设置合适的SGA
常常有人抱怨服务器硬件很好，但是Oracle就是很慢。很可能是内存分配不合理造成的。(1)假设内存有512M，这通常是小型应用。建议Oracle的SGA大约240M，其中：共享池（SHARED_POOL_SIZE）可以设置60M到80M，根据实际的用户数、查询等来定。数据块缓冲区可以大致分配120M-150M，8i下需要设置DB_BLOCK_BUFFERS，DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于数据块缓冲区大小。9i 下的数据缓冲区可以用db_cache_size来直接分配。
(2)假设内存有1G，Oracle 的SGA可以考虑分配500M：共享池分配100M到150M，数据缓冲区分配300M到400M。
(3)内存2G，SGA可以考虑分配1.2G，共享池300M到500M，剩下的给数据块缓冲区。
(4)内存2G以上：共享池300M到500M就足够啦，再多也没有太大帮助；(Biti_rainy有专述)数据缓冲区是尽可能的大，但是一定要注意两个问题：一是要给操作系统和其他应用留够内存，二是对于32位的操作系统，Oracle的SGA有1.75G的限制。有的32位操作系统上可以突破这个限制，方法还请看Biti的大作吧。
二．分析表和索引，更改优化模式
Oracle默认优化模式是CHOOSE，在这种情况下，如果表没有经过分析，经常导致查询使用全表扫描，而不使用索引。这通常导致磁盘I/O太多，而导致查询很慢。如果没有使用执行计划稳定性，则应该把表和索引都分析一下，这样可能直接会使查询速度大幅提升。分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令。对于少于100万的表，可以考虑分析整个表，对于很大的表，可以按百分比来分析，但是百分比不能过低，否则生成的统计信息可能不准确。可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间，索引可以通过DBA_INDEXES的LAST_ANALYZED列。
下面通过例子来说明分析前后的速度对比。（表CASE_GA_AJZLZ大约有35万数据，有主键）首先在SQLPLUS中打开自动查询执行计划功能。(第一次要执行\RDBMS\ADMIN\utlxplan.sql来创建PLAN_TABLE这个表)
SQL SET AUTOTRACE ON
SQLSET TIMING ON
通过SET AUTOTRACE ON 来查看语句的执行计划，通过SET TIMING ON 来查看语句运行时间。
SQL seleCT count(*) from CASE_GA_AJZLZ;
COUNT(*)
----------
346639
已用时间: 00: 00: 21.38
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'CASE_GA_AJZLZ'
……………………
请注意上面分析中的TABLE ACCESS(FULL)，这说明该语句执行了全表扫描。而且查询使用了21.38秒。这时表还没有经过分析。下面我们来对该表进行分析：
SQL analyze table CASE_GA_AJZLZ compute statistics;
表已分析。已用时间: 00: 05: 357.63。然后再来查询：
SQL select count(*) from CASE_GA_AJZLZ;
COUNT(*)
----------
346639
已用时间: 00: 00: 00.71
Execution Plan
0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=351 Card=1)
1 0 SORT (AGGREGATE)
2 1 INDEX (FAST FULL SCAN) OF 'PK_AJZLZ' (UNIQUE) (Cost=351
Card=346351)
…………………………
请注意，这次时间仅仅用了0.71秒！这要归功于INDEX(FAST FULL SCAN)。通过分析表，查询使用了PK_AJZLZ索引，磁盘I/O大幅减少，速度也大幅提升！下面的实用语句可以用来生成分析某个用户的所有表和索引，假设用户是GAXZUSR：
SQL set pagesize 0
SQL spool d:\analyze_tables.sql;
SQL select 'analyze table '||owner||'.'||table_name||'
compute statistics;' from dba_tables where owner='GAXZUSR';
SQL spool off
SQL spool spool d:\analyze_indexes.sql;
SQL select 'analyze index '||owner||'.'||index_name||'
compute statistics;' from dba_indexes where owner='GAXZUSR';
SQL spool off
SQL @d:\analyze_tables.sql
SQL @d:\analyze_indexes.sql
解释：上面的语句生成了两个sql文件，分别分析全部的GAXZUSR的表和索引。如果需要按照百分比来分析表，可以修改一下脚本。通过上面的步骤，我们就完成了对表和索引的分析，可以测试一下速度的改进啦。建议定期运行上面的语句，尤其是数据经过大量更新。
当然，也可以通过dbms_stats来分析表和索引，更方便一些。但是我仍然习惯上面的方法，因为成功与否会直接提示出来。
另外，我们可以将优化模式进行修改。optimizer_mode值可以是RULE、CHOOSE、FIRST_ROWS和ALL_ROWS。对于OLTP系统，可以改成FIRST_ROWS，来要求查询尽快返回结果。这样即使不用分析，在一般情况下也可以提高查询性能。但是表和索引经过分析后有助于找到最合适的执行计划。
三．设置cursor_sharing=FORCE 或SIMILAR
这种方法是8i才开始有的，oracle805不支持。通过设置该参数，可以强制共享只有文字不同的语句解释计划。例如下面两条语句可以共享：
SQL SELECT * FROM MYTABLE WHERE NAME='tom'
SQL SELECT * FROM MYTABLE WHERE NAME='turner'
这个方法可以大幅降低缓冲区利用率低的问题，避免语句重新解释。通过这个功能，可以很大程度上解决硬解析带来的性能下降的问题。个人感觉可根据系统的实际情况，决定是否将该参数改成FORCE。该参数默认是exact。不过一定要注意，修改之前，必须先给ORACLE打补丁，否则改之后oracle会占用100%的CPU,无法使用。对于ORACLE9i，可以设置成SIMILAR，这个设置综合了FORCE和EXACT的优点。不过请慎用这个功能，这个参数也可能带来很大的负面影响！
四．将常用的小表、索引钉在数据缓存KEEP池中
内存上数据读取速度远远比硬盘中读取要快，据称，内存中数据读的速度是硬盘的14000倍！如果资源比较丰富，把常用的小的、而且经常进行全表扫描的表给钉内存中，当然是在好不过了。可以简单的通过ALTER TABLE tablename CACHE来实现，在ORACLE8i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP)。一般来说，可以考虑把200数据块之内的表放在keep池中，当然要根据内存大小等因素来定。关于如何查出那些表或索引符合条件，可以使用本文提供的access.sql和access_report.sql。这两个脚本是著名的Oracle专家 Burleson写的，你也可以在读懂了情况下根据实际情况调整一下脚本。对于索引，可以通过ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)来钉在KEEP池中。
将表定在KEEP池中需要做一些准备工作。对于ORACLE9i 需要设置DB_KEEP_CACHE_SIZE，对于8i，需要设置buffer_pool_keep。在8i中，还要修改db_block_lru_latches，该参数默认是1，无法使用buffer_pool_keep。该参数应该比2*3*CPU数量少，但是要大于1，才能设置DB_KEEP_CACHE_BUFFER。buffer_pool_keep从db_block_buffers中分配，因此也要小于db_block_buffers。设置好这些参数后，就可以把常用对象永久钉在内存里。
五．设置optimizer_max_permutations
对于多表连接查询，如果采用基于成本优化(CBO)，ORACLE会计算出很多种运行方案，从中选择出最优方案。这个参数就是设置oracle究竟从多少种方案来选择最优。如果设置太大，那么计算最优方案过程也是时间比较长的。Oracle805和8i默认是80000，8建议改成2000。对于9i，已经默认是2000了。
六．调整排序参数
(1) SORT_AREA_SIZE:默认的用来排序的SORT_AREA_SIZE大小是32K，通常显得有点小，一般可以考虑设置成1M（1048576）。这个参数不能设置过大，因为每个连接都要分配同样的排序内存。
(2) SORT_MULTIBLOCK_READ_COUNT:增大这个参数可以提高临时表空间排序性能，该参数默认是2，可以改成32来对比一下排序查询时间变化。注意，这个参数的最大值与平台有关系。
本文档旨在提供指南和核对清单，用于将之前升级的数据库从Oracle12c降级回以前的版本：11.2.0.3,11.2.0.2,11.1.0.7必须加以说明的是，将数据库实例从当前版本降级到升级前的版本时，数据库不会返回到升级前的完全相同状态。根据所涉及的版本，升级过程会进行不可逆的更改。用户使用降级过程可以打开和访问以前版本的数据库实例。这通常便已足够。可能需要采取其他更正操作（例如卸载/重新安装或重新升级到当前补丁集级别来解决降级后的遗留问题。如果目标是让实例返回与升级前完全相同的状态，则还应使用包括完全恢复到升级前状态在内的其他过程。本文中讨论的过程是基于脚本的降级。本文不介绍使用导出/导入、数据泵或其他方法将数据从一个版本移动到另一个版本。您所降级到的版本的Oracle二进制文件，在开始降级过程之前应该在服务器上可用/已安装。如果您卸载了要降级到的Oracle可执行文件，请重新安装Oracle二进制文件到正确的版本/补丁程序级别以降级。此过程旨在降级已成功升级到12c的数据库，并非用于从失败的升级退回。您只能降级到升级前所用的版本和补丁程序级别。直接升级可以在版本10.2.0.5、11.1.0.7或版本11.2.0.2及更高版本上执行。可以对这些版本中除10.2.0.5之外的版本进行降级。例如，如果通过应用中间补丁程序11.1.0.7从Oracle11.1.0.6升级到Oracle12c(12.1.0)，则不能降级到Oracle11.1.0.6。降级只能对直接升级版本执行。例外：虽然可以对10.2.0.5直接升级，但降级不适用于10.2.0.5。这是因为在升级过程中，compatible参数已设置为最低11.0.0。这使得无法降级到10.2.0.5。可以降级的版本为11.1.0.7、11.2.0.2、11.2.0.3或更高版本。如果有任何补丁程序应用到了从升级后的主目录运行的源数据库，则需要先回退，然后才能开始降级过程。卸载和回退补丁程序的步骤记录在所涉及补丁程序的自述文件中。未能卸载和回退补丁程序可能会导致无法降级，包括无法重新验证字典对象。Exadata捆绑补丁程序示例，其过程为：卸载补丁程序示例：$opatchauto/u01/app/oracle/patches/14103267-rollback回退任何在补丁程序应用过程中应用的SQL：示例：SQL@rdbms/admin/catbundle_EXA__ROLLBACK.sql，用于回退SQL更改。解决方案降级前步骤-XMLDB组件在12c中是必需的。在升级到12c期间，将安装XMLDB组件（如果未安装）。从12c降级将删除安装的XDB组件-EnterpriseManager不支持降级。在降级之前，请重新配置OracleEM控件。请参阅OracleDatabaseUpgradeGuide12cRelease1(12.1)E17642-106DowngradingOracleDatabasetoanEarlierRelease6.6.5RestoringOracleEnterpriseManagerafterDowngradingOracleDatabase-升级到12c期间，将删除DatabaseControl资料档案库。降级之后，请重新配置DBControl。Note870877.1HowToSaveOracleEnterpriseManagerDatabaseControlDataBeforeUpgradingTheSingleInstanceDatabaseToOtherRelease?Note876353.1HowToRestoreTheOracleEnterpriseManagerDataToDowngradeTheSingleInstanceDatabaseToPrevious/SourceRelease?-compatible参数不能已经更改到12.1.0。-禁用DataVault（如果已启用）。Note803948.1HowToUninstallOrReinstallDatabaseVaultin11g(UNIX)Note453902.1EnablingandDisablingOracleDatabaseVaultinWINDOWS-如果数据库使用OracleLabelSecurity，则在新OracleDatabase12cOracle主目录中运行OracleLabelSecurity(OLS)预处理降级olspredowngrade.sql脚本（在$ORACLE_HOME/rdbms/admin上提供）。-时区版本应相同。-取消设置并指向12c主目录的ORA_TZFILE（如果已设置）。-如果数据库上有OracleApplicationExpress，则必须将apxrelod.sql文件从OracleDatabase12c$ORACLE_HOME/apex/目录复制到Oracle主目录之外的目录，例如系统上的临时目录以稍后执行。-如果基于固定对象创建了对象，则删除这些对象以避免可能的ORA-00600错误。您可以在降级之后重新创建这些对象。-如果降级集群数据库，则彻底关闭实例并将CLUSTER_DATABASE初始化参数更改为FALSE。降级之后，必须将此参数设置回TRUE。满足以上先决条件之后，可以继续进行降级。数据库的降级步骤1)确保所有数据库组件有效。只能从成功升级的数据库执行降级。要验证数据库组件状态，请执行以下查询以SYS用户身份连接到数据库colcomp_idformata10colcomp_nameformata30colversionformata10colstatusformata8selectsubstr(comp_id,1,15)comp_id,substr(comp_name,1,30)comp_name,substr(version,1,10)version,statusfromdba_registry2)验证没有属于sys/system的无效对象selectowner,count(object_name)"Invalidobjectcount"fromdba_objectswherestatus!='VALID'andownerin('SYS','SYSTEM')groupbyowner;如果计数为零，则可以继续降级。如果有无效对象，则执行utlrp.sql多次，如果对象无法解析为有效状态，则不能继续降级。建立SR或在DBA社区上发帖以寻求帮助。或者，对于1和2，运行以下脚本：Note556610.1ScripttoCollectDBUpgrade/MigrateDiagnosticInformation(dbupgdiag.sql)3)关闭数据库Shutdownimmediate4)对12c数据库做备份5)以降级模式启动数据库Startupdowngrade;6)执行降级脚本SqlSpooldowngrade.logSql@$ORACLE_HOME/rdbms/admin/catdwgrd.sql注：$ORACLE_HOME应指向12c主目录catdwgrd.sql脚本将数据库中的所有组件降级到支持的主版本或补丁集版本（您最初升级时的版本）SqlspooloffSqlshutdownimmediateExitSQLPlusSqlexit;7)如果操作系统为LINUX/UNIX：将以下环境变量更改为要降级到的源数据库：ORACLE_HOMEPATH编辑/etc/oratabor/var/opt/oracle/oratab以更改将数据库映射到源数据库Oracle主目录如果操作系统是Windows，则完成以下步骤：a.停止所有Oracle服务，包括OracleDatabase12c数据库的OracleServiceSIDOracle服务，其中SID是实例名称。例如，如果SID为ORCL，则在命令行提示符中输入以下内容：C:\NETSTOPOracleServiceORCLb.在命令提示符下，通过运行ORADIM命令删除Oracle服务。如果出现提示，则输入此Windows系统上活动标准用户帐户的口令。例如，如果SID为ORCL，则输入以下命令：C:\ORADIM-DELETE-SIDORCLc.在命令提示符下，使用ORADIM命令创建要降级的数据库的Oracle服务。C:\ORADIM-NEW-SIDSID-INTPWDPASSWORD-MAXUSERSUSERS-STARTMODEAUTO-PFILEORACLE_HOME\DATABASE\INITSID.ORA8)还原配置文件将配置文件（口令文件、参数文件等）还原到降级版本的ORACLE_HOME。9)如果这是OracleRAC数据库，则执行以下命令以将数据库修改为单实例模式：SETCLUSTER_DATABASE=FALSE10)从降级版本$ORACLE_HOME/rdbms/admin目录执行catrelod脚本。启动sqlplus，以具有sysdba权限的用户SYS身份连接到数据库实例，然后以升级模式启动数据库：:cd$ORACLE_HOME/rdbms/admin:sqlplussqlconnectsysassysdbasqlstartupupgradesqlspoolcatrelod.logsql@?/rdbms/admin/catrelod.sqlsqlspooloffcatrelod.sql脚本在降级的数据库中重新加载各个数据库组件的合适版本。11)运行utlrp.sql脚本：SQL@utlrp.sqlSqlexit;utlrp.sql脚本重新编译先前处于INVALID状态的所有现有PL/SQL模块，例如package、procedure、type等。12)检查已降级数据库的状态：Note556610.1ScripttoCollectDBUpgrade/MigrateDiagnosticInformation(dbupgdiag.sql)此sql脚本是一组查询语句，用于提供用户友好的输出，以在升级前后诊断数据库的状态。脚本将创建名为db_upg_diag__.log的文件。13)降级之后，可能在sys用户下发现无效的QT视图。这是因为视图已从基表中选择了错误的列。您需要重新创建这些视图。请参阅说明：Note1520209.1QT_*BUFERViewsInvalidafterdowngradefrom12C降级后步骤：1)如果您是降级到OracleDatabase11g版本1(11.1.0.7)并且数据库中有OracleApplicationExpress，则转到您将apxrelod.sql脚本复制到的目录（在降级前步骤中）。运行apxrelod.sql脚本以手动重新加载OracleApplicationExpress：SQL@apxrelod.sql运行apxrelod.sql脚本以避免程序包APEX_030200.WWV_FLOW_HELP由于以下错误而成为INVALID状态：PLS-00201:identifier'CTX_DDL'mustbedeclared2)如果数据库中启用了OracleLabelSecurity，则执行以下脚本a.从OracleDatabase12c的Oracle主目录下将olstrig.sql脚本复制到要将数据库降级到的版本的Oracle主目录。b.从降级到的版本的Oracle主目录，运行olstrig.sql以在表上使用OracleLabelSecurity策略重新创建DML触发器：SQL@olstrig.sql3)如果降级集群数据库，则必须运行以下命令以降级OracleClusterwaredatabase配置：$srvctldowngradedatabase-ddb-unique-name-ooraclehome-tto_version其中db-unique-name是数据库名称（而非实例名称），oraclehome是已降级数据库的旧Oracle主目录的位置，to_version是数据库所降级到的数据库版本
1、使用两边加‘%’号的查询，Oracle是不通过索引的，所以查询效率很低。
例如：select count(*) from lui_user_base t where t.user_name like '%cs%';
2、like '...%'和 like'%...'虽然走了索引，但是效率依然很低。
3、有人说使用如下sql，他的效率提高了10倍，但是数据量小的时候
select count(*) from lui_user_base where rowid in (select rowid from lui_user_base t where t.user_name like '%cs%')
我拿100w跳数据做了测试，效果一般，依然很慢，原因：
select rowid from lui_user_base t where t.user_name like '%cs%' 这条sql执行很快，那是相当的快，但是放到select count(*) from lui_user_base where rowid in（）里后，效率就会变的很慢了。
4、select count(*) from lui_user_base t where instr(t.user_name,'cs') 0
这种查询效果很好，速度很快，推荐使用这种。因为我对oracle内部机制不是很懂，只是对结果做了一个说明。
5、有人说了用全文索引，我看了，步骤挺麻烦，但是是个不错的方法，留着备用：
对cmng_custominfo 表中的address字段做全文检索：
1，在oracle9201中需要创建一个分词的东西：
BEGIN
ctx_ddl.create_preference ('SMS_ADDRESS_LEXER', 'CHINESE_LEXER');
--ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer'); 不用
end;
2，创建全文检索：
CREATE INDEX INX_CUSTOMINFO_ADDR_DOCS ON cmng_custominfo(address) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER SMS_ADDRESS_LEXER');
3，查询时候，使用：
select * from cmng_custominfo where contains (address, '金色新城')1;
4，需要定期进行同步和优化：
同步：根据新增记录的文本内容更新全文搜索的索引。
begin
ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');
end;
优化：根据被删除记录清除全文搜索索引中的垃圾
begin
ctx_ddl.optimize_index('INX_CUSTOMINFO_ADDR_DOCS', 'FAST');
end;
5，采用job做步骤4中的工作：
1)该功能需要利用oracle的JOB功能来完成
因为oracle9I默认不启用JOB功能，所以首先需要增加ORACLE数据库实例的JOB配置参数:
job_queue_processes=5
重新启动oracle数据库服务和listener服务。
2)同步 和 优化
--同步 sync:
variable jobno number;
BEGIN
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''INX_CUSTOMINFO_ADDR_DOCS'');',
SYSDATE, 'SYSDATE + (1/24/4)');
commit;
END;
--优化
variable jobno number;
begin
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''INX_CUSTOMINFO_ADDR_DOCS'',''FULL'');', SYSDATE, 'SYSDATE + 1');
commit;
END;
其中， 第一个job的SYSDATE + (1/24/4)是指每隔15分钟同步一次，第二个job的SYSDATE + 1是每隔1天做一次全优化。具体的时间间隔，可以根据应用的需要而定。
6，索引重建
重建索引会删除原来的索引，重新生成索引，需要较长的时间。
重建索引语法如下：
ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;
据网上一些用家的体会，oracle重建索引的速度也是比较快的，有一用家这样描述：
Oracle 的全文检索建立和维护索引要比ms sql server都要快得多，笔者的65万记录的一个表建立索引只需要20分钟，同步一次只需要1分钟。
因此，也可以考虑用job的办法定期重建索引。