중국 전자 과학 기술 대학교 데이터베이스 및 소프트웨어 공학 실험 5

네트워크공학, 사물인터넷 전공자에 적용 가능

최종 시험

1. 실험 목적

2. 실험적 내용

7. 실험 과정, 방법 및 수단 개선을 위한 제안

1. 실험 목적

1. 시스템 권한 및 개체 권한 부여 및 재활용을 마스터합니다.

2. 데이터 펌프를 사용하여 데이터베이스를 백업하고 복원하는 방법을 마스터합니다.

3. Oracle AWR 보고서를 사용하여 데이터베이스 성능을 분석하는 방법을 익히십시오.

2. 실험적 내용

DBA 사용자를 이용하여 Oracle 데이터베이스의 시스템 권한 및 객체 권한을 관리하고 Data Pump를 사용합니다.

데이터베이스 데이터의 백업 및 복구 도구입니다. Oracle AWR 보고서를 생성하고 다양한 관찰

데이터베이스를 최적화하기 위한 매개변수입니다.

3. 실험 소프트웨어

오라클 데이터베이스

4. 실험 절차 및 데이터 기록

1. 권한 관리

Oracle 사용자를 사용하여 CentOS 시스템 데스크탑에 로그인하고, sys 계정을 사용하여 sqlplus를 입력합니다.

1) 비밀번호 usera를 사용하여 비밀번호로 인증된 데이터베이스 사용자 usera_exer를 생성합니다. 기본 테이블스페이스는 USERS, 기본 임시 테이블스페이스는 TEMP, USERS 테이블의 할당량은 10MB이고 초기 상태는 잠겨 있습니다.

그림 1 usera_exer 생성

2) 비밀번호가 userb인 비밀번호로 인증된 데이터베이스 사용자 userb_exer를 생성합니다. 기본 테이블스페이스는 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) userb_exer 사용자에게 SCOTT.EMP의 SELECT 권한과 UPDATE 권한을 부여하되, 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) usera_exer 사용자에게 rolea 및 roleb 역할을 부여합니다.

그림 10 사용자에게 부여된 역할

2. 데이터베이스 백업

1) userb_exer 사용자에게 CREATE SESSION, CREATE TABLE, EXP_FULL_DATABASE, IMP_FULL_DATABASE 권한을 부여합니다.

그림 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> 디렉토리 생성 imp_test AS '/home/Oracle_11g/imp_dir';

Oracle 데이터베이스의 디렉토리를 보고스크린샷을 찍고 쿼리 결과를 기록합니다.

SQL> dba_directories에서 *를 선택하십시오.

그림 12 데이터베이스의 디렉터리 보기

userb_exer 사용자에게 imp_dir 디렉터리의 읽기 및 쓰기 권한을 부여합니다.

SQL> userb_exer에게 imp_test 디렉토리에 대한 읽기, 쓰기 권한을 부여합니다.

4) sqlplus를 종료하고 oracle 사용자 아래에서 userb_exer 사용자를 사용하여 expdp를 사용하여 scott 사용자의 모든 테이블과 모든 데이터를 백업합니다. 백업 파일 이름은 "실험자 이름 Pinyin_Date" 형식입니다.

[Oracle@localhost ~]$ expdp userb_exer/userb DIRECTORY=imp_test SCHEMAS=scott DUMPFILE=zhangsan.scott_0831.dmp 로그 파일= 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 보고서가 너무 길어서 전체 결과가 기재되지는 않았으며, 위에는 일부 주요 지표만 첨부하였습니다.

5. 실험적 결론 및 질문

1. 자신의 이름을 딴 데이터베이스 계정을 생성하고 테이블에 대한 작업 권한을 부여합니다. 테이블 데이터에 대한 쿼리, 업데이트, 삭제 등의 작업을 수행할 수 있습니다. 작업이 완료된 후 테이블에 대한 작업 권한을 취소합니다. 다시 시도해 보세요. 테이블 데이터에 대해 이전 작업을 반복하세요. 스크린샷은모든 작업 명령과 그 결과를 기록합니다.

그림 15 자신의 이름으로 데이터베이스를 생성하고 권한을 부여합니다.

그런 다음 쿼리하십시오.

그림 16 쿼리 결과

권한 철회 후 질의합니다.

사진17개 재활용 권한

그림 18 권한 복구 후 쿼리 스크린샷

2. Oracle AWR 보고서(파일 awrrpt_1_51326_51330.html)에서 현재 데이터베이스 성능을 반영하는 보고서 데이터를 분석하여 현재 데이터베이스에 성능 병목 현상이 있는지 여부와 현재 데이터베이스에 최적화해야 하는 옵션을 확인합니다.

AWM 보고서 교사가 보내드립니다.

1、경과됨및DB 시간

DB 시간=CPU 시간+대기 시간

DB TIME>ELAPSED는 데이터베이스가 상대적으로 바쁜 상태를 의미하며, 예를 들어 DB TIME

데이터베이스가 바쁜 경우.

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。

六、总结及心得体会

实验中遇到的问题以及解决办法：

1.在一开始进入Oracle数据库进行操作的时候，进入sqlplus之后也要先启动数据库，才能正常进行命令的输入；

2. expdp备份scott用户的所有表和所有数据时候，一开始会出现错误，如下：

图19 错误截图

解决方案：

图20 解决方案

3.在最后生成AWR报告时候，快照起始和结束要连续。

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

1. 在expdp 备份 scott用户的所有表和所有数据的时候，可能会出现报错，实验指导书可以指明一下。

2.对快照的ID进行一些说明，防止学生在进行到输入快照的那一步出错，不知如何解决。