BUFFER CACHE作为数据块的缓冲区，不是一块简单的内存区域。在这一块内存区域上，Oracle设计了很多LATCH来保护BUFFER CACHE的结构不受并发性访问的破坏，当LATCH数量不够用或并发访问模式不兼容时，将会引起LATCH的争用，这就是我们经常看到的LATCH FREE等待事件。从BUFFER CACHE中读取数据块一般需要花费100ns左右，假设每次只读取一个数据块，也就是每秒可以读取10 000 000个数据块。而从磁盘读取数据块一般需要花费10ms左右（包括寻址定位时间和传输时间），也就是说每秒只能读取100个数据块。从这个角度来讲，数据块从内存中读取的效率要比从磁盘中读取高100 000倍，但并不是说数据块从BUFFER CACHE中读取一定比从磁盘中读取好，即BUFFER CACHE的命中率并不是越高越好。BUFFER CACHE作为Oracle 数据块的缓冲区，不同的系统类型和业务模块对其命中率的敏感程度会有所不同。比如OLTP系统并发高、事务小、响应快、SQL执行时读取的数据块数量较少，因此，在此系统上比较高的BUFFER CACHE命中率不仅能加快数据块的读取时间，而且能有效缓解存储的I/O压力。而OLAP系统并发低，事务大，SQL执行时读取的数据块数量较多， 所以在这类系统中，BUFFER CACHE命中率的高低却不是特别重要，而且在此类系统中 ...继续阅读 (10)

Oracle管理云服务（OMC）的大数据平台，自动收集的企业IT操作数据，幻化出了以下七种武器，利用端到端的可视化更有效地监控所有类型的IT系统、应用和服务，加速问题解决，并使各业务部门的IT分析员能更容易地监控企业业务信息： 武器1、应用性能监控（Application Performance Monitoring）能够快速隔离应用程序的问题。此服务集成了用户体验信息、应用指标，以及相关的日志分析，可以从一个页面快速隔离、分类、诊断问题根源——甚至可以在用户察觉之前就解决它！ 武器2、IT基础设施监控（Infrastructure Monitoring）统一地、主动地监控IT基础设施的状态和健康，能够从一个平台监控包括本地和公有云上的整个IT基础设施。主动地跨层地监控功能能够及时提醒管理员,在影响最终用户之前排除和解决IT问题。 武器3、日志分析（Log Analytics）实时洞察来自于大量不同应用或设备（包括移动、大机等）的机器数据，利用机器学习能力快速搜索、分析“十亿条” 量级的日志，可以组合、分析跨越本地和公有云上的日志，包括 Oracle 和非 Oracle 提供的日志。 武器4、编排云服务（Orchestration）自动计划、执行和分析报告hyper-scale云任务。Oracle管理云的安全、统一的大数据平台可以调用REST、脚本、或第三方自动化框 ...继续阅读 (4)

2019年7月22日，受邀参加Oracle勒索病毒防范专题培训会议，做了1个半小时的演讲。会议现场见附件。已有0人发表留言，猛击->>这里<<-参与讨论ITeye推荐—软件人才免语言低担保 赴美带薪读研！— ...继续阅读 (7)

某客户数据库从P595物理迁移至P780新服务器并更换存储之后，发现应用性能反而下降。P780配置了32颗4核CPU（主频为3920 MHz），710G内存。如下所示：System Model: IBM,9179-MHCMachine Serial Number: 06DA0CRProcessor Type: PowerPC_POWER7Processor Implementation Mode: POWER 7Processor Version: PV_7_CompatNumber Of Processors: 32Processor Clock Speed: 3920 MHzCPU Type: 64-bitKernel Type: 64-bitLPAR Info: 1 SN06DA0CRMemory Size: 727040 MBGood Memory Size: 727040 MBPlatform Firmware level: AM740_088Firmware Version: IBM,AM740_088Console Login: enableAuto Restart: trueFull Core: falseP595配置了32颗双线程CPU（主频为2302 MHz），186G内存。如下所示：System Model: IBM,9119-595Machine Seria ...继续阅读 (8)

性能优化最难的是能够在海量信息中找到优化的方向，抓住要点。当找到优化方向后，采用的优化技术往往非常简单，甚至不起眼。进行性能优化时，不在于你掌握了多少种技术，使用了多少种工具，而在于找到一种适合自己的实用的方法。比如查看SQL的执行计划有很多种方法，但我们不需要掌握每种方法，通常只需要掌握其中一到两种自己最擅长的方法即可。以下为笔者的性能问题处理流程，供读者参考：（1）制定一个简单可行的沟通机制，了解系统的变更情况。（2）不要让系统意外宕机。（3）明确优化目标，切忌无止境的优化。（4）不要一个人战斗，了解你能够获得的其他支持力量。（5）部署性能监控工具（如OSW），记录下当前主机资源的使用情况。（6）查看V$SESSION_WAIT视图，获取STATSPACK/AWR报告。（7）快速分析，制定优化方案和实施计划。（8）定位故障。（9）再次沟通，审核优化方案和实施计划。（10）实施优化方案，做好回退机制。（11）优化效果评估，如果没有达到预期，则重复6~10步骤。（12）记录下这个成功案例，做到举一反三。“尽信书，不如无书”。我们需灵活运用以上各种优化手段，切忌照搬照抄。优化完成之后，再针对优化成果建立新的数据库的性能基线。注意上述优化步骤并不是简单地串行化操作，而是一个相互迭代，循序渐进的过程。某些调整可能会产生意外的性能结果，如果在调整之前保存了以前的设置，那么回退不正确的调整就 ...继续阅读 (5)

从数据库性能优化的场景来区分，可以将性能优化分为如下三种形式：从来没达到过性能要求的数据库优化。该类故障一般出现在压力测试或者业务系统刚上线时，可能需要通过修改应用架构，大规模优化SQL语句来进行改进，此类优化难度最大，耗时也最长。量变引起质变的数据库优化。该类故障通常是由数据库并发加大，数据量增多引起的，优化难度一般，但代价可能较高。在国内，很多客户都是通过增加硬件投入来解决该类性能问题的。突发性的数据库性能故障优化。该类故障优化的难度最低，但时间紧迫性更强，需要DBA能够快速解决问题。从数据库性能优化的时间点来分，又分以下2点：事前优化，指的是业务系统上线前的优化。在事前优化过程中，系统设计、开发、产品优化、平台优化的全过程都很重要。实践经验表明，事前优化对于系统的平稳运行有着根本性的影响，而且优化代价也最低。事后优化，指的是业务系统上线后的优化。由于事后优化受到宕机时间、代码版本控制、代码内核不容易更改等因素影响，所以事后优化往往只能缓减系统性能下降的症状，治标不治本。系统上线之后，如果爆发出大规模的性能问题，那通常都会是灾难性的，任何容灾在这时都起不了作用。数据库性能优化并没有统一的标准步骤，“不管黑猫白猫，捉到老鼠就是好猫”，这句话在性能优化领域也同样适用。一个性能优化项目的目标如下：增大数据库吞吐量。如通过数据库优化增加每秒执行的事务数。高效利用服务器硬件 ...继续阅读 (5)

数据库的启动是一个相当复杂的过程。比如，Oracle在启动之前首先需要进行主机环境的校验，之后在启动过程中还需要进行内部一致性校验，另外，在此过程中，服务进程还需要进行一系列初始化工作，如SGA的初始化、数据字典的初始化等。看似挺复杂，实际上在正常情况下，启动数据库就像开启家电一样既简单又轻松——DBA通常只要执行一条简单的STARTUP命令就能启动数据库，数据库内部校验操作由后台进程自行处理，对DBA保持透明。但是在某些时候，启动数据库又会变得不是那么容易，比如，在出现数据文件意外损坏，碰到Oracle bug等情况时。但是，在很多行业中，如果关键业务意外中止或者关键业务数据丢失通常都是不可接受的，所以数据库的启动恢复是一个合格DBA的必备技能之一，也是数据库灾难挽救的最重要课程。在没有灾备的情况下，DBA常会是所有环节中的最后一道保障。如果数据库无法及时正常打开并对外提供服务，其后果往往是致命的。在高度紧张的氛围中，DBA除了需要良好的心理素质之外还必须具备扎实的理论功底和丰富的故障解决经验来处理这种突发情况。附件通过思维导图式地总结了数据库无法打开的各种原因，供大家参考已有0人发表留言，猛击->>这里<<-参与讨论ITeye推荐—软件人才免语言低担保 赴美带薪读研！— ...继续阅读 (9)

Oracle提供了drop database命令用来删除数据库，代码如下所示：SQL> startup mount ORACLE instance started. Total System Global Area 264241152 bytes Fixed Size 2095536 bytes Variable Size 83887696 bytes Database Buffers 171966464 bytes Redo Buffers 6291456 bytes Database mounted. SQL> alter system enable restricted session; System altered. SQL> drop database; ...继续阅读 (8)

LGWR进程将LOG BUFFER中的日志条目写往在线日志的条件有如下三个： 事务提交时。 LOG BUFFER中的日志条目超过1MB时。 每隔3秒时。除此之外，Oracle还通过隐含参数_log_io_size来进一步控制LGWR进程写日志条目，当LOG BUFFER中的日志量超过该参数值时，LGWR进程会被自动激活写日志。该参数值默认为0，表示LOG BUFFER容量的1/3，其单位是REDO LOG BLOCK。如下所示：NAME VALUE PDESC------------------------------ ---------- --------------------------------------------------_log_io_size 0 automatically initiate log write if this many redoLGWR进程性能的下降直接关系到整个系统的性能，所以减少重做日志量可以从某种程度上减轻系统的压力，以下为常见的减少日志量的方法： 使用NOLOGGING选项。NOLOGGING有三个级别，分别是SQL级别、表级别、表空间级别。 通过SQL*LOADER装载大量数据时，使用DIRECT LOAD ...继续阅读 (10)

“一朝被蛇咬，十年怕井绳”。在没被“蛇”咬之前，很多DBA喜欢使用SHUTDOWN ABORT方式来关闭数据库。因为这种方式是最快速的关闭方法，但用此方式关闭数据库会使数据库处于不一致状态，极端的情况下甚至会损坏数据库，导致数据库无法启动。所以推荐使用SHUTDOWN IMMEDIATE方式来安全稳妥地关闭数据库。5.9.1 影响数据库关闭速度的因素当数据库以SHUTDOWN IMMEDIATE方式关闭时，Oracle会自动断开所有的客户端连接，并回滚所有未提交的事务，回滚完成之后还会将所有的脏块从BUFFER CACHE写进数据文件，所以以此方式关闭数据库，数据库内部会处于一致状态。这也就意味着再次启动数据库时，服务进程并不需要CRASH RECOVERY。这种方式是目前最常用的关闭方式，但是关闭速度较慢。数据库关闭速度受以下4个因素影响： 连接的客户端进程数量。 未提交的事务占用的UNDO BLOCK数量。 长时间运行的会话。 SMON进程清理临时段的速度。1. 连接的客户端进程数量 数据库关闭之前，需要清理连接的客户端会话。连接的客户端数量越多，那么SHUTDOWN IMMEDIATE关闭数据库时需要断开的会话就越多，消耗时间也就越长，如下所示：Sun Jul 15 02:43:33 CDT 2012Job queue slave processes stopp ...继续阅读 (13)

操作系统：RHEL6.5数据库版本：11.2.0.4我在安装could control软件的时候修改了数据库的部分参数，其中就有memory_target的值。然后数据库就起不来了SQL> startup;ORA-00838: Specified value of MEMORY_TARGET is too small, needs to be at least 3072MORA-01078: failure in processing system parameters报错原因是MEMORY_TARGET的值太小，至少需要3072M修改MEMORY_TARGET的值在数据库里面已经不可操作所以我在参数文件里修改首先生成pfileSQL>create pfile from pfile;[oracle@hzmcorcl dbs]$ vi /oracle/app/product/11.2.0/db_1/dbs/initorcl.ora修改memory_target的值：*.memory_target=3221225472然后使用pfile启动试试：SQL> startup pfile='/oracle/app/product/11.2.0/db_1/dbs/initorcl.ora';ORA-00845: MEMORY_TARGET not supported on this syste ...继续阅读 (18)

11g rac安装在二节点跑脚本一般会报此错误：解决这个问题，需要三个步骤来完成：1、在每个节点上，修改$CRS_HOME/bin目录下的srvctl和vipca文件编辑vipca文件，找到如下内容：Remove this workaround when the bug 3937317 is fixedarch=`uname -m`if [ "$arch" = "i686" -o "$arch" = "ia64" ]then LD_ASSUME_KERNEL=2.4.19export LD_ASSUME_KERNELfi#End workaround #在fi 后新添加一行：unset LD_ASSUME_KERNEL然后编辑srvctl文件，找到如下内容：LD_ASSUME_KERNEL=2.4.19export LD_ASSUME_KERNEL #同样在其后新增加一行：unset LD_ASSUME_KERNEL2、使用$CRS_HOME/bin目录下的oifcfg工具配置pub ip和pri ip3、在任意一个节点上，用root用户，手动运行vipca，配置完正确的prvip和vip 信息之后，crs就可以安装完成已有0人发表留言，猛击->>这里<<-参与讨论ITeye推荐—软件人才免语言低担保 赴美带薪读研！— ...继续阅读 (20)

故障简述XXX第八人民医院HIS数据库7月13日11点左右从原先老服务器切换至新服务器，切换完成之后，数据库版本主机操作系统版本都保持不变。运行20天左右，从8月4日开始，前台操作人员反应业务程序响应出现延迟，此后延迟逐渐增大。8月5日科技工程师远程经过仔细诊断后发现存在大量磁盘读，采取增大SGA数据库内存的方式来减少磁盘读。但调整之后即第二天8月6日上午应用几乎瘫痪无法操作，后台数据库却很空闲。重启数据库业务程序卡顿消失，但过了十几二十分钟之后现象又产生，排除了网络和业务程序自身的故障后，考虑到事故的紧急性采取重启数据库临时解决问题。8月6日下午工程师到达现场仔细排查之后确认是由于连接方式所导致的故障，调整部分参数之后恢复正常，增大SGA后业务程序响应速度明显加快，部分报表查询甚至提升了十几倍。相关知识点前端应用连接数据库的方式分为两种：独占模式和共享模式。独占模式又称专有模式，一个客户端连接对应一个服务器进程，一对一的处理方式。而共享模式则是多个客户端进程对应一个服务器进程，服务器端存在一个进程调度器来管理。下面具体对共享模式的工作原理做简要分析：共享模式主要分为6个步骤(如图1-1)：1.用户发起连接请求2.监听监测到请求返回调度进程地址，此时用户进程与空闲调度进程直接连接3.用户发起操作请求(如dml)，调度进程负责把请求放入请求队列中4.空闲的共享服务进程从请求队列中接过 ...继续阅读 (13)

由于数据库上线过程中出现大量的RESMGR:cpu quantum等待事件，出现性能问题，关闭了resource manager功能，关闭过程如下：ALTER SYSTEM SET “_resource_manager_always_on”=FALSE SCOPE=SPFILE SID='*'; execute dbms_scheduler.set_attribute('SATURDAY_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('SUNDAY_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('MONDAY_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('TUESDAY_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('WEDNESDAY_WINDOW','RESOURCE_PLAN',''); execute dbms_scheduler.set_attribute('THURSDAY_WINDOW','RESOURC ...继续阅读 (19)

数据库中的log file sync等待事件指的是，当user session 提交（commit）时，user session会通知LGWR进程将redo buffer中的信息写入到redo log file，当LGWR进程完成写操作后，LGWR进程再post（通知）user session 写操作已经完成，user session 接收到LGWR的通知后提交操作才完成。因此user session 在没有收到LGWR post（通知）之前一致处于等待状态，具体的等待事件为log file sync。根据实践经验，引起log file sync等待事件的原因有以下几种： 事务过度的提交，即应用程序过度commit或者rollback。 存储I/O资源紧张，导致lgwr进程写速度缓慢。 CPU资源紧张，lgwr进程获得不了响应的CPU时间片。 RAC节点之间SCN同步。 RAC节点之间CR块传递。 控制文件争用。不同的原因，其解决方法会不同，当多种原因混合在一起时，则需要进行综合考虑。事务过度提交事务过度提交是引起log file sync等待事件的主要原因之一。前面提到，默认情况下，当事务提交时，LGWR进程会将事务相关的日志条目立即写至redolog中，直到日志写成功之后才显示提交成功。所以事务提交越频繁，触发LGWR进程写操作越频繁，引起log file sync ...继续阅读 (22)

BUFFER CACHE作为数据块缓冲区，不是一块简单的内存区域。在这一块内存区域上，Oracle设计了很多LATCH来保护BUFFER CACHE的结构不受并发性访问的破坏，当LATCH数量不够用或并发访问模式不兼容时，将会引起LATCH的争用，这就是我们经常看到的LATCH FREE等待事件。从BUFFER CACHE中读取数据块一般需要花费100ns左右，假设每次只读取一个数据块，也就是每秒可以读取10 000 000个数据块。而从磁盘读取数据块一般需要花费10ms左右（包括寻址定位时间和传输时间），也就是说每秒只能读取100个数据块。从这个角度来讲，数据块从内存中读取的效率要比从磁盘中读取高100 000倍，但并不是说数据块从BUFFER CACHE中读取一定比从磁盘中读取好，即BUFFER CACHE的命中率并不是越高越好。BUFFER CACHE作为Oracle 数据块的缓冲区，不同的系统类型和业务模块对其命中率的敏感程度会有所不同。比如OLTP系统并发高、事务小、响应快、SQL执行时读取的数据块数量较少，因此，在此系统上比较高的BUFFER CACHE命中率不仅能加快数据块的读取时间，而且能有效缓解存储的I/O压力。而OLAP系统并发低，事务大，SQL执行时读取的数据块数量较多， 所以在这类系统中，BUFFER CACHE命中率的高低却不是特别重要，而且在此类系统中， ...继续阅读 (15)

从数据库性能优化的场景来区分，可以将性能优化分为如下三种形式： 从来没达到过性能要求的数据库优化。该类故障一般出现在压力测试或者业务系统刚上线时，可能需要通过修改应用架构，大规模优化SQL语句来进行改进，此类优化难度最大，耗时也最长。 量变引起质变的数据库优化。该类故障通常是由数据库并发加大，数据量增多引起的，优化难度一般，但代价可能较高。在国内，很多客户都是通过增加硬件投入来解决该类性能问题的。 突发性的数据库性能故障优化。该类故障优化的难度最低，但时间紧迫性更强，需要DBA能够快速解决问题。从数据库性能优化的时间点来分，又分以下2点： 事前优化，指的是业务系统上线前的优化。在事前优化过程中，系统设计、开发、产品优化、平台优化的全过程都很重要。实践经验表明，事前优化对于系统的平稳运行有着根本性的影响，而且优化代价也最低。 事后优化，指的是业务系统上线后的优化。由于事后优化受到宕机时间、代码版本控制、代码内核不容易更改等因素影响，所以事后优化往往只能缓减系统性能下降的症状，治标不治本。系统上线之后，如果爆发出大规模的性能问题，那通常都会是灾难性的，任何容灾在这时都起不了作用。提示 千万别将数据库的优化全部寄托于系统的参数优化和硬件升级上。数据库性能优化并没有统一的标准步骤，“不管黑猫白猫，捉到老鼠就是好猫”，这句话在性能优化领域也同样适用。一个性能优化项目的目标如下： ...继续阅读 (15)

某客户数据库为10.2.0.4 RAC，运行在HP-UX平台上，如下所示：某日，在使用exp进行本地全库逻辑导出时发现很慢，导出语句的主要语法如下：exp full=y buffer=10M direct=y statistics=none file=.. log =..可以看到客户对exp导出已经进行了优化，使用了直接路径导出（direct=y ），并且不导统计信息（statistics=none） ，但导出速度依然不可接受，一个晚上只导出了20G，这是极为不正常的。数据库exp导出速度的主要影响因素如下： 存储的I/O性能。 exp的导出参数。 数据库资源的争用。exp导出期间，操作系统资源和存储I/O正常，如下所示：Mon Jul 8 20:27:00 EAT 2013procs memory page faults cpur b w avm free re at pi po fr de sr in sy cs us sy id6 1 0 3632805 6982185 0 0 1 0 0 0 ...继续阅读 (9)

某客户数据库从P595物理迁移至P780新服务器并更换存储之后，发现应用性能反而下降。P780配置了32颗4核CPU（主频为3920 MHz），710G内存。如下所示：System Model: IBM,9179-MHCMachine Serial Number: 06DA0CRProcessor Type: PowerPC_POWER7Processor Implementation Mode: POWER 7Processor Version: PV_7_CompatNumber Of Processors: 32Processor Clock Speed: 3920 MHzCPU Type: 64-bitKernel Type: 64-bitLPAR Info: 1 SN06DA0CRMemory Size: 727040 MBGood Memory Size: 727040 MBPlatform Firmware level: AM740_088Firmware Version: IBM,AM740_088Console Login: enableAuto Restart: trueFull Core: falseP595配置了32颗双线程CPU（主频为2302 MHz），186G内存。如下所示：System Model: IBM,9119-595Machine Seria ...继续阅读 (49)

某客户数据库的版本为11.2.0.3，如下所示：SQL> select * from v$version;BANNER------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit ProductionPL/SQL Release 11.2.0.3.0 - ProductionCORE 11.2.0.3.0 ProductionTNS for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - ProductionNLSRTL Version 11.2.0.3.0 - Production数据库使用的UNDO表空间为UNDOTBS1，且为自动管理，如下所示：SQL> show parameter undo_managementNAME TYPE VALUE------------------------------------ ----------- ------------------------------undo_mana ...继续阅读 (13)

一、voting disk换盘注意：voting disk是在crs，rdbms状态正常的情况下进行1、raw4用于新的voting disk，raw5用于新的ocr disk，注意其权限[root@node1 ~]# ls -l /dev/raw/raw4crw-rw---- 1 oracle dba 162, 4 Feb 28 15:22 /dev/raw/raw4[root@node1 ~]# ls -l /dev/raw/raw5crw-rw---- 1 oracle dba 162, 5 Feb 28 15:22 /dev/raw/raw52、观察目前系统中的voting disk[root@node1 oracle]# crsctl query css votedisk0. 0 /dev/raw/raw2located 1 votedisk(s).3、系统中添加voting disk[root@node1 oracle]# crsctl add css votedisk /dev/raw/raw4Cluster is not in a ready state for online disk addition[root@node1 oracle]# crsctl add css votedisk /dev/raw/raw4 -forceNow formatt ...继续阅读 (27)

事情起源：客户需求：数据文件过大，客户业务表格清空数据之后需要缩小数据文件SQL> select file_id,max(BLOCK_ID) from dba_extents where OWNER='TERSA' and SEGMENT_NAME='AA065' group by file_id;FILE_ID MAX(BLOCK_ID)---------- -------------4 102537SQL> select max(BLOCK_ID) from dba_extents where file_id=4;MAX(BLOCK_ID)-------------102537SQL> truncate table TERSA.AA065;Table truncated.SQL> select max(BLOCK_ID) from dba_extents where file_id=4;MAX(BLOCK_ID)-------------22793SQL> select 22793*8192 from dual;22793*8192----------186720256SQL> !ls -l /lank/db/lank/users01.dbf-rw-r----- 1 ora10g dba 841490432 Nov 14 13:18 /lank/db/lank/u ...继续阅读 (28)

本文章仅作记录，没有任何意思Fri Nov 11 20:50:04 2011Shutting down instance: further logons disabledFri Nov 11 20:50:05 2011Stopping background process CJQ0Fri Nov 11 20:50:05 2011Stopping background process QMNCFri Nov 11 20:50:07 2011Stopping background process MMNLFri Nov 11 20:50:08 2011Stopping background process MMONFri Nov 11 20:50:09 2011Shutting down instance (immediate)License high water mark = 36Fri Nov 11 20:50:09 2011Stopping Job queue slave processesFri Nov 11 20:50:09 2011Job queue slave processes stoppedAll dispatchers and shared servers shutdownFri Nov 11 20:50:21 2011PMON failed to acquire ...继续阅读 (14)

客户生产库版本为AIX 11.2.0.2,客户端版本为11.2.0.1，在客户端按用户级别导出表格的时候出现以下错误：. . 正在导出表 S61_B214_GT_2010_3301导出了 1224 行EXP-00008: 遇到 ORACLE 错误 1455ORA-01455: 转换列溢出整数数据类型EXP-00000: 导出终止失败为了排除错误，客户端以表方式导出，S61_B214_GT_2010_3301，的下一张表格报同样错误，同时在某些客户端报错信息多了以下错误：EXP-00003: no storage definition found for segment(0,0)这个错误已经很明显了，因为在11.2.0.1时，由参数deferred_segment_creation（默认为true）控制是否对新建表格默认分配段空间，所以在exp新建表格时，往往会出现此类错误。最终Oracle认为此类错误为bug，并在11.2.0.2时得以修正。知道问题的原因之后，我们就可以有以下3种解决方案：1、在生产端导出2、客户端升级到11.2.0.2，由于客观原因，不能升级客户端.3、生产库将参数deferred_segment_creation由true改为f ...继续阅读 (21)