Oracle性能诊断的方法有很多，下面就此讲讲常用的几种方法。一般而言，如果需要进行性能调整，那么，肯定是存在一些性能问题。所以，诊断，要从用户所提出的性能问题开始着手，做到有的放矢。
用户可能会罗列出一大堆的性能问题，你比如说：某个操作比较慢呀，或者说当达到多少用户的并发时CPU和内存使用达到100%，死锁等等。所以，我们要对用户列出的这些性能问题进行分析。当然，首先得从用户认为最迫切的性能问题开始着手进行分析。
明确了性能问题，这是系统调优的***步，让我们有一个出发点，但是分析性能问题，找到性能问题产生的原因，这是一个复杂的过程，并且是性能调优的非常重要的一个过程。只有找到了产生性能问题的根源，你才好着手进行调整。
在Orace性能诊断上，首先要有一个思路。从整体到局部，从面到点，逐步定位是一个不错的方法。那么，什么是从整体到局部呢？
Oracle数据库本质上是运行于某一种计算机上的应用软件，所以，这个整体，我指的就是运行Oracle的计算机（即 服务器 ）。如果，性能诊断问题的根源是因为计算机的性能低下所导致，那么，做其它的调整将不能根本改变Oracle的性能状况，我们得从调整这个整体开始（即服务器的性能）。
服务器的性能我觉得由2个因素所组成：硬件和操作系统。
(1)硬件包括：CPU，内存，存储等。检查的方法是我们可以登录到服务器发布一些命令来查看服务器CPU,内存,以及硬盘等的I/O速率，如UNIX下及类UNIX（LINUX）下可以发布：
Top,vmstat,iostat,free等等命令来检查这些硬件资源的使用状况。还可以使用一些第三方的测量工具。比如，有一些工具是专门用来测试硬盘的传输速率的，从中我们可以知道硬盘的平均带宽是多少。通过这些工具，如果检查出来，发现是由于服务器的硬件资源所导致的性能问题，那么，我们就可以建议提升服务器的硬件。
(2)第二个因素是OS。因为Oracle是运行于OS之上的，所以OS的一些设置，也会导致一些性能问题。特别是在LINUX下，一些参数的设置，如：内核参数，交换空间(swap)等等，也能影响到整个系统的性能。所以，我们也可以在服务器上查看一下这些设置。如果是windows服务器，windows提供了一个性能测量工具，可以测量每秒的内存页交换（paging）等指标，从这些指标中我们也可以检查出内存是否足够，以及虚拟内存是否足够等等一些问题。
检查完服务器，就可以从Oracle本身开始进行分析了。分析的思路，我也是从整体到局部，从面到点。整体：首先，我们可以从了解一下Oracle数据库的规划开始，这些规划具体包括：存储的规划，内存的规划，实例参数设置等等，下面我分别作一些简单的介绍。
(1)存储的规划（storage planning）:实际上指的就是Oracle数据库的磁盘规划，这关系到Oracle的I/O性能。举例：oracle的数据文件磁盘是否和oracle软件磁盘分开？应用系统是否有创建单独的表空间？有没有为索引和大对象创建单独的表空间？多路复用(multiplexed)的控制文件是否分别存放于不同的磁盘？日志组的不同成员是否存放于不同磁盘？等等，这些都或多或少地影响到oracle的I/O性能。
(2)内存规划(memory planning)：实际上指的是oracle SGA和PGA的分配是否合理？以及组成SGA的各个内存组件的内存分配是否达到***？一般而言，对于排序操作（sort operation）比较多的系统，比如，我们的XPC系统，或者报表系统，就应该适当地多分配一些内存给PGA。当然，PGA总体目标也要根据系统的连接数来确定。在SGA方面，总体原则是，尽量把大部分的内存分配给数据库高速缓存，以增加内存的命中率。至于其它组件如：JAVA池，大池等分配几十M就可以（32M一般就够了）。而对于共享池，则要根据CPU的性能来决定。一般而言，如果CPU很强（如采用多路CPU），则共享池设小一点也无所谓。一般而言，设80M~300M都能满足系统需求，再多设的话对系统性能增加不大，反而浪费内存。
(3)实例的参数：有些Oracle实例的参数能够影响到整个系统的性能。你比如：与oracle优化器相关的一些参数设置，与SQL共享和重用相关的参数,与是否预先将SGA装载到内存相关的参数等等.我们都要检查一些,这些参数设置是否合理.
那么,我们怎么能够检查出这些整体的设置是否就是导致性能问题的根源呢?Oracle有提供一个用于诊断性能问题的工具包(statspack).当然，可能也有一些第三方的用于oracle性能诊断的工具，但是我想没有其它工具比ORACLE本身提供的工具更全面，更准确了。
STATSPACK需要安装。安装后我们需要设置一下检查的时间间隔，实际上就是创建一个oracle的JOB。Statspack或根据我们设定的时间间隔来从oracle的动态性能视图中捕捉一些与性能相关的数据，然后根据一定的公式进行计算，生成一个有关于oracle各项性能指标的报告。报告罗列了一些实际的活动状况（负载，内存命中率等等），***等待事件，以及TOP SQL等内容，是我们进行Oracle性能诊断的一个比较综合的一个工具。
局部：oracle的整体调整完毕后，我们就可能逐步逐步调整某个局部了。你比如，我们可以根据用户反映出来的问题：比如说，在XPC中点击某个BUTTON或进行某项操作，系统响应比较慢，这个时候，我们就可能针对这个问题，来进行定位。导致这个操作慢有可能是由于这个操作执行的SQL语句比较慢，也有可能是由于我们的JAVA代码写得不够好，实现比较复杂，结构不合理等等所导致。往往，这样的性能诊断，要DBA和相关开发人员一起协同完成。在DB这一层，我们可以使用ORACLE的一些实用工具，如SQL TRACE等来捕捉这些SQL，然后对这个SQL的进行分析，并进行优化，从而解决这些性能问题。根据实践，相当大一部分性能优化是在SQL语句一级着手的。
除了上面我所描述的这些以外，其它与性能相关的情况也需要调查一下。如：Oracle是采用何种类型的优化器？如果是采用基于成本的优化器（CBO），是否有定期进行统计（gather shema statistics）?统计的时间间隔设置是否合理？
另外一个跟SQL性能相关的因素就是索引。我们也可以检查一下是否在相关表上有否建索引？这些索引建得是否合理？是否有存在从来没有被使用过的索引（通过索引监控工具来检查）？
***一个检查的项可能是和并发有关。假如用户反映说系统有时会出现死锁，这时，我们就要检查一下导致死锁的原因了，如捕获相关的引起死锁的SQL语句，分析是由于应用的架构设计所导致还是由于业务逻辑本身所导致。在DB这一级，我们可以检查一下事务的隔离等级是否高置合理。
【编辑推荐】
4、空间数据库中,矢量数据的管理方式有哪些,各有什么优缺点?
1、文件-关系数据库混合管理方式不足：①属性数据和图形数据通过ID联系起来，使查询运算，模型操作运算速度慢；② 数据分布和共享困难；③属性数据和图形数据分开存储，数据的安全性、一致性、完整性、并发控制以及数据损坏后的恢复方面缺少基本的功能；④缺乏表示空间对象及其关系的能力。 因此，目前空间数据管理正在逐步走出文件管理模式。 2、全关系数据库管理方式对于变长结构的空间几何数据，一般采用两种方法处理。 ⑴ 按照关系数据库组织数据的基本准则，对变长的几何数据进行关系范式分解，分解成定长记录的数据表进行存储。 然而，根据关系模型的分解与连接原则，在处理一个空间对象时，如面对象时，需要进行大量的连接操作，非常费时，并影响效率。 ⑵ 将图形数据的变长部分处理成binary二进制Block块字段。 3、对象-关系数据库管理方式由于直接采用通用的关系数据库管理系统的效率不高，而非结构化的空间数据又十分重要，所以许多数据库管理系统的软件商在关系数据库管理系统中进行扩展，使之能直接存储和管理非结构化的空间数据。 这种扩展的空间对象管理模块主要解决了空间数据的变长记录的管理，由数据库软件商进行扩展，效率要比前面所述的二进制块的管理高得多。 但是它仍然没有解决对象的嵌套问题，空间数据结构也不能内用户任意定义，使用上仍受到一定限制。 矢量图形数据与属性数据的管理问题已基本得到解决。 从概念上说，空间数据还应包括数字高程模型、影像数据及其他专题数据。 虽然利用关系数据库管理系统中的大对象字段可以分块存贮影像和DEM数据，但是对于多尺度DEM数据，影像数据的空间索引、无缝拼接与漫游、多数据源集成等技术还没有一个完整的解决方案。
MDF和LDF文件有什么方法导入MYSQL里
先将其里面的每个表导出为txt文件, 然后在mysql中用load data infile导入txt文件
oracle数据库的后台进程有哪些
DBWR进程：该进程执行将缓冲区写入数据文件，是负责缓冲存储区管理的一个ORACLE后台进程。 当缓冲区中的一缓冲区被修改，它被标志为“弄脏”，DBWR的主要任务是将“弄脏”的缓冲区写入磁盘，使缓冲区保持“干净”。 由于缓冲存储区的缓冲区填入数据库或被用户进程弄脏，未用的缓冲区的数目减少。 当未用的缓冲区下降到很少，以致用户进程要从磁盘读入块到内存存储区时无法找到未用的缓冲区时，DBWR将管理缓冲存储区，使用户进程总可得到未用的缓冲区。 ORACLE采用LRU（LeasT RECENTLY USED）算法（最近最少使用算法）保持内存中的数据块是最近使用的，使I/O最小。 在下列情况预示DBWR 要将弄脏的缓冲区写入磁盘：当一个服务器进程将一缓冲区移入“弄脏”表，该弄脏表达到临界长度时，该服务进程将通知DBWR进行写。 该临界长度是为参数DB-BLOCK-WRITE-BATCH的值的一半。 当一个服务器进程在LRU表中查找DB-BLOCK-MAX-SCAN-CNT缓冲区时，没有查到未用的缓冲区，它停止查找并通知DBWR进行写。 出现超时（每次3秒），DBWR 将通知本身。 当出现检查点时，LGWR将通知DBWR.在前两种情况下，DBWR将弄脏表中的块写入磁盘，每次可写的块数由初始化参数DB-BLOCK- WRITE-BATCH所指定。 如果弄脏表中没有该参数指定块数的缓冲区，DBWR从LUR表中查找另外一个弄脏缓冲区。 如果DBWR在三秒内未活动，则出现超时。 在这种情况下DBWR对LRU表查找指定数目的缓冲区，将所找到任何弄脏缓冲区写入磁盘。 每当出现超时，DBWR查找一个新的缓冲区组。 每次由DBWR查找的缓冲区的数目是为寝化参数DB-BLOCK- WRITE-BATCH的值的二倍。 如果数据库空运转，DBWR最终将全部缓冲区存储区写入磁盘。 在出现检查点时，LGWR指定一修改缓冲区表必须写入到磁盘。 DBWR将指定的缓冲区写入磁盘。 在有些平台上，一个实例可有多个DBWR.在这样的实例中，一些块可写入一磁盘，另一些块可写入其它磁盘。 参数DB-WRITERS控制DBWR进程个数。 LGWR进程：该进程将日志缓冲区写入磁盘上的一个日志文件，它是负责管理日志缓冲区的一个ORACLE后台进程。 LGWR进程将自上次写入磁盘以来的全部日志项输出，LGWR输出：当用户进程提交一事务时写入一个提交记录。 每三秒将日志缓冲区输出。 当日志缓冲区的1/3已满时将日志缓冲区输出。 当DBWR将修改缓冲区写入磁盘时则将日志缓冲区输出。 LGWR进程同步地写入到活动的镜象在线日志文件组。 如果组中一个文件被删除或不可用，LGWR 可继续地写入该组的其它文件。 日志缓冲区是一个循环缓冲区。 当LGWR将日志缓冲区的日志项写入日志文件后，服务器进程可将新的日志项写入到该日志缓冲区。 LGWR 通常写得很快，可确保日志缓冲区总有空间可写入新的日志项。 注意：有时候当需要更多的日志缓冲区时，LWGR在一个事务提交前就将日志项写出，而这些日志项仅当在以后事务提交后才永久化。 ORACLE使用快速提交机制，当用户发出COMMIT语句时，一个COMMIT记录立即放入日志缓冲区，但相应的数据缓冲区改变是被延迟，直到在更有效时才将它们写入数据文件。 当一事务提交时，被赋给一个系统修改号（SCN），它同事务日志项一起记录在日志中。 由于SCN记录在日志中，以致在并行服务器选项配置情况下，恢复操作可以同步。 CKPT进程：该进程在检查点出现时，对全部数据文件的标题进行修改，指示该检查点。 在通常的情况下，该任务由LGWR执行。 然而，如果检查点明显地降低系统性能时，可使CKPT进程运行，将原来由LGWR进程执行的检查点的工作分离出来，由 CKPT进程实现。 对于许多应用情况，CKPT进程是不必要的。 只有当数据库有许多数据文件，LGWR在检查点时明显地降低性能才使CKPT运行。 CKPT进程不将块写入磁盘，该工作是由DBWR完成的。 初始化参数CHECKPOINT-PROCESS控制CKPT进程的使能或使不能。 缺省时为FALSE，即为使不能。 SMON进程：该进程实例启动时执行实例恢复，还负责清理不再使用的临时段。 在具有并行服务器选项的环境下，SMON对有故障CPU或实例进行实例恢复。 SMON进程有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。 PMON进程：该进程在用户进程出现故障时执行进程恢复，负责清理内存储区和释放该进程所使用的资源。 例：它要重置活动事务表的状态，释放封锁，将该故障的进程的ID从活动进程表中移去。 PMON还周期地检查调度进程（DISPATCHER）和服务器进程的状态，如果已死，则重新启动（不包括有意删除的进程）。 PMON有规律地被呼醒，检查是否需要，或者其它进程发现需要时可以被调用。 RECO进程：该进程是在具有分布式选项时所使用的一个进程，自动地解决在分布式事务中的故障。 一个结点RECO后台进程自动地连接到包含有悬而未决的分布式事务的其它数据库中，RECO自动地解决所有的悬而不决的事务。 任何相应于已处理的悬而不决的事务的行将从每一个数据库的悬挂事务表中删去。 当一数据库服务器的RECO后台进程试图建立同一远程服务器的通信，如果远程服务器是不可用或者网络连接不能建立时，RECO自动地在一个时间间隔之后再次连接。 RECO后台进程仅当在允许分布式事务的系统中出现，而且DISTRIBUTED ？C TRANSACTIONS参数是大于进程：该进程将已填满的在线日志文件拷贝到指定的存储设备。 当日志是为ARCHIVELOG使用方式、并可自动地归档时ARCH进程才存在。 LCKn进程：是在具有并行服务器选件环境下使用，可多至10个进程（LCK0，LCK1……，LCK9），用于实例间的封锁。 Dnnn进程（调度进程）：该进程允许用户进程共享有限的服务器进程（SERVER PROCESS）。 没有调度进程时，每个用户进程需要一个专用服务进程（DEDICATEDSERVER PROCESS）。 对于多线索服务器（MULTI-THREADED SERVER）可支持多个用户进程。 如果在系统中具有大量用户，多线索服务器可支持大量用户，尤其在客户_服务器环境中。 在一个数据库实例中可建立多个调度进程。 对每种网络协议至少建立一个调度进程。 数据库管理员根据操作系统中每个进程可连接数目的限制决定启动的调度程序的最优数，在实例运行时可增加或删除调度进程。 多线索服务器需要SQL*NET版本2或更后的版本。 在多线索服务器的配置下，一个网络接收器进程等待客户应用连接请求，并将每一个发送到一个调度进程。 如果不能将客户应用连接到一调度进程时，网络接收器进程将启动一个专用服务器进程。 该网络接收器进程不是ORACLE实例的组成部分，它是处理与ORACLE有关的网络进程的组成部分。 在实例启动时，该网络接收器被打开，为用户连接到ORACLE建立一通信路径，然后每一个调度进程把连接请求的调度进程的地址给予于它的接收器。 当一个用户进程作连接请求时，网络接收器进程分析请求并决定该用户是否可使用一调度进程。 如果是，该网络接收器进程返回该调度进程的地址，之后用户进程直接连接到该调度进程。 有些用户进程不能调度进程通信（如果使用SQL*NET以前的版本的用户），网络接收器进程不能将如此用户连接到一调度进程。 在这种情况下，网络接收器建立一个专用服务器进程，建立一种合适的连接.即主要的有：DBWR,LGWR,SMON 其他后台进程有PMON,CKPT等
发表评论