索引在我们日常维护数据库的性能中占用非常大的比例,如何维护好你的索引很大程度上关系着数据库的性能,当然了索引只是性能调整中数据model的一部分,本文只是大头根据对索引的理解结合脚本来浅浅的对b-tree索引的变化做一个描述,权当饭后谈资,有错误和需要弥补的地方还要靠大家指正.
b-tree索引是啥我就不解释了,不懂的朋友参考oracle concept或者摸下度娘.很多dba都知道,维护索引无外乎如下几种情况：
1.索引有没有
2.索引设计合不合理
3.索引碎片太多了
4.索引过大了，虚胖
5.索引聚簇因不同步
郁闷碰到故障了··rac disgroup 起不来~先去trouble shooting了.
后续补上.
跨平台的oracle迁移对于企业在目前来讲是比较少碰到的.碰到跨平台项目一般都是碰到数据整合,或者项目升级的情况.这里我以个人的角度浅浅的描述下oracle跨平台迁移涉及到的一些技术以及解决方案,顺便附上关于这方面的资料,只作个人的闲余消遣,更多的是我把我某一个项目中关于oracle迁移的经验思路理出来作分享
Oracle跨平台迁移一般使用手段便是如下所列的几种：
1.使用export工具，包括Datapump，对于Datapump，要求数据库为10.1.0.2以上版本
2.10G 或更高版本可使用 Transportable Tablespaces（TTS）。
3.10G 或更高版本可使用 RMAN Convert Database 功能。
4.Streams 流复制。
5.Create Table As Select (CTAS)
6.Dataguard 基于异构平台的物理主备库。
7.Oracle Golden Gate
每种办法都会有其优势和局限，包括数据类型、所需时间和潜在成本，我列举一个我迁移项目的例子：
(如要转载请标注原创）.
首先平台环境,原始环境平台：
oracle 10203 aix 5203
目标环境平台：
oracle rac 11.2.0.3.8 OElinux 6.1 aix 5203
这是我一个金融行业用户的核心生产要升级的项目,从Ibm的aix平台迁移到linux 平台,单机变双机,数据库版本也横跨了大版本.那么在项目初期,客户的期望就是我要迁过去,这样硬件升级还能有双活节点,有高可用做保障,对于DBA怎么迁移,他可不管,也不会问到非常细的环节(每个客户都是不一样的).那么作为乙方,我认为在处理这样的项目的时候,从接手开始就应该尽量的把你专业的一方面表现出来,尽可能的考虑到各种情况.这个升级项目涉及到的方方面面,在这个项目中我通常首先要了解的是时间窗口、整个DB的数据量,在我这项目中一开始我得到的信息为时间窗口是24小时,数据量是600多g.哟呵,有点儿意思,时间很充足,数据量马马虎虎,在这个行业里算大了,眼看就要想要用什么技术来迁移了.其实还早,时间窗口是用户确定了足信,至于数据量更多时候我一定会到数据库里再确定一次,那么怎么确定正确的数据量?确定数据量的办法挺多,肯定会有人说看dba_data_files的总和减去dba_free_space，剩下的就是实际数据量了，没准还会有更可爱的说看tablespace占了多少.哎呀其实都没错，在一些特定的技术环节下是要看这些，但是这里我想补充2个信息，就是从exp或者datapump的导出dump文件大小以及用rman做备份后的实际的备份集考虑.这只是在选择迁移技术前的信息判断而已,这些信息是越多越好,我最终选择的技术还是使用expdp，没有选择tts或者是dg.
那么为啥呢？别急容我慢慢述来.
1.数据量实际大小为290G,这与用户的描述有出入,经过了解是因为客户是通过sql语句来计算容量的，而实际上客户经常对一些历史表做delete的清理，并未做空间的回收操作，这样就会有大量的空间实际上是没有数据但是确占用着表空间容量的.得出这个数据后我逐测试了下exp和expdp的在生产系统空闲时间段的导出时间,expdp导出大小为270左右,开8个并行耗时80–120分钟.
2.在搭建好的linux平台（未来的核心平台）上测试导入时间，采取并行,索引分离,扩大PGA，分用户（应用用户相对独立）双节点导入等手段,最终在导入时间可以控制在80分钟以内.
那大头为什么不用tts或者dg,ogg,stream呢？
.
1.tts虽然我用的次数挺多,这里不用是因为用户表空间建的较大,整体加起来接近2t,表空间众多,操作繁冗.
2.虽然dg支持aix和linux的异构同步,但是这里对停机时间要求没有很严格，而且如果用dg一开始就要对生产系统停机维护,还需要规避bug.最重要的是,大头对这个技术虽然做过测试,但是经验不足，我不能保证会没有问题.我肯定会选择我可控的胸由成竹的技术.
3.ogg很美好，但是转眼想下，做ogg有必要么？初始化过程就相当于一次迁移了.又不需要无缝停机,即使真的无缝停机,ogg也不大可能会满足要求的,因为注定要经过一翻波折之后ogg才会这服在你额运维手段之下.
4.stream,快要淘的技术了,转眼像在ogg上复活了,ogg我都拒绝了,流再见吧.
理解了大头的用心良苦了么？汇总下上面的信息
项目起始选择迁移方式无外乎要注意几个重点：
1.尽可能多的收集和迁移相关的信息,而且要亲自去确认排除可能的情况
2.如果有测试数据支持,那么方案将更加有说服力
3.尽可能去结合项目的场景要求选择自己熟悉的适合技术,不要为项目,为自己,为技术团队添加意外的风险
4.如果遭遇客户的追问,123就是你的答复.
其实这个项目在使用datapump过程也对工程师的技术要求较高,虽然本身datapump的技术并不复杂,但是需要考虑的方面很多,我总结如下：
1.dblink，无论是出去的，还是进来的dblink都需要做一遍梳理.11.2.0.2之后重建dblink可以使用转换过的密码直接重建哦！
2.函数，同义词与dblink的依赖需要格外关注
3.物化视图迁移到11g后是一起迁移的，需要关注迁移后的物化视图是否为正常状态
4.导出的dump文件传输到目标库的时间是要计算到整个迁移时间的
5.统计信息最好不要一起迁移
6.如果导入过程碰到约束错误不要慌，报错的表可以在后续重新导入
7.在导入完成后需要验证每个用户下的对象信息是否与原库相符,最好有类似veridata软件对比原库和目标库行数信息的工具来支撑，否则就需要应用来做验证数据迁移的完整性
8.迁移的回退工作,万一遭遇datapump的bug,如何快速恢复初始环境？最好是在导入之前做一份目标库的rman全备份.
9.记得把temp表空间设大,把pga调大,把DB的归档关闭.
有不足的地方大家继续补充~欢迎大家斧正.
以上这就是一个最基本的迁移工作要注意的环节，以及datapump的使用注意事项.其他跨平台迁移方式相关资料大家可以参考如下，
luadtou
Note.556636.1 Oracle Server – Export Data Pump and Import DataPump FAQ
Note.351598.1 Export/Import DataPump The Minimum Requirements to Use Export DataPump and Import DataPump (System Privileges)
Note.243304.1 10g : Transportable Tablespaces Across Different Platforms
Note:371556.1 How move tablespaces across platforms using Transportable Tablespaces with RMAN
Note: 413484.1 Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration
NOTE:1401921.1 – Cross-Platform Database Migration (across same endian) using RMAN Transportable Database
NOTE:62290.1 – Changing between 32-bit and 64-bit Word Sizes
前一个刚经历rac安装完后遭遇的ORA-12545错误，这里就顺便把这个错误的诊断思路理出来，毕竟这个错误在10g后还是比较常见，本文只是对这个故障的处理诊断思路做一些经验上的讨论，纯为有趣。
12545的报错提示为如下：
ORA-12545 / TNS-12545 Connect failed because target host or object does not exist
先往下聊吧，这类错误通常是和hostname相关配置不正确有关，举个例子
[ora10g@ludatou ~]$ tnsping lu10g TNS Ping Utility for Linux: Version 10.2.0.4.0 - Production on 15-APR-2014 12:08:27 Copyright (c) 1997, 2007, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ludatou)(PORT = 1523)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = lu10g))) OK (10 msec) [ora10g@ludatou ~]$ sqlplus luda/luda@lu10g SQL*Plus: Release 10.2.0.4.0 - Production on Tue Apr 15 12:12:15 2014 Copyright (c) 1982, 2007, Oracle. All Rights Reserved. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production With the Partitioning, OLAP, Data Mining and Real Application Testing options =====这里我的tnsnames配置的解析主机名是ludatou，而且采用网络验证方式登录成功 [ora10g@ludatou ~]$ cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.102.128 ludatou luda =====在这边我把/etc/hosts文件的主机名ludatou变更为ludatouxx,变更结果如下 [ora10g@ludatou ~]$ cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost 192.168.102.128 ludatouxx luda
再次在客户端（另外一个主机）远程登录，在响应了很久之后报错
[root@ludatou ~]# su - oracle [oracle@ludatou ~]$ sqlplus luda/luda@lu10g SQL*Plus: Release 11.1.0.7.0 - Production on Tue Apr 15 12:13:40 2014 Copyright (c) 1982, 2008, Oracle. All rights reserved. ERROR: ORA-12545 Connect failed because target host or object does not exist
下来以分类场景的方式来描述这类故障的诊断：
场景1：
当连接数据库不通过listener的时候，而是使用BEQ协议来连接数据库，这个时候如果$ORACLE_HOME/bin目录下oracle文件丢失或者损坏，用户执行权限不足，以及Oracle_home（多个安装版本）的路径设置错误的情况下，使用beq协议连接oracle的用户就会遭遇ORA/TNS-12545的错误。
关于BEQ协议可以参考如下解释：
This is the bequeth oracle process. The bequeth process starts first. Later all the processes related to particular database are controlled by its bequeth process.
场景2：
这个场景就是上面我所做的测试场景，由客户端通过listner连接服务端oracle数据库，这个时候如果客户端的tnsnames解析文件中对应service name部分的hostname和服务端的hostname不匹配，就会报错ora-12545.
在这个场景中可以使用nslookup命令来搜索对应的主机，按照上面的例子，这里使用nslookup命令搜索ludatou主机时候则会出现以下情况：
$ nslookup ludatou Server: 192.168.102.128 Address: 192.168.1.102#53 ** server can't find ludatou: ==>Indicates ludatou is not resolvable on the machine
这个场景的解决办法就是把客户端的tnsnames中的hostname部分写为ip，避免服务端主机名变更导致配置不符的情况出现。
场景3：
参考 RAC实施完遭遇ORA-12545
Cause: One of the hostname (which corresponds to public IP or VIP) is not reachable from this client machine. When the server side load balancing is enabled in the RAC setup, the listener will redirect the connection to the least loaded node.While doing so, the server sends the packet NSPTRD containing the hostname of the corresponding machine. The Remote Service Handler value registered with the remote Listener process via the REMOTE_LISTENER parameter is built by the LOCAL_LISTENER value on the local server.So, its necessary to check whether the local_listener / remote listener information are reflected properly in the listener services output as well. Diagnosis: Enable the oracle sqlnet client tracing at support level, and reproduce the issue.In the generated client trace, you would see the below information: After NSPTCN Connect to the listener , listener sends
场景4：
listerner.ora的hostname配置错误，导致监听无法找寻到正确的监听地址，也会产生ora/tns-12545的错误。具体监听日志报错如下：
Error listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=abc)(PORT=1522))) TNS-12545: Connect failed because target host or object does not exist TNS-12560: TNS:protocol adapter error TNS-00515: Connect failed because target host or object does not exist
如果打开了sqlnet的trace跟踪，可以发现类似如下的报错：
nsc2addr: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=abc)(PORT=1522))) nttbnd2addr: entry snlinGetAddrInfo: entry snlinGetAddrInfo: Invalid IP address string abc snlinFreeAddrInfo: entry snlinFreeAddrInfo: exit snlinGetAddrInfo: exit nttbnd2addr: looking up IP addr for host: abc snlinGetAddrInfo: entry snlinGetAddrInfo: Name resolution failed for abc snlinFreeAddrInfo: entry snlinFreeAddrInfo: exit snlinGetAddrInfo: exit nttbnd2addr: *** hostname lookup failure! *** nttbnd2addr: exit nserror: entry nserror: nsres: id=0, op=78, ns=12545, ns2=12560; nt[0]=515, nt[1]=0, nt[2]=0; ora[0]=0, ora[1]=0, ora[2]=0
这类问题解决办法就是检测监听的配置是否和主机的ip，hostname配置吻合，不吻合的情况下会造成12545的错误。
场景5：
操作系统或者硬件问题也会导致产生ora/tns-12545的产生。
5.1windows 2000 with Service Pack 3 会导致这个ora/tns-12545 的产生
http://support.microsoft.com/default.aspx?scid=kb;en-us;329405
5.2Solaris系统在配置不正确情况下也会导致ora/tns-12545的产生
以上的场景描述是对1254错误的故障做一些分类分析，大概的诊断思路也是这样。
当然以上只是针对12545，oracle网络的错误有很多，对于诊断oracle网络错误，我个人的习惯诊断流程是如下
1.check listener.log确认是否有报错信息
2.check syslog是否有设备或者系统的报错信息
3.check $ORACLE_HOME/bin/oracle文件是否存在以及权限正确与否
4.check tnsnames,sqlnet,listener的配置是否与主机对应
5.在rac环境下，我会优先检查节点和client的通信情况，网络配置文件是否配置正确，最后才是taf和ld的影响
6.必要时候开启trace进一步跟踪详细信息
最近临时接手一个ogg的项目，前面的兄弟没处理好，算是临危而上了。当时是这种情况，ogg的初始化完成了，但是发现复制进程的延时有100多个小时，而且越积越多，但是进程还是在正常允许没有hang住，根据这个情况根据数据库和ogg的角度提出和执行了一些优化上的处理事宜，具体如下：
首先延时是一个相对的代表当前数据同步处理情况，相对主库运行时间段的一种判断，也是OGG提供给我们当前进行的工作进度展示，影响Goldnenate进程lag的因素有哪些？
具体我统计如下：
1.OGG bug，不能正常显示lag信息，由于时区设置不正确，或者本身程序等造成
2.OGG 源端抽取进程延时大，这个时候主要是取决与当前主机CPU,IO，在硬件（上述任1）资源达到超负荷时候，对抽取进程的处理就会挂起乃至延时，造成lag过大或者是显示不正确，或者是抽取开始的scn距离当前的主库scn有时间的差距。
3.OGG 源端传送进程延时大，这个时候主要是取决于主机的CPU,IO,NETWORK，在除了与2中的硬件资源有关之外，还跟OGG传送的网卡，生产到目的端网络情况（包括网络通信长度，网络繁忙度， 网络有效负荷等），生产与目的端防火墙对发送包的限制情况。
举些例子，如果你的日志量很大，但是你的网卡为百M网卡，你传送需求是20M/s，传送速率只有理论的10/S，这时候延时显而易见就出来了，你每秒就有10m的延时，相当于1s就积累1s的延时。
比如传输长度，光纤输出平均1公里增加延时1ms，这个时候比如吉林长春到北京亦庄的光纤是经过了1000公里，那么这里1000*0.001=1s，这是理论的情况下最小的延时。
再接着是防火墙，还有无线网络的考虑情况，这些跟网络传输环境息息相关的方面都需要考虑进去。
4.OGG 目标端lag很大，跟目标端的cpu，io有关，这个时候目标端的cpu压力主要来自于3方面：系统运行，数据库运行，OGG运行；IO压力主要来自于OGG以及数据库的日志写和读，那么repliact进程延时大了主要是什么情况？
4.1.io不够，cpu够，你数据库有能力1秒能写200M数据，但是你存储io只能写100M，这个时候就积累延时了
4.2.io够了，cpu不够，这个时候你也会发现有延时，因为你处理速度远远低于源端传过来的数据的速度，这个时候延时也就积累了
4.3.io够了，cpu够了，这个时候你硬件很ok，但是你的延时很大，这个就是进程积累的日志过多；
数据库性能问题，OGG性能问题就和看病一样，需要对症下药，如果诊断错了，你开的药就错了，出现的结果就是病没治好，有可能身体本身器官负载还更大了.在这个项目中的情况，和我上述描述的症状对比起来，在多次诊断中，我比较倾向4.1，4.2，4.3的综合类型，就是目标端replicat应用日志的速度无法追上（4.1，4.2），而且在初始化完成后本身在目标端积累了过多的日志（4.3）。
那又怎么处理？对症下药。优化资源使用，提高数据库的处理速度是我们要做的事情。那么怎么处理？根据情况可以考虑下面的2种方式来做
一：提高目标端Oracle处理速度
1.关闭备库的日志补全级别，关闭备库的强制日志模式，减少redo产生，降低io。
2.置备库为noarchive（非归档模式），减少archive过程产生的io。
3.提高备库服务器的内存大小，为Oracle设置更大的buffer cache，shared pool，减少VMM控制的整体的换页频率所带来的对cpu和io的额外负荷。
4.确认异步IO是否开启。未开启的过程请打开服务器的aio，aix确认如下lsdev -Cc aio
5.提高PGA的大小，为多个的repliacat进程们提供足够的缓存区域。
6.对目标端ogg的接收源端发来的data文件 和 oracle本身的数据文件错开到不同的（存储级别）vg上面，以避免disk hot的情况出现，进而提高io效率
7.对无查询，存插入更新（全表）的对象的索引进行删除
二：从业务逻辑上拆分繁忙的延时大复制进程
角度1：工作量最小，但是统计会有一定误差
在局部进程延时大的时候，可能是这种情况，业务处理的核心压力都集中在一些对象上面，而这些对象都被安排设置到一个进程中，这个时候大部分的日志都集中在这个进程中，出现了这个进程很忙，其他进程很闲，类似多点闲单点热的情况，如果这个时候硬件资源满足情况下，可以从业务逻辑上去拆分这个进程，比如这次宋经理根据应用开发商的提供的表的更改频率表按照等级来拆分进程，按照表的繁忙度把热点表们平摊到2个进程中。而周五我的建议是全部平摊出去，这样效果才会明显，而根据文档显示宋经理已经按照应用商提供的将热点表全部平摊到各个进程中。
在这方面，我方从数据库角度提出建议，应用从业务角度划分出来的表可以从数据库对应DML操作的频率记录上进行check对应。因为存在一种情况，应用提供商提供的是表的操作频率，比如查询，更新，插入，删除都是在一起统计的，从细化上我们需要的表的更新，插入，删除方面的统计信息，这类信息可以通过oracle 实例中的ALL_TAB_MODIFICATIONS表进程查询数据库中所有对象的delete，insert，update的频率，根据频率高的进行排序，再对频率高的前100，或者200的表进行拆分，这样的效果可能会更理想，具体语句如下：
select TABLE_OWNER,TABLE_NAME,INSERTS,UPDATES,DELETES from ALL_TAB_MODIFICATIONS ORDER BY 3,4,5;
或者
select TABLE_OWNER,TABLE_NAME，INSERTS+UPDATES+DELETES "ALL_DML_COUNTS" from ALL_TAB_MODIFICATIONS ORDER BY 3;
角度2：工作量较大，但是统计效果精准
表的DML频率并无法估算到具体产生的redo量，理论上redo的产生量越大，对应的操作涉及的数据（比如表的字段多，数据量大）就越多，所以从这个角度上讲，我们是要找到redo量产生多的那些表，这种情况下就需要用到logmnr工作，通过对归档日志的挖掘分析，开对ogg的部署进行决策支持，在当前项目，这个角度比较不倾向实际，但是可以作为一个参考方向。
一直都要把redo，undo在recovery中是怎么协调作用的东西写下来，一直都往后推拖，到了现在稍微有了点时间，也就顺便把这一系列的东西做了一个整理.
我这些文章中对log的dump操作请参考文章
How to Dump Redo Log File Information
大概会有3个大系列，分为如下部分：
1.谈谈redo
1.1.谈谈redo以及Imu的理解
1.2.什么是redo Records
1.3.理解redo log file header,redo block header and redo record header
1.4.什么是change vectors
1.5.理解Row and Index Operations
1.6.理解Direct Loads以及Nologging 在redo中的展现
1.7.理解审计与Redo之间的关系
1.8.理解附加日志内幕
（www.ludatou.com)
2：谈谈undo机制
2.1.理解undo的作用
2.2.理解事务与undo的关系
2.3.理解XID
2.4.理解UBA
2.5.理解UNDO CHAIN实现机制
2.6.理解延迟块清除
2.7.关于ora-01555的处理
（www.ludatou.com)
3.谈谈检查点机制
3.1.
4.谈谈控制文件
4.1理解控制文件的作用
4.2理解bootstrap
5.谈谈恢复原理以及特殊恢复技术
5.1.概念：实例恢复，介质恢复，崩溃恢复的概念
13.深入理解recovery的实现机制：Page Fix、写日志优先、Checkpoint
（www.ludatou.com)
5.1.1无法启动故障根本原因的定位案例
5.2.ora 00600 [2662]处理
5.3.ora 00600 [4097]一例
5.4.ora 00600 [4193]处理
—-BBED处理
5.5.数据文件头损坏恢复
5.6.控制文件损坏恢复
5.7.系统表空间损坏恢复
