对于default或者max分区有数据的，可以采用split的方式避免删除最大分区，但最大分区数据量过大可能会花费更多时间。对于default或者max分区有数据的，可以采用split的方式避免删除最大分区，但最大分区数据量过大可能会花费更多时间。对于default或者max子分区有数据的情况，可以采用split的方式避免全局索引失效，跟分区表的split不一样。使用add subpartition增加分区，在无最大分区的情况下可以直接扩容（分区不适用，但哈希分区可以直接add分区，一般也没有必要扩容。

如下图，分区表，local字段的不支持反向索引。一、重建的方式改造反向索引。全局索引，则没有问题.1、创建普通主键索引。2、创建反向主键索引。

---------------------------------------附件，子分区建表语句---------------------------------子分区，全局索引并没有失效（子分区没有数据的情况下，全局索引不会失效）。但必须加上分区键、子分区键MT_O_CODE,M_YMD。子分区有数据，对子分区ddl后，全局索引失效。分区有数据，ddl后全局索引失效。2、删除子分区（子分区没有数据）分区没有数据，全局索引不失效。--查看分区索引状态。--查看子分区索引状态。--查看全局索引状态。

range分区，单个分区内非分区字段的值不是顺序的，分区字段值也不是顺序的（如按100值分区，第一个分区是1-100，顺序可能是7,1,3,67,9这样的，第二分区101-200，顺序可能是199,136,103,178这样的，但是相对两个分区而言，第二个分区和第一个分区值的范围是顺序的）当然，它们还有其他的区别。分区字段的分区索引是顺序的，因为第一个数据分区开始到后面的数据分区是range顺序的，虽然单独的数据分区内数据不是顺序的。非分区字段只是某一分区索引内的索引是顺序的，不代表分区索引是顺序的。

3、修改实例指向新的undo表空间（2个节点）2、新建2个节点的undo表空间。4、删除老的undo表空间。1、查看undo表空间。

2、设置数据库的新默认表空间为新建临时表空间。1、创建新的临时表空间。3、删除老的临时表空间。

6、综合以上分析，在统计信息准确且无法通过绑定计划（sql过多）提高效率，只能修改sql代码加hint的方式开展。参照Plan hash value: 1532449235的执行计划，加hint强制走IDX_QTY_CHARG_LIST_CUST这个索引。2、按通常来说处置方法很简单，绑定1532449235这个hashvalue的执行计划即可。4、统计目前已有100余个sql_id，因此无法通过绑定执行计划解决该问题。5、查看该表统计信息比较陈旧，收集统计信息，但问题依旧。

直到原有logfile为INACTIVE状态。直到原有logfile为INACTIVE状态。一、增加新日志组，并放在不同磁盘。四、节点1删除原有的group组。六、节点2删除原有的group组。三、节点1删除原有归档日志组。五、节点2删除原有归档日志组。

--Current.257.1057568499这种格式必须用rman 导入。打开其中一个节点到nomount状态。

这些xxxxxxx表示转换后能承载的长度，尽量长一些，太短会报错。长了，多的只会多几个空格。1、十六进制转换成十进制。2、十进制转换成十六进制。

查看字段的统计信息：select table_name,column_name,num_distinct,low_value,high_value,density from user_tab_columns;truncate命令不会修改数据的统计信息,也就是如果我们想让CBO利用合理利用数据的统计信息的时候,需要我们及时的使用analyze命令或者dbms_stats重新统计数据的统计信息。统计信息产生在user_tables、user_tab_columns、user_indexes中。

STALE_STATS=YES 表示过期了（表中10%的数据发生了变化）LAST_ANALYZED 表示上次统计信息收集时间。STALE_STATS=NO 未过期，--查看表的统计信息是否过期，二、关闭数据库统计信息收集。三、开启数据库统计信息收集。四、查看表的统计信息。

判断是物化视图创建的时候需要兼容所有分区的数据，所以报错，而分区表则不存在这种情况。最终原因是：缺少了 这个 r34411分区，加上就好。在跑脚本的时候创建物化试图提示分区界限过高。

直到Oracle10.2.0.5开始，Oracle也意识到了asm的这个问题，在asm metadata中保留了一个备份块，这样使用 kfed的一个隐含功能就可以实现asm磁盘头的一键修复了。Kfed repair功能可以一键修复磁盘头，哪怕你对磁盘头一无所知，只要会使用这个命令就可以了。本次再次将asm_disk2加入磁盘组，在加入磁盘组的过程中会将磁盘头信息重新写，造成本次异常。经分析，asm_disk2是本次新加的磁盘，对应的是DATA_008；1、asm磁盘组扩容的前建议首先备份磁盘的头文件。

5、如果丢失当前控制文件，用冷备份的控制文件恢复的时候，用来告诉oracle，不要以controlfile中的scn作为恢复的终点；如果丢失当前controlfile并且current/active redo都丢失，会先去自动应用归档日志,可以实现最大的恢复；关键文件：①system01 file，②undotbs file，③control file，④current log。三、一致性关库后，手工冷备数据库，未备份联机日志文件，使用冷备恢复时，启动到 mount 状。

2、数据库存储连接配置。

2.系统有一个默认的监听器叫做 LISTENER，端口号是 1521，利用它可以不需要 listener.ora 配置文件。（11g pmon 进程）2、动态监听每分钟注册一次（LEGN或者PMON进程），静态监听打开就是注册的。使用非默认端口的动态监听程序时，需要修改 local_listener 参数。0、动态监听，就算没有listener.ora,也会自动使用动态监听。1、动态监听是 READY状态，静态监听是UNKNOWN状态。3、动态监听无法远程启动数据库，静态监听远程登录数据库并打开。

将vm.dirty_background_ratio设置为5-10，将vm.dirty_ratio设置为它的两倍左右，以确保能持续将脏数据刷新到磁盘，避免瞬间I/O写，产生严重等待（和MySQL中的innodb_max_dirty_pages_pct类似）后续检查主机，发现主机重启过，检查操作系统日志，发现从15.02分开始，: INFO: task ocssd.bin:16080 blocked for more than 120 seconds. 有任务被hung 住，可以调整 操作系统参数，

基于当前系统压力较大，执行大量sql会调整shared pool，随机决定将LOCAL=NO的会话全部从操作系统杀掉，数据库恢复正常。2、查看数据库主机资源消耗情况，发现74451的oracle进程长期cpu使用率100%1、查看数据库日志未发现异常，还有归档切换，说明数据库并没有完全夯死。1、数据库连接失败，监控工具告警无法连接到数据库。建议：增大sga，并设置shared pool。说明 shared pool 在一直在增长。3、继续查询发现该进程为mmon进程。4、查看该进程trc文件。

3、因此判断是由于nfs挂载不正常导致，继续查找历史记录验证。4、果然是由于nfs没有挂载，备份的时候直接备份到根目录了。数据库操作系统自动重启，提示写入错误，没有剩余空间。3、设置目录自动挂载，彻底解决该问题。2、查看该目录里的内容是数据库备份集。2、迁移根目录上的备份集，释放空间。1、查看根目录已经达到98%

可以考虑分片导入数据，且lob对象可以“ENABLE STORAGE IN ROW”，参考：墨天轮脚本：SPLIT_TAB_ROWID。合理利用并行，数据量小的schema一起导入，数据量大的单独导入、分表导入。以全库迁移为标准，也可直接通过需求方获取需要迁移的用户。4.1、单独导出大表、LOB、LONG（可分多个脚本）4.2、单独导入大表、LOB、LONG（可分多个脚本）3.6、检查大事务、停止源端数据库(两个节点)3.4、修改job参数，以及查杀JOB会话。2）以系统用户创建时间为限确认需要的用户。

每次执行删除partition_position = '2'的分区，删除之后，partition_position = '3'的分区会前移到partition_position 为 '2';该存储过程部署后，设置成定时任务，每天执行。

--------来自Oracle官方的tfa收集要求。

1、点击目录2、选择文件3、选择表名。

2、按大表2千万为维度，统计出大表，再根据大表找到最近一天的sql，统计其执行效率（毫秒），创建数据存储表。三、创建存储过程，将第二步的查询结果插入到数据表dbtj_tab。四、创建定时任务，每天1、7、13、19 统计。

当前的基数值为8,这里我们修改成7(基数值必须小于或等于AWR快照所设置的保留值)修改采集间隔为1小时,保留时间是3天。二、修改采集间隔和保留时间。报错解决办法,修改基数值。

services --每个service的统计信息，不论是哪个用，只要是连接这个service的就统计在内。v$session_event --每个session的每一项等待事件。v$session_wait -- 会话正在等待什么。v$event_name --等待事件的定义。v$sgainfo --内存使用情况。2、会话相关的动态性能视图。

备份参数文件 create pfile='/home/oracle/pfile.ora' from spfile;备份控制文件 Alter database backup controlfile to trace;2、操作系统层面kill掉所有LOCAL=NO的所有进程，即：连接会话。1、关闭两节点的监听；5、等待5-10分钟。

关闭主库和备库二节点实例后，查询应用延迟情况的时候，发现一直存在延迟。发现是read only状态，而没有WITH APPLY。2、因此重新起动apply日志应用。1、在备库查看其日志应用情况。

----修复所有记录在V$DATABASE_BLOCK_CORRUPTION中的逻辑坏块。一、由于数据库或者操作系统bug、IO错误、内存异常等原因，可能会导致数据库产生坏块，针对是否存在坏块可使用rman进行检查。} --修复单个坏块。四、发现坏块后，首先要获得坏块的所属对象、文件号及块位置。--检测数据文件物理坏块信息。

如下日志所示，数据库出现ORA-01033: ORACLE 正在初始化或关闭报错，非常吓人，但数据库没有重启记录。4、该dblink异常的原因是，该dblink连接的数据库正在重启，导致这个告警产生。ORA-12012: 自动执行作业 "DT"."TZB_JOB1" 出错。ORA-02063: 紧接着 line (起自 DT_TO_DT)3、查看这个job是在调用DT_TO_DT的dblink异常。---原因是数据库正在初始化或者已经被关闭。---连接这个dblink失败。---执行job报错。

本次异常原因是：原因定位3： 库缓存对象无效 Library cache object Invalidations。数据库和前段应用重启后，出现大量library cache lock等待事件。三、各类情况具体分析如下。

-检测数据文件物理坏块信息RMAN> run {blockrecover datafile 5 block 1345;} --修复单个坏块RMAN> run {blockrecover corruption list;} ----修复所有记录在V$DATABASE_BLOCK_CORRUPTION中的逻辑坏块。一、由于数据库或者操作系统bug、IO错误、内存异常等原因，可能会导致数据库产生坏块，针对是否存在坏块可使用rman进行检查。四、发现坏块后，首先要获得坏块的所属对象、文件号及块位置。

注意，在ADG存在延迟的情况下，不可再进行switch over的切换，一定要追上延迟再开展切换。关闭主库和备库二节点实例后，查询应用延迟情况的时候，发现一直存在延迟。发现是read only状态，而没有WITH APPLY。2、因此重新起动apply日志应用。1、在备库查看其日志应用情况。

备份参数文件 create pfile='/home/oracle/pfile.ora' from spfile;备份控制文件 Alter database backup controlfile to trace;3、操作系统层面kill掉所有LOCAL=NO的所有进程。2、关闭两节点的监听；6、等待5-10分钟。

原因是由于静默安装，但是系统中设置了DISPLAY环境变量，更改方法。然后再执行runInstaller.sh，执行成功！1、编辑响应文件db_install.rsp。中间需要使用root执行两个shell文件。出现如下提示则表示安装成功。3、取消display。4、创建用户交付使用。

rac环境使用的是ASM共享存储，而有些新手不小心加成了本地磁盘，为解决这个问题，做了如下尝试。rac的一个节点在加数据文件的时候，加到了本地文件。

Oracle数据库逻辑结构从小至大依次由块(block)、区(extent)、段(segment)、表空间(tablespace)、数据库(database)构成。undo表空间下，每个段区的数量最大为32765，当有大事务出现时，会产生大量的undo，导致回滚段区的数量超出最大限制，产生ORA-01628报错。如下图，数据库版本是12.2。查询段下区数超数undo表空间及相应的段名，此处检测阈值为25600。查看undo空间和并行均未发现异常，在不使用并行的情况下依然如此。

3、到/dev/disk/by-id路径，查看uid号，一般是scsi开头的。1、主机存储组划分好资源，使用upRescan扫描（2个节点）后加载到主机。2、使用upadmin show vlun查看磁盘。只有CANDIDATE状态的可以添加。5、使用以下命令重新加载udev。4、编写udev别名和权限文件。

6、当前空间看并没有不足，进一步查看删除未释放的空间，发现异常，存在大量删除未释放的文件，至此问题原因已明确，由于在删除文件的时候，进程占用，导致空间未能释放，从而引起空间不足。2、查看sga和pga分配的内存分别是：140g和40g。【告警内容】当前内存使用率为98.9%，超警戒值90%4、查看内存排行榜，top M ohas.d占用率最高。5、根据alert的报错日志查看空间使用率77%【全景监控：Oracle主机内存使用监控】1、清理一些必要的无用日志释放空间。2、重启集群，释放被占用的内存。