Oracle 11g中的IO Calibrate(IO校準)--Automatic Degree of Parallelism(DOP)

lhrbest發表於2017-12-14

Oracle 11g中的IO Calibrate(IO校準)--Automatic Degree of Parallelism(DOP)




 Oracle 11g中的IO Calibrate(IO校準) 

轉載自:http://blog.itpub.net/17203031/viewspace-1063523/

Oracle資料庫發展到今天,“IO為王”已經是一種發展方向趨勢。ExtraData一體機的重要特色之一就是最大程度的發揮IO能力、提高IO吞吐量。

相比CPU和記憶體,IO儲存有其特殊性。我們討論IO,通常成為I/O棧(I/O Stack)。I/O棧設計的物件是一系列關鍵元件層,包括HBAStorage SwitchesStorage ArrayPhysical Disks。這些物件共同合力,才能形成系統整體的IO能力。

四層關鍵元件,共同形成“木桶效應”。只要有一個層面存在不足,必然成為IO中的短板。I/O難調,也就是在這個方面。但是對於Oracle而言,我們需要關注的是IO整體效能,也就是整體的效果。

Oracle 11g有兩個對於效能方面的測試工具,一個就是RATReal Application Test),另一個就是IO校準(Calibrate IO)。RAT是一種負載重演元件,當進行系統軟硬體升級的時候,我們一個很關注的問題是:此次變化能否提升系統效能、能提升多少,會不會有新的瓶頸。這個在過去是不能實現的,只能夠在升級之後通過實踐去發現。但是RAT可以捕獲實際系統負載情況,將其在新環境下進行重演,並且進行度量比較。IO調教的作用也是IO負載模擬,從而判斷出實際真實的系統IO情況。

本篇我們就介紹IO校準特性。

 

1、發現IO校準

 

首先聊聊為什麼要進行校準。IO是一個多元件共同影響的統一體,多個元件之間大部分情況下是不能夠完全如同理想情況下工作的。所以需要進行硬體標準指標和實際情況之間進行校準,來獲取準確的IO資料。

獲取精確IO有什麼用途呢?根源還是Oracle自動化和智慧化的需要。進入11g之後,Oracle向智慧化的步子是在加快的過程。OracleCBO開始,進行自動化並行決策的Auto DOP就需要IO校準的資訊。

 

2、配置IO校準

 

我們進行配置過程,首先選擇Oracle 11gR2進行測試。

 

SQL> select * from v$version;

 

BANNER

---------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production

PL/SQL Release 11.2.0.3.0 - Production

CORE 11.2.0.3.0 Production

 

TNS for Linux: Version 11.2.0.3.0 - Production

NLSRTL Version 11.2.0.3.0 - Production

 

11g中有一個檢視v$io_calibration_status,記錄了系統進行校準過程資訊。和統計量不同,Oracle是不會自動進行IO校準的,而需要DBA手工完成。

 

SQL> select * from v$io_calibration_status;

STATUS        CALIBRATION_TIME

------------- --------------------------------------------------------------------------------

NOT AVAILABLE

 

注意:進行校準過程,一般需要配置非同步IO功能。

 

SQL> show parameter disk_asy

 

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

disk_asynch_io                       boolean     TRUE

 

 

SQL> select name,asynch_io from v$datafile f,v$iostat_file i

  2  where f.file#=i.file_no

  3  and (filetype_name='Data File' or filetype_name='Temp File');

 

NAME                                               ASYNCH_IO

-------------------------------------------------- ---------

+DATA/ora11g/datafile/system.256.825944325         ASYNC_ON

+DATA/ora11g/datafile/system.256.825944325         ASYNC_ON

+DATA/ora11g/datafile/sysaux.257.825944327         ASYNC_ON

+DATA/ora11g/datafile/undotbs1.258.825944329       ASYNC_ON

+DATA/ora11g/datafile/users.259.825944329          ASYNC_ON

+DATA/ora11g/datafile/example.265.825944513        ASYNC_ON

 

6 rows selected

 

IO校準並不是單獨的列出功能,而是融入到OracleResource Manager功能包裡面。呼叫IO校準的功能包DBMS_RESOURCE_MANAGER.CALIBRATE_IO,其中兩個輸入引數,一個是磁碟的個數,另一個是允許的最大IO延遲。這兩個引數可以通過諮詢運維團隊和廠商實現。

呼叫過程如下:

 

 

SQL> set serveroutput on;

SQL> DECLARE

  2    lat INTEGER;

  3    iops INTEGER;

  4    mbps INTEGER;

  5  BEGIN

  6  --DBMS_RESOURCE_MANAGER.CALIBRATE_IO(, ,iops, mbps, lat);

  7    DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);

  8    DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);

  9    DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);

 10    dbms_output.put_line('max_mbps = ' || mbps);

 11  end;

 12  /

 

max_iops = 111

latency = 8

max_mbps = 62

 

PL/SQL procedure successfully completed

 

Executed in 811.547 seconds

 

這個執行過程執行超過800s,時間不算短。最後計算出測算出的最大iops、延遲和最大mbps(每秒MB)。

在執行過程中,我們檢視檢視v$io_calibration_status

 

 

 

SQL> select * from v$io_calibration_status;

 

STATUS        CALIBRATION_TIME

------------- --------------------------------------------------------------------------------

IN PROGRESS   14-12-13 11.20.20.120 上午

 

 

此時的狀態,從Not Available變為Ready。在校準過程中,Oracle會形成對儲存的大量IO讀寫操作。我們藉助Linux下的sar命令,監控全部過程。

 

 

[root@SimpleLinux ~]# sar -b 5 100 -o /tmp/res2

Linux 2.6.18-128.el5 (SimpleLinux.localdomain)  12/13/2013

 

11:25:08 AM       tps      rtps      wtps   bread/s   bwrtn/s

11:25:13 AM      8.33      0.00      8.33      0.00    134.92

11:25:18 AM     23.02      1.59     21.43     50.79    311.90

11:25:23 AM      5.96      1.59      4.37     50.89     85.88

11:25:28 AM      7.14      1.59      5.56     50.79     89.68

11:25:33 AM      2.78      0.00      2.78      0.00     44.44

11:25:38 AM      5.96      1.59      4.37     50.89     85.88

11:25:43 AM    257.65    253.28      4.37   4141.55     76.34

11:25:48 AM    281.75    276.19      5.56   4415.87    219.05

11:25:53 AM    278.33    273.56      4.77   4427.83     89.07

11:25:58 AM    289.50    266.53     22.97   4264.55    237.62

11:26:03 AM    232.14    228.97      3.17   3688.89     50.79

11:26:08 AM    268.53    264.14      4.38   4608.76     92.43

 

 

注意TPS的變化過程。啟動校準之後,Oracle生成大量的IO操作,來判斷儲存的極限。這個過程也就是讓我們瞭解當前IO架構的上限。

我們通過Excel畫出全過程的TPSRTPSWTPS趨勢。

 

結束IO校準之後,我們可以檢視到IO調教過程資訊。

 

 

SQL> select * from v$io_calibration_status;

 

STATUS        CALIBRATION_TIME

------------- --------------------------------------------------------------------------------

READY         14-12-13 11.39.10.194 上午

 

3、校準使用

 

我們進行IO校準,可以為Oracle很多功能提供決策依據。如果沒有進行過IO校準,Auto DOP就不能正常工作。

 

 

SQL> explain plan for select /*+parallel*/ * from scott.emp;

 

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

Plan hash value: 1408123770

--------------------------------------------------------------------------------

| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT     |          |    14 |   532 |     2   (0)| 00:00:01

|   1 |  PX COORDINATOR      |          |       |       |            |

|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |   532 |     2   (0)| 00:00:01

|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01

|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01

--------------------------------------------------------------------------------

Note

-----

   - automatic DOP: skipped because of IO calibrate statistics are missing

 

15 rows selected

 

收集IO Calibrate統計量之後,就可以看到並行度效果。

 

 

SQL> explain plan for select /*+parallel*/ * from scott.emp;

 

Explained

 

SQL> select * from table(dbms_xplan.display);

 

PLAN_TABLE_OUTPUT

--------------------------------------------------------------------------------

Plan hash value: 2873591275

--------------------------------------------------------------------------------

| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time

--------------------------------------------------------------------------------

|   0 | SELECT STATEMENT     |          |    14 |   532 |     2   (0)| 00:00:01

|   1 |  PX COORDINATOR      |          |       |       |            |

|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |   532 |     2   (0)| 00:00:01

|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01

|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01

--------------------------------------------------------------------------------

Note

-----

   - automatic DOP: Computed Degree of Parallelism is 2

 

15 rows selected

 

 

4、結論

 

Oracle自動化、智慧化過程中,是需要提供很多輔助資訊的。Calibrate IO是一個重要方面。Oracle不進行自動的Calibrate IO統計量的原因大體有三個:

首先是Oracle並不知道實際磁碟的標準指標。第二是Oracle校準過程生成很大的IO,如果不慎會引起很大產品問題。第三是Disk IO效能不會經常性發生變化。






Automatic Degree of Parallelism in 11.2.0.2 (文件 ID 1269321.1)

In this Document

Purpose
Scope
  Ask Questions, Get Help, And Share Your Experiences With This Article
Details
  IO Calibration
  Tuning Parameters
References


APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.2 and later
Information in this document applies to any platform.

PURPOSE

In 11.2.0.2 Automatic Degree of Parallelism can only be used if  I/O statistics are gathered.

This Note explains what DBA has to do in order to make sure Automatic Degree of Parallelism works.

SCOPE

For DBAs 

The AutoDOP is not a feature to use more parallelism. It is a feature that restricts the parallel to maximize throughput,
so it is expected that with AutoDOP not all queries will run in parallel and the ones that do run in parallel may not run with full parallelism, as this is the technical specifications of the feature.

Ask Questions, Get Help, And Share Your Experiences With This Article

Would you like to explore this topic further with other Oracle Customers, Oracle Employees, and Industry Experts?

Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article.
Discover discussions about other articles and helpful subjects by clicking here to access the main My Oracle Support Community page for Database Datawarehousing.

DETAILS

When PARALLEL_DEGREE_POLICY is set to AUTO, Oracle Database determines whether a statement should run in parallel based on the cost of the operations in the execution plan and the hardware characteristics.

AutoDOP is used when PARALLEL or PARALLEL(AUTO) statement level hint is used regardless of the value of the PARALLEL_DEGREE_POLICY (see documentation).


IO Calibration

The hardware characteristics include I/O calibration statistics so these statistics must be gathered otherwise Oracle Database does not use the automatic degree parallelism feature.

If I/O calibration has not been run to gather the required statistics, the explain plan includes the following text in its notes section:  ": skipped because of IO calibrate statistics are missing"

explain plan for 
select /*+ parallel */ * from emp;

Plan hash value: 2873591275 
--------------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |    14 |   532 |     2   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR      |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------

 Note 
 ----- 
 - dynamic sampling used for this statement (level=2) 
 - automatic DOP: skipped because of IO calibrate statistics are missing

The Oracle PL/SQL package DBMS_RESOURCE_MANAGER.CALIBRATE_IO is used to execute the calibration. The duration of the calibration is dictated by the NUM_DISKS variable as well as the number of nodes in the RAC cluster.

SET SERVEROUTPUT ON
DECLARE
   lat INTEGER;
   iops INTEGER;
   mbps INTEGER;
BEGIN
    --DBMS_RESOURCE_MANAGER.CALIBRATE_IO(, ,iops, mbps, lat);
    DBMS_RESOURCE_MANAGER.CALIBRATE_IO (28, 10, iops, mbps, lat);
   DBMS_OUTPUT.PUT_LINE ('max_iops = ' || iops);
   DBMS_OUTPUT.PUT_LINE ('latency = ' || lat);
   dbms_output.put_line('max_mbps = ' || mbps);
END;
/


Note that the first two variables (NUM_DISKS, MAX_LATENCY) are input variables, and the remaining three are output variables.

NUM_DISKS - To get the most accurate results, its best to provide the actual number of physical disks that are used for this database. The Storage Administrator can provide this value. Keep in mind that when ASM is used to manage the database files, say in the DATA diskgroup, then only physical disks that make up the DATA diskgroup should be used for the NUM_DISKS variable; i.e.; do not include the disks from the FRA diskgroup. In the example above the DATA diskgroup is made up of 28 physicals (presented as 4 LUNs or ASM disks)

LATENCY– Maximum tolerable latency in milliseconds for database-block-sized IO requests.

You find more information about CALIBRATE_IO in Note: 727062.1  Configuring and using Calibrate I/O.

In order to verify whether the calibration run was successful, query V$IO_CALIBRATION_STATUS after you executed DBMS_RESOURCE_MANAGER.CALIBRATE_IO call.

select * from V$IO_CALIBRATION_STATUS;

STATUS   CALIBRATION_TIME
-------- ----------------------------- 
READY    25-NOV-10 08.53.08.536

The execution plan now shows that the feature automatic degree of parallelism can be used:

explain plan for 
select /*+ parallel */ * from emp;
Plan hash value: 2873591275 
--------------------------------------------------------------------------------------------------------------
| Id  | Operation            | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
--------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |          |    14 |   532 |     2   (0)| 00:00:01 |        |      |            |
|   1 |  PX COORDINATOR      |          |       |       |            |          |        |      |            |
|   2 |   PX SEND QC (RANDOM)| :TQ10000 |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
|   3 |    PX BLOCK ITERATOR |          |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
|   4 |     TABLE ACCESS FULL| EMP      |    14 |   532 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
--------------------------------------------------------------------------------------------------------------

Note 
----- 
- dynamic sampling used for this statement (level=2)
- automatic DOP: Computed Degree of Parallelism is 2 

 There is known issue with DBMS_RESOURCE_MANAGER.CALIBRATE_IO.

Note: 10180307.8 DBRM DBMS_RESOUCE_MANAGER.CALIBRATE_IO REPORTS VERY HIGH MAX_PMBPS If CALIBRATE_IO can not be used you can set the relevant value manual:

delete from resource_io_calibrate$;
insert into resource_io_calibrate$
values(current_timestamp, current_timestamp, 0, 0, 200, 0, 0); 
commit;

 You have to restart the database after this change.

200 is a value that works well for Machine with a fast I/O subsystem, as example for Exadata Machines. If you set the number (max_pmbps) lower your calculated DOP will increase. If you set max_pmbps higher the calculated DOP are decreased. It appears that 200 is a reasonable value to deal with concurrency on a system.

Automatic DOP is not computed if
  -  the database is not opened, or
  -  the database is in restricted access (DBA) or read-only or migrate mode, or
  -  database is suspended, or
  -  instance is not open , or
  - the SQL cursor is not supported do run in AutoDOP mode.

Tuning Parameters

When you use AutoDOP, you may want to adjust some tuning parameters.  See Document 1549214.1 Setup, Monitor, And Tune Parallelism In The Database for information about these parameters.   The parallel_servers_target should always be smaller than parallel_max_servers, with parallel_servers_target anywhere from 75% to 50% of parallel_max_servers.  If you start seeing a lot of DOP downgrades, you should make the distance between the values for these two parameters greater.

parallel_servers_target
parallel_min_time_threshold





Overview I/O Calibration

Oracle Database 11g introduces an I/O Calibration mechanism, whereby you can run I/O calibration tests either through the Enterprise Manager Performance page or a PL/SQL package. Oracle’s I/O calibration is a variation on the Clarion tool. In an Oracle database, the I/O workload is of two basic types—small random I/O and large sequential I/O. OLTP applications usually experience the small random I/O workload, where the speed with which small I/O requests are serviced is paramount. Thus, disk spinning and seeking times are of critical importance. OLAP applications, on the other hand, employ the large sequential I/O in general. For these types of applications, the critical factor is the capacity of the I/O channel. The larger the I/O channels between the database server and the storage system, the larger the I/O throughput. Oracle uses the following two metrics, each measuring the efficacy of one type of I/O workload:

  • IOPS (I/O per second)  The IOPS rate is the number of small random I/Os the system can perform in a second and depends on the spin speed of disks. You can increase the IOPS rate by increasing the number of disks in the storage array or by using faster disk drives, which have a high RPM and lower seek time.
  • MBPS (megabytes per second)  This metric measures the data transfer rate between the server and the storage array and depends on the capacity of the I/O channel between the two systems. A larger I/O channel means a higher MBPS rate.

Two important terms need clarification in this discussion: throughput and latency. The throughput of a system determines how fast it can transfer data and is measured by the MBPS metric. The channel capacity determines the overall throughput of the system, and it thus puts the ceiling on the amount of data transfer. Latency refers to the lag between the time an I/O request is made and when the request is serviced by the storage system. High latency indicates a system that’s overloaded and you can reduce latency by striping data across multiple spindles, so different disks can service the same I/O request in parallel.

Oracle recommends that you use the new I/O Calibration tool to determine I/O metrics in a database. It takes about 10 minutes to run the tools and you should pick a time when the database workload is light to avoid overstressing the storage system. You can run only a single calibration task at a time. If you perform the task in an RAC environment, the workload is generated simultaneously from all instances in the system. You can either run the tool with Enterprise Manager or through PL/SQL.

Calibrating I/O Using PL/SQL

You can also use the new procedure CALIBRATE_IO from the DBMS_ RESOURCE_MANAGER package to run the I/O Calibration task. Here is an example:

begin
  exec dbms_resource_manager.calibrate_io(-
  num_disks         => 1,   -
  max_latency       => 10, -
  max_iops          => :max_iops, -
  max_mbps          => :max_mbps, -
  actual_latency    => :actual_latency);
 end;
 /
In the CALIBRATE_IO procedure, the following are the key parameters:

  • num_disks: Approximate number of disks in the storage array.
  • max_latency: Maximum tolerable latency (in milliseconds) for an I/O request.
  • max_ios: Maximum number of random DB block-sized read requests that can be serviced.
  • max_mbps: Maximum number of randomly distributed 1MB reads that can be serviced (in megabytes per second).
  • actual_latency: Average latency of DB block-sized I/O requests at max_iops rate (in milliseconds).

The procedure only works if asynchronous I/O is enabled. If asynchronous I/O is not enabled, the procedure returns the following error.
DECLARE
*
ERROR at line 1:
ORA-56708: Could not find any datafiles with asynchronous i/o capability
ORA-06512: at "SYS.DBMS_RMIN", line 453
ORA-06512: at "SYS.DBMS_RESOURCE_MANAGER", line 1153
ORA-06512: at line 6
You can use the FILESYSTEMIO_OPTIONS static initialization parameter to enable or disable asynchronous I/O or direct I/O on file system files. This parameter is platform-specific and has a default value that is best for a particular platform.
FILESYTEMIO_OPTIONS can be set to one of the following values:

  • ASYNCH: enable asynchronous I/O on file system files, which has no timing requirement for transmission.
  • DIRECTIO: enable direct I/O on file system files, which bypasses the buffer cache.
  • SETALL: enable both asynchronous and direct I/O on file system files.
  • NONE: disable both asynchronous and direct I/O on file system files.

SQL> SHOW PARAMETER FILESYSTEMIO_OPTIONS
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
filesystemio_options                 string      none
ALTER SYSTEM SET FILESYSTEMIO_OPTIONS=SETALL SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

Usage Notes

  • Only users with the SYSDBA privilege can run this procedure. Qualified users must also turn on timed_statistics, and ensure asynch_io is enabled for datafiles. This can be achieved by setting filesystemio_options to either ASYNCH or SETALL. One can also query the asynch_io status by means of the following SQL statement:
    col name format a50
    SELECT name, asynch_io FROM v$datafile f,v$iostat_file i
    WHERE f.file#        = i.file_no
    AND   filetype_name  = 'Data File';
  • Only one calibration can be run at a time. If another calibration is initiated at the same time, it will fail.
  • For an Oracle Real Application Clusters (Oracle RAC) database, the workload is simultaneously generated from all instances.

For timed_statistics paramter,please refer to following illustration :

TIMED_STATISTICS specifies whether or not statistics related to time are collected.Values:

  • true: The statistics are collected and stored in trace files or displayed in the V$SESSTATS and V$SYSSTATS dynamic performance views.
  • falseThe value of all time-related statistics is set to zero. This setting lets Oracle avoid the overhead of requesting the time from the operating system.

Starting with release 11.1.0.7.0, the value of the TIMED_STATISTICS parameter cannot be set to false if the value of STATISTICS_LEVEL is set to TYPICAL or ALL.
On some systems with very fast timer access, Oracle might enable timing even if this parameter is set to false. On these systems, setting the parameter to true can sometimes produce more accurate statistics for long-running operations.

The [G]V$IO_CALIBRATION_STATUS views show the current status of the calibration runs. During a run the status of 'IN PROGRESS' is displayed. Once a run is complete the status switches to 'READY' and the calibration time is displayed.Besides,NOT AVAILABLE mean Calibration results not available and CALIBRATION_TIME tell us End time of the last calibration run
SQL> SELECT * FROM v$io_calibration_status;
STATUS        CALIBRATION_TIME
------------- -------------------------------
IN PROGRESS
SQL> SELECT * FROM v$io_calibration_status;
STATUS        CALIBRATION_TIME
------------- ---------------------------------------------------------------------------
READY         28-JUL-2008 14:37:38.410
1 row selected.

Once you execute the CALIBRATE_IO procedure, you can query the V$IO_ CALIBRATION_STATUS and the DBA_RSRC_IO_CALIBRATE views to check the results. Here’s a sample query:

SQL> select max_iops, max_mbps, max_pmbps, latency
     from dba_rsrc_io_calibrate;

MAX_IOPS      MAX_MBPS      MAX_PMBPS     LATENCY
----------   ------------  ------------  ----------
133           12             6             64
Oracle Database 11g collects I/O statistics in three different dimensions to provide a consistent set of statistics for I/O calls.These dimensions are RDBMS components grouped into 12 functional groups.

  • The V$IOSTAT_ FUNCTION view provides the details. I/O statistics are collected for each consumer group that’s part of the currently enabled resource plan.
  • The V$IOSTAT_CONSUMER_GROUP view has the details.
  • Individual file level I/O statistics are collected and stored in the V$IOSTAT_ FILE view for details.

參考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》

                 http://www.oracle-base.com/articles/11g/resource-manager-enhancements-11gr1.php
                 http://docs.oracle.com/cd/E11882_01/server.112/e40402/initparams259.htm#REFRN10218
                 http://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_resmgr.htm#ARPLS67599







About Me

.............................................................................................................................................

● 本文作者:小麥苗,部分內容整理自網路,若有侵權請聯絡小麥苗刪除

● 本文在itpub(http://blog.itpub.net/26736162/abstract/1/)、部落格園(http://www.cnblogs.com/lhrbest)和個人微信公眾號(xiaomaimiaolhr)上有同步更新

● 本文itpub地址:http://blog.itpub.net/26736162/abstract/1/

● 本文部落格園地址:http://www.cnblogs.com/lhrbest

● 本文pdf版、個人簡介及小麥苗雲盤地址:http://blog.itpub.net/26736162/viewspace-1624453/

● 資料庫筆試面試題庫及解答:http://blog.itpub.net/26736162/viewspace-2134706/

● DBA寶典今日頭條號地址:http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

.............................................................................................................................................

● QQ群號:230161599(滿)、618766405

● 微信群:可加我微信,我拉大家進群,非誠勿擾

● 聯絡我請加QQ好友646634621,註明新增緣由

● 於 2017-12-01 09:00 ~ 2017-12-31 22:00 在魔都完成

● 文章內容來源於小麥苗的學習筆記,部分整理自網路,若有侵權或不當之處還請諒解

● 版權所有,歡迎分享本文,轉載請保留出處

.............................................................................................................................................

小麥苗的微店https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

小麥苗出版的資料庫類叢書http://blog.itpub.net/26736162/viewspace-2142121/

.............................................................................................................................................

使用微信客戶端掃描下面的二維碼來關注小麥苗的微信公眾號(xiaomaimiaolhr)及QQ群(DBA寶典),學習最實用的資料庫技術。

   小麥苗的微信公眾號      小麥苗的DBA寶典QQ群2     《DBA筆試面寶典》讀者群       小麥苗的微店

.............................................................................................................................................

Oracle 11g中的IO Calibrate(IO校準)--Automatic Degree of Parallelism(DOP)
DBA筆試面試講解群
《DBA寶典》讀者群 歡迎與我聯絡



來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/26736162/viewspace-2148709/,如需轉載,請註明出處,否則將追究法律責任。

相關文章