Oracle程序员面试分类模拟12

Oracle程序员面试分类模拟12简答题1.

什么是检查点?如何调优检查点?正确答案：(1)什么是检查点?一般所说的检查点是一种将内存中的已修改数据块与磁盘上的数据文件进行同步的数据库事件(Eve（江南博哥）nt)，是Oracle在数据库一致性关闭、实例恢复和Oracle基本操作不可缺少的机制。Oracle通过检查点确保被事务修改过的数据可以被同步至磁盘。检查点信息(CheckpointInformation)包含检查点位置(CheckpointPosition)、SCN、联机Redo日志中开始恢复的位置等。当检查点发生时，CKPT通知DBWn进程将脏块(DirtyBuffer)写出到数据文件上，并更新数据文件头及控制文件上的检查点信息。注意，CKPT进程不负责BufferCache中的脏数据写入到磁盘中，该工作由DBWn负责：CKPT进程也不负责将RedoLogBuffer中的数据写入到联机Redo日志文件中，该工作由LGWR负责。由于Oracle事务在提交的时候不会将已修改数据块同步写入磁盘上，所以，CKPT进程负责更新控制文件和数据文件头的检查点信息和触发DBWn写脏数据到磁盘。CKPT执行越频繁，DBWn写出就越频繁。

检查点位置(CheckpointPosition)由在数据缓冲池中存在的最老的脏数据位置决定，并且检查点的信息存储在控制文件和数据文件头中。控制文件中记录的检查点位置是实例恢复的起点。在检查点位置前的Redo记录，其对应的BufferCache中的DirtyBuffer已经被写进了数据文件，在此位置后的Redo记录，所对应数据脏块有可能还在内存中。如果发生了实例崩溃，只需要在日志文件中找到检查点位置(LowCacheRBA)，从此处开始应用所有的Redo日志文件，就完成了前滚操作。

(2)检查点的作用

检查点的主要目的是以对数据库的日常操作影响最小的方式刷新脏块，检查点主要有两个作用：

1)确保数据库的一致性，包含两个方面，第一，确保BufferCache中的DirtyBuffer能有规律地定期写入磁盘，这样在系统或数据库出现故障时就不会丢失数据；第二，确保数据库在一致性关闭期间可以将所有已提交了的数据写入磁盘。

2)实现更快的数据库恢复，主要是缩短实例恢复的时间。实例恢复要把实例异常关闭前没有写出到硬盘的脏数据通过日志进行恢复，只需要重新应用控制文件中记录的检查点位置之后的联机Redo日志条目即可进行恢复。如果脏块过多，那么实例恢复的时间也会很长，所以，检查点的发生可以减少脏块的数量，从而提高实例恢复的时间。

(3)检查点的分类CKPT进程负责将检查点信息写入到数据文件头中和控制文件中，包括几种类型的检查点，见表。

(4)有关检查点的几个概念

1)1RBA(RedoBlockAddress)、LRBA(LowRBA)、HRBA(HighRBA)。RBA就是Redo日志块的地址，相当于数据文件中的ROWID，通过RBA可以定位Redo日志块。RBA由3部分组成：

①日志文件序列号(4字节)，根据这个可以找到对应的日志文件地址。

②日志文件块编号(4字节)，根据这个可以找到对应日志条目所在的日志文件块。

③Redo日志记录在日志块中的起始偏移字节数(2字节)，根据这个可以找到对应的日志条目。

在BufferCache中，一个脏块第一次被更新的时候会产生Redo日志记录，该记录在Redo日志文件中所对应的位置就称为LRBA；若数据库再次更新该脏块的时候也会产生Redo日志记录，则该记录在Redo日志文件中所对应的位置就称为HRBA。

例如，用户发出了一条UPDATE命令，更新了块A，块A现在变成了脏块，Oracle会为它生成一条Redo记录。这条Redo记录在Redo日志文件中的位置就是RBA。过了一会儿，假如块A依然还是脏块，此时，用户又发出一条更新块A的命令，这又会生成一条Redo记录。第一条更新命令对应的Redo记录的RBA被称为块A的LRBA(LowRBA)，第二条更新命令对应的RBA被称为HRBA(HighRBA)。

2)CheckpointRBA。当一个检查点事件发生的时候，CKPT进程会记录下当时所写的Redo日志块的地址即RBA，此时记录的RBA被称为CheckpointRBA。从上一个CheckpointRBA到当前的CheckpointRBA之间的日志所保护的BufferCache中的脏块接下来将会被写入到数据文件当中去。

3)检查点队列(CheckpointQueue，CKPTQ)。Oracle将所有在BufferCache中被修改的脏块按照LRBA的顺序连接起来就组成了一个检查点队列(CKPTQ)，这个队列主要记录了BufferCache第一次发生变化的时间顺序，然后由DBWn进程根据CKPTQ顺序将脏块写入到数据文件中，这样保证了先发生变更的Buffer能先被写入到数据文件中。

Oracle引入检查点队列(CKPTQ)是为了使检查点在BufferCache较大的情况下依然有效工作(既要保证数据完全恢复，又要尽量快速恢复)，该队列上存放的都是脏块所对应的BufferHeader。每次DBWn写脏块时，也是从CKPTQ上扫描脏块，并将这些脏块实际写入数据文件。检查点队列上的BufferHeader是按照数据块第一次被修改的时间的先后顺序来排列的。越早修改的数据块的BufferHeaderS)在越前面，同时如果一个数据块被修改了多次的话，那么在该链表上也只出现一次，其在CKPTQ上的位置不会发生变化。而且，检查点队列上的BufferHeader还记录了脏块在第一次被修改时，所对应的Redo条目在Redo日志文件中的地址，也就是LRBA，所以可以认为检查点队列上的脏块是按照LRBA排列的，从而保证最早更改的数据块能够尽快从内存写入数据文件。

DBWn每到一定的时机，就会被触发，沿着检查点队列(CKPTQ)的顺序刷新脏块，同时CKPT进程监控着检查点队列的长度，当检查点队列的长度达到一定限制时，CKPT会通知DBWn写脏块。CKPT会根据几个参数的设置和I/O的速度以及繁忙程度，计算出来一个TargetRBA(目标RBA)，DBWn会沿着检查点队列，按照DirtyBuffer的LRBA顺序将所有TargetRBA之前对应的脏块从内存写入数据磁盘文件。当CKPT进程通知完DBWn后，CKPT的任务就结束了，它并不会等待DBWn写完所有的TargetRBA之前的脏块。因此这里CKPT只是起到了一个通知DBWn进程写入的作用。

4)文件检查点队列(FileQueue，FILEQ)。文件检查点队列提高了表空间检查点(TablespaceCheckpoint)的性能，每个DirtyBuffer同时链接到CKPTQ和FILEQ，CKPTQ包含实例所有需要执行检查点的Buffer，FILEQ包含属于特定文件需要执行检查点的Buffer。每个文件都包含一个文件队列，在执行表空间检查点请求时需要使用FILEQ，通常当对表空间执行OFFLINE等操作时会触发表空间检查点。

5)OnDiskRBA。“OnDiskRBA”指向Redo日志文件里最新的(最后的)一条Redo日志条目，它是CKPT进程从某一个脏块里读取过来的，在进行恢复时应用Redo至少要达到这个值。在实例崩溃后，再次启动数据库，Oracle会到控制文件中读取LRBA，这就是检查点位置。从此处开始应用Redo日志，应用到OnDiskRBA的位置，OnDiskRBA是Oracle前滚操作的终点。如果某条Redo记录的RBA高于OnDiskRBA，那么说明此Redo记录还没有被LGWR写进日志文件中，还驻留在LogBuffer中，所以，崩溃发生时，它是不可能被恢复的。

(5)增量检查点

为了能够尽量减少实例崩溃后恢复的时间，Oracle还引入了增量检查点(IncrementalCheckpoint)，从而增加了检查点启动的次数。在执行增量检查点时，DBWn从检查点队列按照LRBA顺序写出，先修改的数据可以被按优先顺序写出，全局检查点因此可以不被增进。同时CKPT进程阶段性使用轻量级控制文件更新协议将当前LRBA写入控制文件，CKPT在进行轻量级更新时，不会更新控制文件中数据文件检查点信息(数据库SCN以及数据文件条目的SCN信息)以及数据文件头信息，而只是每3s由CKPT进程检查DBWn写进度并更新控制文件中的检查点的位置信息(LRBA)。完全检查点会将检查点信息写入到控制文件以及数据文件头中；增量检查点只会将LRBA信息写入到控制文件中。

通过增量检查点，数据库可以将全部写出改为增量渐进写出，从而极大减少对于数据库性能的影响，而检查点队列进一步将RBA和检查点关联起来，从而可以通过检查点确定实例恢复的起点。

增量检查点的几个作用：

1)CKPT每3s一次的检查DBWn写进度并在控制文件中记录检查点位置(LRBA)。注意，增量检查点并不会去更新数据文件头以及控制文件中数据库SCN及数据文件条目的SCN信息。

2)CKPT定期触发DBWn去写CKPTQ中的脏数据。

(6)检查点调优检查点的主要任务就是催促DBWn刷新脏块，如果DBWn刷新脏块时的等待事件太多，那么就说明脏块太多、存储设备的写速度太慢，或者就是增量检查点的频率设置不合理。DBWn写脏块的等待事件是dbfileparallelwrite。如果系统增量检查点频率很低，系统大量产生该事件，在排除了存储设备写性能的问题后，那么应该将增量检查点频率设置得高一些。反之，如果增量检查点频率本身很高，若出现了dbfileparallelwrite事件，则说明检查点频率太高了。

1)与增量检查点相关的参数。优化检查点涉及到下面4个关键初始化参数：

①FAST_START_MTTR_TARGET。

②LOG_CHECKPOINT_INTERVAL。

③LOG_CHECKPOINT_TIMEOUT。

④LOG_CHECKPOINTS_TO_ALERT。

需要注意的是，日志文件切换将始终覆盖由以上4个参数引起的检查点。这4个参数的详解见表。

需要注意的是，除了上表中列出的4个初始化参数外，Oracle内部事实上还将Redo日志文件末尾前面90%的位置设为检查点位置(90%ofSmallestRedoLog)。在每个Redo日志中，这几个参数指定的位置可能不尽相同，Oracle将离日志文件末尾最近的那个位置确认为检查点位置。

在Oracle9i后，对检查点频率建议只设置FAST_START_MTTR_TARGET。当然，根据需要也可以通过参数LOG_CHECKPOINTT_IMEOUT设置一个脏块保持脏状态的最大时间，而参数LOG_CHECKPOINT_INTERVAL建议不再使用，参数FAST_START_IO_TARGET已废弃。

2)Redo日志和检查点。在每次切换日志时都会发生一次Thread检查点。如果上一个检查点已在进行中，那么由日志切换引起的检查点将覆盖当前检查点。此时就需要大小合适的Redo日志，以避免因频繁的日志切换而引起不必要的检查点。另外，增量检查点目标和日志尾之间的间隔也会受“最小在线日志文件大小的90%”设置所限制。这样可确保在大多数情况下，日志切换不必等待检查点。因此，日志文件大小应配置得足够大。一个经验值是，最多每15～20min切换一次日志。日志文件过小会增加检查点活动并降低数据库的性能。Oracle建议用户将所有在线日志文件设置为同一大小，且每个线程至少拥有两个日志组。若要监视日志切换发生的速度以及随后的检查点发生的速度，则告警(ALERT)日志是一个很有价值的工具。

以下是通过ALERT日志发现日志切换过于频繁的示例：

如果Redo日志每3min切换一次，那么就会明显感觉到数据库性能降低了。这表明Redo日志不够大，不能有效地处理该事务负载。

有时候在告警日志(alert_$ORACLE_SID.log)文件中可以看到以下消息：

那么，在告警日志中的“Cannotallocatenewlog”和“Checkpointnotcomplete”是什么含义呢?“Cannotallocatenewlog”表示无法分配新日志，“CheckpointnotComplete”表示检查点未完成。这两个信息表明Oracle希望重新使用某个Redo日志文件，但当前的检查点位置仍位于该日志中。在这种情况下，Oracle必须等到检查点位置通过该日志。由于增量检查点目标相对于当前日志尾的滞后绝不会超过最小日志文件大小的90%以上，因此，如果DBWn写入速度过慢，或者在日志全满之前发生日志切换，或者日志文件过小，就会遇到这种情况。在数据库等待检查点时，Redo生成过程会停止，直到完成日志切换。

(7)RAC中的检查点集群环境中的检查点可以分为：

1)局部检查点：单个实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件，触发命令为：

这两条命令都可以显式地触发一个局部检查点。注意，命令“ALTERSYSTEMSWITCHLOGFILE;”只会影响当前的数据库实例。

2)全局检查点：RAC数据库的所有实例执行数据库所有数据文件的一个检查点操作，属于此实例的全部脏缓存区写入数据文件，触发命令为：

这两条命令都可以显式地触发一个全局检查点。

对于全局和局部检查点，有如下的结论：

①对于单节点数据库，由于只有一个Thread，所以由日志切换引起的对当前Thread的检查点实质上就是整个数据库的检查点，所以日志切换会导致V$DATAFILE和V$DATAFILE_HEADER中的CHECKPOINT_CHANGE#改变，但是必须要等检查点完成以后才会变成最新的值。

②对于RAC数据库，由于至少存在两个Thread，所以对单一Thread的日志切换并不会触发V$DATAFILE和V$DATAFILE_HEADER中的CHECKPOINT_CHANGE#的改变。原因是其他节点可能存在在此检查点SCN之前的脏块，所以对于数据文件(或者是数据库)来说，这并不是一个完整的DATABASE级的检查点。在RAC中，只有所有节点间的全局检查点(GlobalCheckpoint)才会导致发V$DATAFILE和V$DATAFILE_HEADER中的CHECKPOINT_CHANGE#的变化。

③在RAC中，对于Thread的CHECKPOINT_CHANGE#，可以通过GV$THREAD来查询。

(8)视图

1)V$DATAFILE_HEADER查看数据文件的完全检查点信息。

2)V$INSTANCE_RECOVERY查看FAST_START_MTTR_TARGET设置以及系统MTTR相关信息。

3)X$BH用于查看脏块的LRBA和HRBA。

4)X$TARGETRBA查看增量检查点RBA，TargetRBA和OnDiskRBA。

5)X$KCCCP查看增量检查点RBA、TargetRBA的信息。

6)X$KCCRT完全检查点的RBA信息。

2.

数据库的启动经历几个过程?正确答案：Oracle数据库的启动，严格来说应该是实例的启动，数据库仅仅是在实例启动后进行装载。Oracle数据库启动的过程被划分为几个不同的步骤，在不同的启动过程中，可以对其实现不同的操作。

启动命令：STARTUP[FORCE][RESTRICT][PFILE=...][NOMOUNT][MOUNT][OPEN]

启动过程：NOMOUNT---＞MOUNT--＞OPEN，详细情况见表。

打开数据库的几种特殊方式：

(1)只读模式：STARTUPOPENREADONLY；若当前数据库在MOUNT状态，则执行ALTERDATABASEOPENREADONLY;。

(2)受限模式有时进行数据库维护，希望一般的用户不能登录。可以启动到该模式，在这种模式下只有用户具有RESTRICTEDSESSION权限的用户才可登录到数据库。

1)启动方法：STARTUPRESTRICT;。

2)取消受限：ALTERSYSTEMDISABLERESTRICTEDSESSION;。

数据库的关闭也有一些参数需要注意，关刚命令为：

其中，SHUTDOWN不带参数将缺省为NORMAL。一般情况下，关闭数据库都使用“SHUTDOWNIMMEDIATE”命令。这几个参数的区别见表。

3.

给出数据库正常启动所经历的几种状态?正确答案：数据库正常启动经历如下所示的3个阶段：

1)STARTUPNOMOUNT——数据库实例启动。

2)STARTUPMOUNT——数据库装载。

3)STARTUPOPEN——数据库打开。

4.

Oracle10g和11g告警日志文件的位置在哪里?正确答案：作为一名DBA，必须知道告警日志是什么，在何处。实时的监控数据库的告警日志是必须进行的工作。监控并且根据不同的告警级别，通过邮件或短信发送告警信息给DBA，这可以帮助DBA及时了解数据库的变化与异常，及时响应并介入处理。

告警日志文件有两种类型，一种是纯文本格式的，另外一种是xml文件格式的，平时查看最多的是纯文本格式的告警日志。告警日志的内容包含：消息和错误的类型、ORA-600内部错误、ORA-1578块损坏错误、ORA-12012作业队列错误、实例启动关闭、恢复等信息、特定的DDL命令、影响表空间、数据文件及回滚段的命令、可持续的命令被挂起、LGWR不能写入到日志文件、归档进程启动信息、调度进程的相关信息和动态参数的修改信息等。

无论是Oracle10g还是11g，其告警日志的位置都可以由参数BACKGROUND_DUMP_DEST来查询，只不过在Oracle11g中位置有所变化。在Oracle10g中，告警日志一般在$ORACLE_BASE/admin/$ORACLE_SID/bdump目录下：

在Oracle11g中，告警日志一般在$ORACLE_BASE/diag/rdbms/$DBNAME/$ORACLE_SID/trace目录下。

从Oracle12.1.0.1开始，参数BACKGROUND_DUMP_DEST已废弃，告警日志的位置应该由以下SQL来查询：

需要注意的是，该SQL也适用于Oracle11g的版本。

由于告警日志按时间的先后顺序不断累积存储，久而久之，势必造成告警日志的过大，难以维护，查找相关的信息也不方便。另外，若告警日志超大，也会严重影响系统的性能。这里提供3种办法来管理告警日志：①使用外部表方式来管理告警日志将大大简化维护工作量，也可以更直观地获取所需的信息。②视图V$DIAG_ALERT_EXT对应的基表里存储了告警日志的内容，可以根据该视图将告警日志的内容存储在历史表中。③利用SHELL脚本定时将告警日志进行备份，防止告警日志过大而影响系统性能。

5.

PFILE和SPFILE的区别是什么?正确答案：参数文件(ParameterFile)也称为初始化文件，它主要用来记录数据库的配置文件，在数据库启动时，Oracle读取参数文件，并根据参数文件中的参数设置来配置数据库，如内存的分配，允许打开的进程数和会话数等。Oracle的参数文件主要分为2类：PFILE(ParameterFile)和SPFILE(ServerParameterFile)。SPFILE和PFILE的区别见表。

需要注意的是，Oracle数据库在启动时寻找参数文件的顺序如下所示，如果这些文件都不存在，那么Oracle会报错：

6.

简述Oracle数据库的参数正确答案：Oracle数据库根据SPEILE或PFILE中设置的参数来启动数据库。Oracle中的参数(下图)根据系统使用情况可以简单分为两大类：

Oracle参数分类

1)普通参数：Oracle系统正常使用的一些参数。

2)非凡参数：包括4种，过时参数、强调参数、隐含参数及推导参数。

7.

如何列举某个用户下所有表的注释及列的注释?正确答案：可以使用DBA_TAB_COMMENTS视图来查询表的注释，使用DBA_COL_COMMENTS视图来查询列的注释。

8.

Oracle用户的状态有几种?分别表示什么含义?正确答案：Oracle用户的状态是由密码来决定的，而Oracle中的密码是由PROFILE来配置的。PROFILE是口令限制、资源限制的命令集合。当建立数据库时，Oracle会自动建立名称为DEFAULT的PROFILE。当创建用户而没有指定PROFILE选项时，Oracle就会将DEFAULT分配给用户。

通过如下的命令可以查出与密码相关的PROFILE的值：

每个参数的含义如下所示：

(1)FAILED_LOGIN_ATTEMPTS设定登录到Oracle数据库时可以失败的次数。一旦某用户尝试登录数据库的次数达到该值时，该用户的账户就被锁定，只能由DBA解锁。

(2)PASSWORD_LIFE_TIME设定口令的有效时间(天数)，一旦超过这一时间，必须重新设口令。缺省为UNLIMITED。

(3)PASSWORD_REUSE_TIME许多系统不许用户重新启用过去用过的口令。该资源项设定了一个失效口令要经过多少天，用户才可以重新使用该口令，默认周期为180天。

(4)PASSWORD_REUSE_MAX重新启用一个先前用过的口令前必须对该口令进行重新设置的次数(重复用的次数)。

(5)PASSWORD_LOCK_TIME设定账户被锁定的天数(当登录失败达到FAILED_LOGIN_ATTEMPTS时)。

(6)PASSWORD_GRACE_TIME设定在口令失效前，给予的重新设置该口令的宽限天数。当口令失效之后，在登录时会出现警告信息显示该天数。如果没有在宽限天数内修改口令，口令将失效。

(7)PASSWORD_VERITY_FUNCTION该资源项允许调用一个PL/SQL来验证口令。Oracle已提供该应用的脚本，为$ORACLE_HOME/rdbms/admin/utlpwdmg.sql。但是，用户可以制定自己的验证脚本。该参数的设定就是PL/SQL函数的名称，默认为NULL。

用户的状态可以由以下脚本查询获得：

以上九种可以分为两大类：①基本状态；②组合状态。前五种是基本状态，后四种是组合状态。具体分类如图所示。

用户状态的分类

每种状态的解释见表。

在Oracle中，若用户的密码变为锁定状态[LOCKED、LOCKED(TIMED)1时，DBA可以直接执行“ALTERUSER用户名ACCOUNTUNLOCK”来解锁。但是，如果用户的状态变成过期状态[EXPIRED、EXPIRED(GRACE)]，那么DBA必须要更改用户的密码账户才能重新使用。但有些时候，因为各种原因并不知道原密码的明文是什么，这时候可以有如下两种办法来更新密码。

(1)用原密码的密文来更改密码

在Oracle10g中，DBAUSERS视图的PASSWORD字段提供了密码的密文形式，而在Oracle11g中，该字段被弃用了，内容为空，但是在基表USER$中的PASSWORD字段依然有记录密文形式。另外，可以通过DBMS_METADATA.GET_DDL包或者expdp.exp命令来获取创建用户的语句从而获取密码的密文形式。如下的SQL即获取密码的密文形式：

获取了密码的密文后就可以用如下的命令来修改了，注意：使用密文的命令中多了一个VALUES关键字：

所以，即使不知道用户的原密码是什么，也可以用它的密文来更改密码。这样既保持了密码不改变，又可以把EXPIRED的状态更改掉。在MOS文档ID1543668.1中也有命令可以直接获取密码。

(2)直接更新USER$基表

不管用户的状态是什么，通过更新USER$表可以让用户处于OPEN状态。

9.

用户的权限分为哪几类?如何导出用户的权限?正确答案：权限是指执行特定类型SQL命令或访问其他用户对象的权利，包括系统权限(SystemPrivilege)、对象权限(ObjectPrivilege)、角色权限(RolePrivilege)、列权限(ColumnPr]vilege)。

(1)系统权限

系统权限是指执行特定类型SQL命令的权利。它用于控制用户可以执行的一个或是一组数据库操作。通过查询系统表SYSTEM_PRIVILEGE_MAP可以获取所有系统权限，查询视图DBA_SYS_PRIVS可以获取每个用户拥有的系统权限。以下示例显示了SCOTT用户具有的系统权限：

一般情况，授予系统权限是由DBA完成的，如果用其他用户来授予系统权限，那么要求该用户必须具有GRANTANYPRIVILEGE的系统权限。在授予系统权限时，可以带有WITHADMINOPTION选项，这样，被授予权限的用户或角色还可以将该系统权限授予其他的用户或角色。

(2)对象权限

对象权限是指访问其他用户(SCHEMA)对象的权利，用户可以直接访问自己用户的对象，但是如果要访问别的用户的对象，那么必须具有该对象的相应权限。常用的对象权限有：ALTER、DELETE、SELECT、INSERT、UPDATE等。通过数据字段视图DBA_TAB_PRIVS可以查询用户或角色所具有的对象权限。下列示例列举出了所有的对象权限的种类：

可以单独赋权，也可以多个权限用逗号隔开：

也可以使用ALL来赋权：

(3)列权限

可以基于列进行赋权，只不过只能赋予INSERT、REFERENCES和UPDATE的权限，举例如下：

基于列的权限可以查询DBA_COL_PRIVS视图。

(4)角色权限

角色即用户权限的集合，可以对用户直接赋予某一个角色，这样，该用户就拥有了角色的所有权限。如果想查询角色所拥有的权限，那么可以通过视图DBA_SYS_PRIVS来查询；如果想查询某个用户拥有哪些角色，那么可以通过视图DBA_ROLE_PRIVS来查询。

角色权限需要注意默认角色(DefaultRole)的问题。一个用户一旦被赋予某个角色之后，其默认角色为YES，即角色权限处于激活状态，该角色拥有的权限是生效的；若默认角色为NO，则代表目标用户被赋予了某个角色，但是该角色拥有的权限并没有生效。可以使用如下SQL语句让角色生效：

(5)如何获取用户的权限

若要获取一个用户的角色、系统权限、对象权限以及列权限，则可以通过以上介绍的数据字典视图来获取也可以通过DBMS_METADATA.GET_GRANTED_DDL来获取。

若使用SYS用户创建了如下的用户LHRSYS并赋予相应的权限：

既可以通过数据字典来编写程序，也可以创建视图来获取一个用户的所有权限。通过视图VW_USER_PRIVS_LHR(视图内容参考随书提供的pdf文档)来直接查询某个用户的权限：

通过系统包DBMS_METADATA.GET_DDL也可以获取用户的权限信息，如下：

将结果拷贝出来简单地用文本编辑工具编辑后即可运行。

另外还可以通过exp或expdp来获取用户的权限，这里不再演示。

10.

下列SQL语句共创建了多少个段?

正确答案：创建了0个或4个段。

如果数据库环境是Oracle11g，且参数DEFERRED_SEGMENT_CREATION的值为TRUE(默认为TRUE，表示开启了延迟段创建)，那么这个时候上面的SQL语句不会创建任何段。

如果数据库环境是Oracle10g或者数据库环境是Oracle11g且数据库参数DEFERRED_SEGMENT_