适用于网工和物联网专业

期末考试会考

一、实验目的

二、实验内容

三、实验软件

四、实验步骤及数据记录

1. 权限管理

2. 数据库备份

3. 生成 AWR 报告

五、实验结论及思考题

六、总结及心得体会

七、对本实验过程及方法、手段的改进建议

一、实验目的

1、掌握系统权限、对象权限的授予和回收；

2、掌握使用数据泵的方法来备份及还原数据库；

3、熟悉利用 Oracle AWR 报告分析数据库性能。

二、实验内容

利用 DBA 用户进行 Oracle 数据库的系统权限、对象权限管理，利用数据泵

工具进行数据库数据的备份及恢复。生成 Oracle AWR 报告，并观测报告中的各

项参数，以此来进行数据库优化。

三、实验软件

Oracle 数据库

四、实验步骤及数据记录

1. 权限管理

使用 Oracle 用户登录进入 CentOS 系统桌面，用 sys 账户进入 sqlplus。

1）创建一个用户口令认证的数据库用户 usera_exer，口令为 usera，默认表空间为 USERS，默认临时表空间为 TEMP，USERS 表的配额为 10MB，初始状态为锁定状态。

图1 usera_exer的创建

2）创建一个口令认证的数据库用户 userb_exer，口令为 userb，默认表空间为 USERS，默认临时表空间为 TEMP，USERS 表的配额为 10MB，初始状态为默认状态。

图2 userb_exer的创建

3）为 usera_exer 用户授权 CREATE SESSION 系统权限、SCOTT.EMP 的SELECT 和 UPDATE 对象权限，同时允许该用户将获得的权限授予其他用户。

图3 usera_exer相关权限授权

4）将用户 usera_exer 的账户解锁。

图4 用户 usera_exer 的账户解锁

5）用 usera_exer 账户登录数据库（conn usera_exer/usera），查询SCOTT.EMP 中的数据。

图5 SCOTT.EMP 中的数据

6）将 SCOTT.EMP 的 SELECT 权限和 UPDATE 权限授予用户 userb_exer，但禁止用户 userb_exer 将获得的权限再授予其他用户。

图6 命令和结果截图

7）用 sys 账户登录数据库（conn /as sysdba），禁止用户 usera_exer 将获得的 CREATE SESSION 系统权限再授予其他用户。

图7 禁止权限

8）禁止用户 usera_exer 将获得的 SCOTT.EMP 的 SELECT 和 UPDATE 对象权限再授予其他用户。

图8 禁止用户usera_exer的权限

9）创建角色 rolea（口令为 rolea）和 roleb（口令为 roleb），将 CREATE TABLE权限、SCOTT.EMP 的 INSERT 和 DELETE 权限授予 rolea；将 CONNECT 和RESOURCE 角色授予 roleb。

图 9创建角色

10）将角色 rolea 和 roleb 授予用户 usera_exer。

图10 角色授予用户

2. 数据库备份

1）将权限 CREATE SESSION、CREATE TABLE、EXP_FULL_DATABASE、 IMP_FULL_DATABASE 授予用户 userb_exer。

图11 权限授予

2）使用 Oracle 用户在/home/Oracle_11g 下创建一个目录 imp_dir。

[Oracle@localhost ~]$ cd /home/oracle_11g/

[Oracle@localhost Oracle_11g]$ mkdir imp_dir

3）用 sys 账户进入 sqlplus，定义刚创建的 imp_dir 目录。

[Oracle@localhost Oracle_11g]$ sqlplus /nolog

SQL> conn /as sysdba

SQL> CREATE DIRECTORY imp_test AS '/home/Oracle_11g/imp_dir';

查看 Oracle 数据库的directory，截图记录查询结果。

SQL> select * from dba_directories;

图12 查看数据库的directory

将 imp_dir 目录的读写权限授权给 userb_exer 用户，

SQL> grant read,write on directory imp_test to userb_exer;

4）退出 sqlplus，在 oracle 用户下，使用 userb_exer 用户用 expdp 备份 scott 用户的所有表和所有数据，备份的文件名采用“实验者姓名拼音_日期”形式。

[Oracle@localhost ~]$ expdp userb_exer/userb DIRECTORY=imp_test SCHEMAS=scott DUMPFILE=zhangsan.scott_0831.dmp logfile= zhangsan_scott.0831.log

图13 执行结果记录

3. 生成 AWR 报告

用 sys 账户进入 sqlplus，运行脚本 awrrpt.sql 产生整个数据库的 AWR 报告。

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

要求：

1）输出报告的文件格式为 html

2）报告的监控天数为 1 天

3）报告针对的起始快照号和终止快照号包含最多 5 个最新快照

AWR 报告生成后，退出 sqlplus，用浏览器打开生成在当前目录下的 AWR报告文件，查看并截图记录能反映当前数据库性能的报告数据。

图14 AWR报告

由于AWR报告太长就不所有结果都列出来，上述只附上一些关键的指标。

五、实验结论及思考题

1、创建一个以自己姓名命名的数据库账户并授予对表的操作权限，可以对该表数据进行查询、更新、删除等操作，操作完成后收回对表的操作权限，再尝试对表数据重复之前的操作。截图记录所有操作命令及其结果。

图15 创建自己名字命名的数据库和授予权限

之后进行查询：

图16 查询结果

收回权限之后进行查询。

图17 进行权限的回收

图18 回收权限后查询截图

2、分析 Oracle AWR 报告（文件 awrrpt_1_51326_51330.html）中反映当前数据库性能的报告数据，判断当前数据库是否存在性能瓶颈，以及当前数据库需要优化的选项。

AWM报告老师会发

1、ELAPSED和DB TIME

DB TIME=CPU TIME+WAIT TIME

DB TIME>ELAPSED 说明数据库比较繁忙如DB TIME<ELAPSED 说明数据库比较空闲。

如果数据库繁忙。

CPU的负载程度可以使用下面公式：

CPU负载=DB TIME/（CPU数*ELAPSED）*100% 计算

2、Load Profile (REDO SIZE、LOGICAL READS、HARD PARSES、ROLLBACK)

Redo size：每秒/每事务产生的redo大小（单位字节），可标志数据库任务的繁重程序。其中Per Second表示每秒中产生的redo的字节数，Per Transaction表示每个事务产生的redo的字节数，可以通过后者可以看到事务的大小，协助判断是否commit次数太多。例如per second很大，而per transaction很小，说明commit次数太多。通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百k。

Logical reads：每秒/每事务逻辑读的块数（我们可以这样认为，block在内存中，我们每一次读一块内存，就相当于一次逻辑读），单位为块。

Executes：每秒/每事务SQL执行次数，包括用户执行的sql语句与系统执行的sql语句，表示一个系统SQL的繁忙程度。

Logical reads/Executes不会超过50，一般只有10左右。

Hard parses：其中硬解析的次数，如果硬解析次数太高，说明SQL重用率不高。例如超过100，基本都是由于不使用绑定变量所导致的，导致CPU使用率的问题，极有使得性能急剧下降。

Rollbacks：表示数据库中事务的回退率，如果不是因为业务本身的原因，通常应该小于10%为好，回退是一个很消耗资源的操作。

3、内存命中率相关指标

首先看整个实例的命中率，普通应用系统应该在90%以上。

Buffer Nowait% ：表示在数据缓冲区中获取buffer时，未进行等待的比率，越高越好。

buffer hit% ：表示进程从内存中找到数据块的比率，监视这个值是否发生重大变化比这个值本身更重要。对于一般系统，命中率通常在95%以上，如果此值低于80%，应该给数据库分配更多的内存，考虑加大db_cache_size。

Redo NoWai%t表示在LOG缓冲区获得BUFFER的未等待比例。如果太低（可参考90%阀值），考虑增加LOG BUFFER。

library hit%表示Oracle从Library Cache中检索到一个解析过的SQL或PL/SQL语句的比率，当应用程序调用SQL或存储过程时，Oracle检查Library Cache确定是否存在解析过的版本，如果存在，Oracle立即执行语句；如果不存在，Oracle解析此语句，并在Library Cache中为它分配共享SQL区。低的library hit ratio会导致过多的解析，增加CPU消耗，降低性能。Sql语句在库缓冲中能否找到相应的解析计划，如果library hit ratio低于90%，可能需要调大shared pool区，或检查是否有硬编码现象。

Latch Hit%：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可,表示内部结构维护锁命中率。要确保Latch Hit>99%，否则意味着Shared Pool latch争用，可能由于未共享的SQL，或者Library Cache太小，可使用绑定变更或调大Shared Pool解决。

Parse CPU to Parse Elapsd：表示解析实际运行时间/(解析实际运行时间+解析中等待资源时间)，越高越好。在实际繁忙的系统中，该值可能因为等待资源而不会太高。

Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。说明解析时间所占比率过高，需要考虑提高sql语句重用性。

Execute to Parse：是语句执行与分析的比例,表示sql语句解析后被重复执行的命中率，计算公式=100*（1-Parses/Executions）,如果该值偏小，说明分析（硬分析和软分析）的比例较大，快速分析较少，根据实际情况，可以考虑调整session_cached_cursors参数，有些报告中这个值是负的，看上去很奇怪，事实上这表示一个问题，sql如果被age out的话就可能出现这种情况，也就是sql老化，执行alter system flush shared_pool如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

Soft Parse%：

Soft Parse%：软解析的百分比（softs/softs+hards），近似当作SQL在共享区的命中率，SQL语句软解析占整个分析的命中率，如果低于95，需检查是否有硬编码现象，如果低于80，说明SQL语句基本没有重用性=soft/(soft+hard)。太低则需要调整应用使用绑定变量。

In-memory Sort：在内存中排序的比率，即有多少排序在内存中进行的，如果过低说明有大量的排序在临时表空间中进行，性能肯定不好，考虑调大PGA参数，sort_area_size。

4、共享内存池总体情况

Memory Usage %：表示共享池内存使用率，对于一个已经运行一段时间的数据库来说，共享池内存使用率，应该稳定在75%-90%间，如果太小，说明Shared Pool有浪费，而如果高于90，说明共享池中有争用，内存不足。

SQL with executions>1：执行次数大于1的SQL比率，如果此值太小的话要结合Parse，看看是不是硬编码现象，说明需要在应用中更多使用绑定变量，避免过多SQL解析。

Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。

5、前5/10个等待时间最长的事件

通常排序前几位的事件有如下几个：

db file scattered read等待事件是当SESSION等待multi-block I/O时发生的，通常是由于full table scans或 index fast full scans。如果在一般系统中，不应该有过多的全扫描操作，而应使用选择性好的索引操作。

db file sequential read等待意味着发生顺序I/O读等待（通常是单块读取到连续的内存区域中），如果这个等待非常严重，应该使用上一段的方法确定执行读操作的热点SEGMENT，然后通过对大表进行分区以减少I/O量，或者优化执行计划（通过使用存储大纲或执行数据分析）以避免单块读操作引起的sequential read等待。通过在批量应用中，DB file sequential read是很影响性能的事件，总是应当设法避免。

Log File Parallel Write事件是在等待LGWR进程将REDO记录从LOG 缓冲区写到联机日志文件时发生的。虽然写操作可能是并发的，但LGWR需要等待最后的I/O写到磁盘上才能认为并行写的完成，因此等待时间依赖于OS完成所有请求的时间。如果这个等待比较严重，可以通过将LOG文件移到更快的磁盘上或者条带化磁盘（减少争用）而降低这个等待。

Buffer Busy Waits事件是在一个SESSION需要访问BUFFER CACHE中的一个数据库块而又不能访问时发生的。缓冲区“busy”的两个原因是：1）另一个SESSION正在将数据块读进BUFFER。2）另一个SESSION正在以排它模式占用着这块被请求的BUFFER。

Log File Sync事件，当用户SESSION执行事务操作（COMMIT或ROLLBACK等）后，会通知 LGWR进程将所需要的所有REDO信息从LOG BUFFER写到LOG文件，在用户SESSION等待LGWR返回安全写入磁盘的通知时发生此等待。

Enqueue Waits是串行访问本地资源的本锁，表明正在等待一个被其它SESSION（一个或多个）以排它模式锁住的资源。减少这种等待的方法依赖于生产等待的锁类型。导致Enqueue等待的主要锁类型有三种：TX（事务锁）, TM D（ML锁）和ST（空间管理锁）。

enq:TX-index contention是索引分割事件。当事务修改索引中的数据时,而相关索引块没有足够的空间的时候,就会发生索引块的分割,在分割的过程中前台进程需要等待分割完毕才能继续操作。如果这个时候其他会话也要修改这个索引块的数据,那么将会出现索引块的竞争。一般索引块的分割持有资源和释放非常短,并不会对数据库造成严重的影响。但是对表操作并发量很大的情况下可能导致严重的竞争。

buffer exterminate等待事件通常发生SGA自动管理内存组件的时候。是当buffer cache中的部分空间正进行动态回缩时，有会话试图访问buffer cache中被选择空间释放的granule中的data block时，就会发生buffer exterminate等待。当buffer被释放（比如从buffer cache hash chain，LRU chain上移除）后，等待的会话就能够重载该block到剩余的一个db cache granule中去，然后其他会话就可以通过hash查找找到新的该block的buffer address。