ITPub博客

今天在扩容表空间的时候出现报错ERROR at line 1:ORA-19502: write error on file "/u01/app/oracle/oradata/gbps/LIS66.db", block number 1139968 (block size=8192)ORA-27072: File I/O errorAdditional information:

今天早上在使用数据泵导入的时候出现ORA-39002: invalid operationORA-39070: Unable to open the log file.ORA-29283: invalid file operationORA-06512: at "SYS.UTL_FILE", line 536ORA-29283: invalid file operation查询

RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 12/08/2018 05:03:36 RMAN-06026: some targets not found - aborting restore RMAN-06023: no backup or copy of datafile 4 found to restore R

现在很少用exp和imp，这两天从11g到10G的数据迁移，用数据泵出现乱码，就整理关于exp和imp的相关的知识。

设置process时需要注意的有这么几个方面1、受操作系统参数的限制，操作系统中oracle用户使用的nproc参数要够大，否则process设的再大也没有用。2、查看oracle数据库pga的大小，如果pga太小也会有问题。3、process的设置还和shared_pool有关系今天我们主要分析第二点和第三点首先看PGA的问题，我们使用的是专用服务器（DEDICATED）连接方式的话，客户端建立

前 言在客户现场处理各种各样的问题，很多问题会涉及到数据库、存储、操作系统甚至应用代码，只有先定位问题的根源在哪个或哪几个方向，才能做出针对性的分析，否则就很有可能在处理问题的过程中南辕北辙，无的放矢，无法快速解决问题；今天分享的问题，可能到最后，并不是DBA可以控制的部分，然而作为DBA，时不时需要解释两个问题：我们什么都没有变化，出了问题跟我们有关吗？为什么以前没有问题，现在有问题了呢？事实上

ASSM机制是oracle在段内进行空间自动管理的机制；通常来说，这个机制能很好的帮我们查找、定位、分配相关的段空间；然而，所有的机制都不是那么完美的，在具体的CASE中，我们需要充分理解它，才能更好的掌控它；今天的CASE分享，希望大家能对ASSM机制有真正充分的理解。1问题来了“我们这一个奇怪的问题吧，一个简单的insert语句居然执行了上百秒。”在一个投产上线后的某一天，负责应用维护的同事描

前言作为经验丰富的DBA，我们经常会遇到各式各样的bug；然而，并不是每个bug都可以简单的直接通过现象匹配出来，很多时候，我们可能需要通过不同的维度先收集很多信息，甚至先找出问题的解决/绕行方案，再来确定问题的bug的源头；今天的分享，我们就来看一个用特别的方法来定位、确认bug的案例，通过这个案例，我们可以举一反三，触类旁通的了解更多oracle的小技巧；在案例分享中，方法比结论来的更重要！升

前言：通常SQL优化的常见手段包括，收集统计信息，创建索引，重写SQL语句，而大家日常遇到的CASE中是否也有遇到过，SQL已经看似没有优化空间，系系统整体性能也非常良好，但是SQL语句就是达不到预期执行效率的呢？今天作者给大家分享的就是一个不算SQL优化的“SQL优化"，希望大家能有所启发；     批量语句太慢了某日早上，客户应用维护的同事提出问题，有一

前言一个复杂问题通常可以拆解成若干个简单问题来分析，如何从各个维度来分析和确认一个问题，并最终给出合理的解决方案却又是一个比较复杂的过程；今天给大家分享的就是，从一个"简单"的报错最后定位到bug，并最终结合具体CASE给出解决方案的案例，希望大家能从中领悟到解决问题过程中的各种技巧和思路，同时告诉大家有些oracle bug并不可怕，其实我们自己就可以给出解决方案。“简单”的

前言：上线前检查已经是老生常谈了，通常上线前检查完后，就应该当做生产系统对待，不应该随意修改系统的相关配置，然而，很多老司机会认为，自己对系统很有把握，修改一些系统配置，重启系统后没有任何问题，就此认为一切正常；殊不知，很可能一个不经意的操作，给你的系统就已经带来了无法预知的隐患。发现隐患客户新搭建了一套11g的RAC+DATAGUARD环境，CRS、数据库已经运行了一段时间了，正准备投产上线，这

现象描述数据库大版本升级的过程是相对复杂和繁琐的，非标准流程下100套系统可能会遇到100个不同的问题，这种问题相对好解决，那么本期的问题来了，在使用EXPDP/IMPDP工具，从Oracle 10.2.0.4迁移到11.2.0.4之后，约束比对时发现，原生产环境10.2.0.4的数据库比新生产11.2.0.4环境中多了27个约束：select owner,CONSTRAINT_TYPE,STAT

前言：时间一晃已经来到了6月，技术人生系列文章已经半年没有更新了，在过去的半年时间里，我们技术人生系列文章的作者们一直奋战在工作一线，同时不忘积累和总结，为我们的文章提供更深厚的底蕴；如今，技术人生系列将携中亦课堂正式回归，依旧严谨深刻，生动再现客户现场处理问题的点点滴滴，希望在传递更多知识点的同时给大家带来更多深度的思考。在这里，首先感谢一直以来支持技术人生系列的小伙伴们，你们的支持与转发是我们

问题来了某客户发现生产库上的跑批脚本经常跑了180+ 分钟，而在测试库跑完脚本只要60分钟；客户觉得生产服务器的配置比测试服务器高，而且数据库的压力很小，出现这种生产比测试还慢的情况无法理喻，怀疑是ORACLE数据库有问题，所以联系小编进一步排查。负载性能先看生产库的AWR，面对这种数据库总体性能问题，从AWR入手可以直观而且全面地了解一个数据库的性能和问题；生产库运行在AIX平台上8C 32GB

在系统维护的过程中，随时可能有需要查看 CPU 使用率，并根据相应信息分析系统状况的需要。在 CentOS 中，可以通过 top 命令来查看 CPU 使用状况。运行 top 命令后，CPU 使用状态会以全屏的方式显示，并且会处在对话的模式 -- 用基于 top 的命令，可以控制显示方式等等。退出 top 的命令为 q （在 top 运行中敲 q 键一次）。top命令是Linux下常用的性能分析工具

一、问题描述某大型国有银行的一套业务系统，近期由小型机迁移至X86环境。据项目组反映部分DB_LINK查询比原来小型机慢。这不对啊，相同的存储，CPU也更多，内存也更大。于是DBA随手挑出一张大表，做个简单的COUNT(*)查询，发现Linux比AIX慢了6倍。重复执行多次，结果也类似。难道委屈项目组了，这套X86就是比小机慢？于是找上中亦，深入分析下问题原因。执行时间对比AIX下执行时间为3分1

上线前的压力测试，是系统上线过程中重要一环；一轮好的压力测试，不仅能发现系统配置方面的不足，更重要的是能发现应用设计上的缺陷；压测时发现问题之时，事实上也是我们结合应用逻辑提出有效解决方案的大好机会；这个时候的改动，代价更小、调整更方便，而且还能直接看到压力环境下的测试效果；也就能验证你提出的解决方案是否有效了。 今天笔者要跟大家分享的问题，是一个压测过程中与"enq: TX

线上的生产系统，因为一些原因，时不时会出现一些意想不到的性能问题，当紧急问题出现时，我们如果无法立即解决，有时通过调整系统硬件资源是一种快速有效的解决应急方式，确保系统能正常运行后，再做根因分析，从根本上解决问题； 最近老K遇到了客户的应急策略导致了数据库重启的案例，翻了翻邮件历史，竟是N年前就已经遇到过了；问题本身不算复杂，然而却可以造成数据库直接重启，影响生产，这里特别分享出来，给大

相信大家做DBA的，都看到过很多数据库专家缜密思考、抽丝剥茧、层层推进最终找到问题答案的精彩案例。Jason每次看到这样的案例，都被专家们丰富的经验，执着的态度和强大的逻辑推理能力折服。但这是不是诊断数据库问题的唯一方法论呢？可不可以讲近来大热的机器学习思想引入其中，通过统计学（深度学习的基础）来诊断问题呢？Jason在近期遇到的一个问题上，做了些许尝试，这里分享给大家。。。　问题描述　在Jaso

写在前面如果你的数据库性能经常抖动，时快时慢，你会怎么入手，又会怎么一步步排查解决的？是先看等待事件？还是看AWR或ASH？接下来优化SQL？调整参数？甚至更换硬件？本次分享一个我在GCS处理的案例，希望大家读后会有新的收获。问题来了在一个宁静的早晨，本来打算能够看会儿书，做几个实验来打发时间，刚刚拿起书，电话就如期而至，让本来宁静的早晨变成了工作的开始。仔细想想，这就是运维人的常态吧，也就释然了