《2010年oracle学习数据库概念及实验》由会员分享，可在线阅读，更多相关《2010年oracle学习数据库概念及实验（20页珍藏版）》请在金锄头文库上搜索。
1、2010年oracle学习数据库概念及实验03 内存结构一、Oracle有3个主要的内存结构：1、系统全局区（System Global Area，SGA）：这是一个很大的共享内存段，几乎所有Oracle进程都要访问这个区中的某一点。2、进程全局区（Process Global Area，PGA）：这是一个进程或线程专用的内存，其他进程/线程不能访问。3、用户全局区（User Global Area，UGA）：这个内存区与特定的会话相关联。它可能在SGA中分配，也可能在PGA中分配，这取决于是用共享服务器还是用专用服务器来连接数据库。如果使用共享服务器，UGA就在SGA中分配；如果使用专用服务
2、器，UGA就会在PGA（即进程内存区）中。这里需要了解 SGA 区和 PGA 区就可以了。二、PGA 区进程全局区（PGA）是特定于进程的一段内存。换句话说，这是一个操作系统进程或线程专用的内存，不允许系统中的其他进程或线程访问。PGA一般通过C语言的运行时调用malloc()或memmap()来分配，而且可以在运行时动态扩大（甚至可以收缩）。PGA绝对不会在Oracle的SGA中分配，而总是由进程或线程在本地分配。所以，PGA包含进程内存，还可能包含UGA。PGA内存中的其他区通常用于完成内存中的排序、位图合并以及散列。可以肯定地说，除了UGA内存，这些区在PGA中的比重最大。我们使用自动管
3、理，所以手工管理参数就不讨论了。*实验过程：略由于这个实验有可能造成系统瘫痪，特别是一些初学人员会就此掌握使系统瘫痪的方法，所以不列出具体的实验过程。只需要记住结论就可以。1、DBA 使用自动管理方式，把管理交给数据库自身2、控制用户并发登陆，需要应用设计时考虑3、排序尽量使用分区表，使用index4、由于一些PGA内存不在Oracle的控制之下，所以如果在PL/SQL代码中分配了大量很大的数据结构，就很容易超出PGA_AGGREGATE_TARGET，有可能导致内存不足，而这个内存不足不是DBA（数据库管理员）和SA（操作系统管理员）能够控制的DBA 能做的第一条已经做了，后面三条都需要开发
4、人员考虑 历史故障：出现过的故障比较少，基本上从IO方面可以反映出来，一般是index问题，应用维护人员会比平台维护人员敏感，他们会自己重建index。三、SGA 区（一）SGA分为不同的池（pool）：1、Java池（Java pool）：Java池是为数据库中运行的JVM分配的一段固定大小的内存。在Oracle10g中，Java池可以在数据库启动并运行时在线调整大小。2、大池（Large pool）：共享服务器连接使用大池作为会话内存，并行执行特性使用大池作为消息缓冲区，另外RMAN备份可能使用大池作为磁盘I/O缓冲区。在Oracle 10g 和 9i Release 2中，大池都可以在线
5、调整大小。3、共享池（Shared pool）：共享池包含共享游标（cursor）、存储过程、状态对象、字典缓存和诸如此类的大量其他数据。在Oracle 10g和9i中，共享池都可以在线调整大小。4、流池（Stream pool）：这是Oracle流（Stream）专用的一个内存池，Oracle流是数据库中的一个数据共享工具。这个工具是Oracle 10g中新增的，可以在线调整大小。如果未配置流池，但是使用了流功能，Oracle会使用共享池中至多10%的空间作为流内存。5、“空”池（“Null”pool）：这个池其实没有名字。这是块缓冲区（缓存的数据库块）、重做日志缓冲区和“固定SGA”区专用
6、的内存。根据过去的经验：一定要掌握共享池（Shared pool）的工作原理，其他不作要求（二）共享池共享池是SGA中最重要的内存段之一，特别是对于性能和可扩缩性来说。共享池如果太小，会严重影响性能，甚至导致系统看上去好像中止了一样。如果共享池太大，也会有同样的效果。共享池使用不当会导致灾难性的后果。案例：应用或开发人员叫DBA扩共享池时，不是别人叫扩就能扩的，要分析有没有灾难性的后果到底什么是共享池？共享池就是Oracle缓存一些“程序”数据的地方。在解析一个查询时，解析得到的表示（representation）就缓存在那里。在完成解析整个查询的任务之前， Oracle会搜索共享池，看看这个
7、工作是否已经完成。你运行的PL/SQL代码就在共享池中缓存，所以下一次运行时，Oracle不会再次从磁盘重新读取。PL/SQL代码不仅在这里缓存，还会在这里共享。如果有1 000个会话都在执行同样的代码，那么只会加载这个代码的一个副本，并由所有会话共享。Oracle把系统参数存储在共享池中。数据字典缓存（关于数据库对象的已缓存信息）也存储在这里。简单地讲，就像是厨房的水池一样，什么东西都往共享池里放。共享池的特点是有大量小的内存块（chunk），一般为4 KB或更小。要记住，4 KB并不是一个硬性限制，可能有的内存分配会超过这个大小，但是一般来讲，我们的目标是使用小块的内存来避免碎片问题。如果
8、分配的内存块大小显著不同（有的很小，有的却相当大），就可能出现碎片问题。共享池中的内存根据LRU（最近最少使用）的原则来管理。在这方面，它类似于缓冲区缓存，如果你不用某个对象，它就会丢掉。为此提供了一个包，名叫DBMS_SHARED_POOL，这个包可用于改变这种行为，强制性地“钉住”共享池中的对象。可以使用这个过程在数据库启动时加载频繁使用的过程和包，并使它们不至于老化。不过，通常如果过一段时间共享池中的一段内存没有得到重用，它就会老化。甚至PL/SQL代码（可能相当大）也以一种分页机制来管理，这样当你执行一个非常大的包中的代码时，只有所需的代码会加载到共享池的小块中。如果你很长时间都没有用
9、它，而且共享池已经填满，需要为其他对象留出空间，它就会老化。如果你真的想破坏Oracle的共享池，最容易的办法是不使用绑定变量。这有两个原因：1、系统要花大量CPU时间解析查询。2、系统使用大量资源来管理共享池中的对象，因为从来不重用查询。对于这个问题，真正的解决方案只有一个，这就是使用共享SQL，也就是重用查询。参数CURSOR_SHARING游标共享可以作为一种短期的解决方案但是可能会造成oracle bug出现，DBA 不会同意使用这个参数。不过，真正要解决这个问题，首当其冲地还是要使用可重用的SQL。即使在最大的系统上，一般也最多有10 00020 000条不同的SQL语句。大多数系统
10、只执行数百个不同的查询。如果不绑定变量，需要增加越来越多的CPU，因为硬解析SQL太耗费CPU。要求开发人员在大多数情况下都会使用绑定变量。如果你确实想让Oracle缓慢地运行，甚至几近停顿，只要根本不使用绑定变量就可以办到。绑定变量（bind variable）是查询中的一个占位符。例如，要获取员工123的相应记录，可以使用以下查询：或者，也可以将绑定变量:empno设置为123，并执行以下查询：在典型的系统中，你可能只查询一次员工123，然后不再查询这个员工。之后，你可能会查询员工456，然后是员工789，如此等等。如果在查询中使用直接量（常量），那么每个查询都将是一个全新的查询，在数据库
11、看来以前从未见过，必须对查询进行解析、限定（命名解析）、安全性检查、优化等。简单地讲，就是你执行的每条不同的语句都要在执行时进行编译。第二个查询使用了一个绑定变量:empno，变量值在查询执行时提供。这个查询只编译一次，随后会把查询计划存储在一个共享池（库缓存）中，以便以后获取和重用这个查询计划。以上两个查询在性能和可扩缩性方面有很大差别，甚至可以说有天壤之别。从前面的描述应该能清楚地看到，与重用已解析的查询计划（称为软解析，soft parse）相比，解析包含有硬编码变量的语句（称为硬解析，hard parse）需要的时间更长，而且要消耗更多的资源。硬解析会减少系统能支持的用户数，但程度如何
12、不太明显。这部分取决于多耗费了多少资源，但更重要的因素是库缓存所用的闩定（latching）机制。硬解析一个查询时，数据库会更长时间地占用一种低级串行化设备，这称为闩（latch）。这些闩能保护Oracle共享内存中的数据结构不会同时被两个进程修改（否则，Oracle最后会得到遭到破坏的数据结构），而且如果有人正在修改数据结构，则不允许另外的人再来读取。对这些数据结构加闩的时间越长、越频繁，排队等待闩的进程就越多，等待队列也越长。你可能开始独占珍贵的资源。有时你的计算机显然利用不足，但是数据库中的所有应用都运行得非常慢。造成这种现象的原因可能是有人占据着某种串行化设备，而其他等待串行化设备的人
13、开始排队，因此你无法全速运行。数据库中只要有一个应用表现不佳，就会严重地影响所有其他应用的性能。如果只有一个小应用没有使用绑定变量，那么即使其他应用原本设计得很好，能适当地将已解析的SQL放在共享池中以备重用，但因为这个小应用的存在，过一段时间就会从共享池中删除已存储的SQL。这就使得这些设计得当的应用也必须再次硬解析SQL。真是一粒老鼠屎就能毁了一锅汤。如果使用绑定变量，无论是谁，只要提交引用同一对象的同一个查询，都会使用共享池中已编译的查询计划。这样你的子例程只编译一次就可以反复使用。这样做效率很高，这也正是数据库期望你采用的做法。你使用的资源会更少（软解析耗费的资源相当少），不仅如此，占
14、用闩的时间也更短，而且不再那么频繁地需要闩。这些都会改善应用的性能和可扩缩性。四、下面是实验和结论部分，先说结论1、 数据库参数是专业DBA设置的，基本上都采用oracle自动管理的方式，只设置一个内存值，由数据库自身管理各个参数的内存分配，IT支撑中心的要求是不要对生产系统（实际系统）做任何修改，除非先测试修改有没有副作用。2、增加参数值意味着CPU需在更大的空间中找数据，会造成CPU过忙，资源不能充分利用。3、要求应用人员使用绑定变量解决问题，是要求不是请求，没有商量余地。不是增加share pool的问题，增加内存会导致CPU同步增加，硬件扩容不是关键问题，关键问题时随意改动数据库参数配
15、置风险无法预知。 常见故障与不绑定变量有关 数据库等待事件出现大量latch等待（大部分时候是不绑定变量造成的），或者应用维护人员突然说运行什么东西share pool 报错，要DBA处理。 如果是结算、财务这类稳定的系统（版本不变、后台操作人员基本没有），这个时候DBA可以介入处理。 如果是计费、CRM这类系统，只要DBA排除oracle 软件bug的原因（概率比较小），值班人员找几个语句，告诉应用维护人员让他们自行调整就可以了。 实验一：绑定变量和不绑定变量的比较，空口无凭，用别人的实验数据说话1、环境准备SQL runstats.sql2、建立数据表SQL create table test (x int);Table created.3、不绑定变量的存储过程SQL create or replace procedure no_bindas begin for i in 1. 10000 loop execute immediate insert into test values (|i|); end loop; end;/Procedure created.4、绑定变量的存储过程create or replace procedure bind as
