此文章主要介绍的是通过优化数据库来大幅度的提高Oracle数据库性能，以下几个简单的相关步骤就可以简单实现Oracle数据库性能，下面就是文章的具体内容的描述，望你浏览之后会对其有所了解。
数据库优化的讨论可以说是一个永恒的主题。资深的Oracle优化人员通常会要求提出Oracle数据库性能问题的人对数据库做一个statspack，贴出数据库配置等等。还有的人认为要抓出执行最慢的语句来进行优化。
但实际情况是，提出疑问的人很可能根本不懂执行计划，更不要说statspack了。而我认为，数据库优化，应该首先从大的方面考虑：网络、 服务器 硬件配置、操作系统配置、Oracle服务器配置、数据结构组织、然后才是具体的调整。
实际上网络、硬件等往往无法决定更换，应用程序一般也无法修改，因此应该着重从数据库配置、数据结构上来下手，首先让数据库有一个良好的配置，然后再考虑具体优化某些过慢的语句。我在给我的用户系统进行优化的过程中，总结了一些基本的，简单易行的办法来优化数据库，算是我的三板斧，呵呵。
不过请注意，这些不一定普遍使用，甚至有的会有副作用，但是对OLTP系统、基于成本的数据库往往行之有效，不妨试试。（注：附件是Burleson写的用来报告Oracle数据库性能等信息的脚本，本文用到）
一．设置合适的SGA
常常有人抱怨服务器硬件很好，但是Oracle就是很慢。很可能是内存分配不合理造成的。(1)假设内存有512M，这通常是小型应用。建议Oracle的SGA大约240M，其中：共享池（SHARED_POOL_SIZE）可以设置60M到80M，根据实际的用户数、查询等来定。
数据块缓冲区可以大致分配120M-150M，8i下需要设置DB_BLOCK_BUFFERS，DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于数据块缓冲区大小。9i 下的数据缓冲区可以用db_cache_size来直接分配。
(2)假设内存有1G，Oracle 的SGA可以考虑分配500M：共享池分配100M到150M，数据缓冲区分配300M到400M。
(3)内存2G，SGA可以考虑分配1.2G，共享池300M到500M，剩下的给数据块缓冲区。
(4)内存2G以上：共享池300M到500M就足够啦，再多也没有太大帮助；(Biti_rainy有专述)数据缓冲区是尽可能的大，但是一定要注意两个问题：一是要给操作系统和其他应用留够内存，二是对于32位的操作系统，Oracle的SGA有1.75G的限制。有的32位操作系统上可以突破这个限制，方法还请看Biti的大作吧。
二．分析表和索引，更改优化模式
Oracle数据库性能默认优化模式是CHOOSE，在这种情况下，如果表没有经过分析，经常导致查询使用全表扫描，而不使用索引。这通常导致磁盘I/O太多，而导致查询很慢。如果没有使用执行计划稳定性，则应该把表和索引都分析一下，这样可能直接会使查询速度大幅提升。
分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令。对于少于100万的表，可以考虑分析整个表，对于很大的表，可以按百分比来分析，但是百分比不能过低，否则生成的统计信息可能不准确。可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间，索引可以通过DBA_INDEXES的LAST_ANALYZED列。
下面通过例子来说明分析前后的速度对比。（表CASE_GA_AJZLZ大约有35万数据，有主键）首先在SQLPLUS中打开自动查询执行计划功能。(***次要执行\RDBMS\ADMIN\utlxplan.sql来创建PLAN_TABLE这个表)
通过SET AUTOTRACE ON 来查看语句的执行计划，通过SET TIMING ON 来查看语句运行时间。
已用时间: 00: 00: 21.38
请注意上面分析中的TABLE Access(FULL)，这说明该语句执行了全表扫描。而且查询使用了21.38秒。这时表还没有经过分析。下面我们来对该表进行分析：
表已分析。已用时间: 00: 05: 357.63。然后再来查询：
已用时间: 00: 00: 00.71
【编辑推荐】
mysql悲观锁和乐观锁的区别
悲观锁与乐观锁是两种常见的资源并发锁设计思路，也是并发编程中一个非常基础的概念。 本文将对这两种常见的锁机制在数据库数据上的实现进行比较系统的介绍。 悲观锁（Pessimistic Lock）悲观锁的特点是先获取锁，再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的，因此要先确保获取锁成功再进行业务操作。 通常所说的“一锁二查三更新”即指的是使用悲观锁。 通常来讲在数据库上的悲观锁需要数据库本身提供支持，即通过常用的select … FOR update操作来实现悲观锁。 当数据库执行select for update时会获取被select中的数据行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发生排斥（需要等待行锁被释放），因此达到锁的效果。 select for update获取的行锁会在当前事务结束时自动释放，因此必须在事务中使用。 这里需要注意的一点是不同的数据库对select for update的实现和支持都是有所区别的，例如oracle支持select for update no wait，表示如果拿不到锁立刻报错，而不是等待，mysql就没有no wait这个选项。 另外mysql还有个问题是select for update语句执行中所有扫描过的行都会被锁上，这一点很容易造成问题。 因此如果在mysql中用悲观锁务必要确定走了索引，而不是全表扫描。 乐观锁（Optimistic Lock）乐观锁的特点先进行业务操作，不到万不得已不去拿锁。 即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新数据的最后一步再去拿一下锁就好。 乐观锁在数据库上的实现完全是逻辑的，不需要数据库提供特殊的支持。 一般的做法是在需要锁的数据上增加一个版本号，或者时间戳，然后按照如下方式实现：1. SELECT data AS old_data, version AS old_version FROM …;2. 根据获取的数据进行业务操作，得到new_data和new_version3. UPDATE SET data = new_data, version = new_version WHERE version = old_versionif (updated row > 0) {// 乐观锁获取成功，操作完成} else {// 乐观锁获取失败，回滚并重试}乐观锁是否在事务中其实都是无所谓的，其底层机制是这样：在数据库内部update同一行的时候是不允许并发的，即数据库每次执行一条update语句时会获取被update行的写锁，直到这一行被成功更新后才释放。 因此在业务操作进行前获取需要锁的数据的当前版本号，然后实际更新数据时再次对比版本号确认与之前获取的相同，并更新版本号，即可确认这之间没有发生并发的修改。 如果更新失败即可认为老版本的数据已经被并发修改掉而不存在了，此时认为获取锁失败，需要回滚整个业务操作并可根据需要重试整个过程。 总结乐观锁在不发生取锁失败的情况下开销比悲观锁小，但是一旦发生失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景，可以提升系统并发性能乐观锁还适用于一些比较特殊的场景，例如在业务操作过程中无法和数据库保持连接等悲观锁无法适用的地方
什么是OCM认证？如何获得Oracle 11g OCM认证
Oracle Certified Master(OCM)大师认证是Oracle官方最高级别的认证。 OCM认证是对Oracle数据库从业人员的技术、知识和操作技能经验的最高级别的认可。 Oracle OCM是解决最困难的技术难题和最复杂的系统故障的最佳Oracle专家人选。 OCM认证考试是资深专家级Oracle 技能考试，通过后将成为企业内的资深专家和顾问。 OCM不但有能力处理关键业务数据库系统和应用，还能帮助客户解决所有的Oracle技术困难。 要想获得OCM证书，必须先通过OCP考试，然后在Oracle公司北京、广州或者上海Oracle实验室通过场景实验OCM考试(11g OCM共9场考试，历时2天)。 场景实验考试的目的是测试您的实际问题分析和故障解决能力。 通过OCM考试，Oracle美国总部将在2个月内直接寄送 OCM证书、全球唯一识别号的OCM卡、OCM大师服装等系列物品。
4、空间数据库中,矢量数据的管理方式有哪些,各有什么优缺点?
1、文件-关系数据库混合管理方式不足：①属性数据和图形数据通过ID联系起来，使查询运算，模型操作运算速度慢；② 数据分布和共享困难；③属性数据和图形数据分开存储，数据的安全性、一致性、完整性、并发控制以及数据损坏后的恢复方面缺少基本的功能；④缺乏表示空间对象及其关系的能力。 因此，目前空间数据管理正在逐步走出文件管理模式。 2、全关系数据库管理方式对于变长结构的空间几何数据，一般采用两种方法处理。 ⑴ 按照关系数据库组织数据的基本准则，对变长的几何数据进行关系范式分解，分解成定长记录的数据表进行存储。 然而，根据关系模型的分解与连接原则，在处理一个空间对象时，如面对象时，需要进行大量的连接操作，非常费时，并影响效率。 ⑵ 将图形数据的变长部分处理成Binary二进制Block块字段。 3、对象-关系数据库管理方式由于直接采用通用的关系数据库管理系统的效率不高，而非结构化的空间数据又十分重要，所以许多数据库管理系统的软件商在关系数据库管理系统中进行扩展，使之能直接存储和管理非结构化的空间数据。 这种扩展的空间对象管理模块主要解决了空间数据的变长记录的管理，由数据库软件商进行扩展，效率要比前面所述的二进制块的管理高得多。 但是它仍然没有解决对象的嵌套问题，空间数据结构也不能内用户任意定义，使用上仍受到一定限制。 矢量图形数据与属性数据的管理问题已基本得到解决。 从概念上说，空间数据还应包括数字高程模型、影像数据及其他专题数据。 虽然利用关系数据库管理系统中的大对象字段可以分块存贮影像和DEM数据，但是对于多尺度DEM数据，影像数据的空间索引、无缝拼接与漫游、多数据源集成等技术还没有一个完整的解决方案。
发表评论