undo自动调优介绍

Comments

5 responses to “undo自动调优介绍”

1. 

   admin

   August 1, 2010

   Hdr: 5387030 10.2.0.2.0 RDBMS 10.2.0.2.0 TXN MGMT LOCAL PRODID-5 PORTID-212
   Abstract: AUTOMATIC TUNING OF UNDO_RETENTION CAUSING SPACE PROBLEMS

   So when:
   a) not using GUARANTEED retention at undo tablespace level and
   b) not using auto-extensible data files (fixed sized data file). then the
   tuned_undoretention stays high to satisfy the maxquerylen at that time and
   causes out of undo space error. The tuned_undoretention value did not return
   to
   a lower value even after 36 hours of quiet time (not a single query was
   submitted).

   Then, we changed undo tablespace’s data files to be auto_extensible, but did
   not allow it to actually extend any further. The max size was set to the
   current allocated size.

   With this change the tuned_undoretention returned to the set value for und
   o_retention parameter immediately after the long running query completed.
   This is same behavior we have seen in 10g R1 without the need for
   auto_extensible data files.
   And that is the difference in 10g R2 from R1. This change forces the bogus
   use
   of auto_extensible option.

   I will upload a text file for you to review in support of what I mentioned
   here.
   It is causes confusion and misleading to customer needs.

   So, this workaround is not a big deal, but 10g R2 is not backward compatible
   to 10g R1 in this respect. And is not clearly documented as such. If there is
   no chance to change this to match what 10g R1did, then I think a Metalink
   Note to that effect will clear things up for all who may run into this
   issue.

   SQL> show parameter undo

   NAME TYPE VALUE
   ———————————— ———–
   ——————————
   undo_management string AUTO
   undo_retention integer 900
   undo_tablespace string UNDO_TBS
   SQL>

   SQL> alter session set nls_date_format=’mm/dd/yy hh24:mi:ss’;

   Session altered.

   SQL> set lines 132
   SQL> get f1.sql
   1 select begin_time
   2 , end_time
   3 , undoblks
   4 , tuned_undoretention
   5 , maxquerylen
   6 , maxqueryid
   7* from v$undostat
   SQL> /

   BEGIN_TIME END_TIME UNDOBLKS TUNED_UNDORETENTION
   MAXQUERYLEN MAXQUERYID
   —————– —————– ———- ——————-
   ———– ————-
   07/05/06 14:32:23 07/05/06 14:37:25 1 900
   0
   07/05/06 14:22:23 07/05/06 14:32:23 3 900
   0
   07/05/06 14:12:23 07/05/06 14:22:23 4 900
   0
   07/05/06 14:02:23 07/05/06 14:12:23 2 900
   0
   07/05/06 13:52:23 07/05/06 14:02:23 50 900
   0
   07/05/06 13:42:23 07/05/06 13:52:23 5 900
   0
   07/05/06 13:32:23 07/05/06 13:42:23 2 900
   0
   07/05/06 13:22:23 07/05/06 13:32:23 4 900
   0
   07/05/06 13:12:23 07/05/06 13:22:23 6 900
   0
   07/05/06 13:02:23 07/05/06 13:12:23 0 900
   0
   07/05/06 12:52:23 07/05/06 13:02:23 63 900
   0

   BEGIN_TIME END_TIME UNDOBLKS TUNED_UNDORETENTION
   MAXQUERYLEN MAXQUERYID
   —————– —————– ———- ——————-
   ———– ————-
   07/05/06 12:42:23 07/05/06 12:52:23 265 1800
   962 271b023vduant
   07/05/06 12:32:23 07/05/06 12:42:23 449 1201
   362 271b023vduant
   07/05/06 12:22:23 07/05/06 12:32:23 404 2948
   2108 271b023vduant
   07/05/06 12:12:23 07/05/06 12:22:23 372 2348
   1506 271b023vduant
   07/05/06 12:02:23 07/05/06 12:12:23 353 1747
   906 271b023vduant
   07/05/06 11:52:23 07/05/06 12:02:23 513 1421
   582 271b023vduant
   07/05/06 11:42:23 07/05/06 11:52:23 169 1005
   164 fby3wmzn3hzvw
   07/05/06 11:32:23 07/05/06 11:42:23 3 900
   0
   07/05/06 11:22:23 07/05/06 11:32:23 2 900
   0
   07/05/06 11:12:23 07/05/06 11:22:23 11 900
   0
   07/05/06 11:02:23 07/05/06 11:12:23 4 900
   0

   SQL> get f2.sql
   1 select tablespace_name
   2 , retention
   3 from dba_tablespaces
   4* where tablespace_name = ‘UNDO_TBS’
   SQL> /

   TABLESPACE_NAME RETENTION
   —————————— ———–
   UNDO_TBS NOGUARANTEE

   SQL> col file_name for a45
   SQL>
   SQL> get f3.sql
   SQL> get f3.sql
   1 select file_name
   2 , autoextensible
   3 , bytes/1048576 MB
   4 , increment_by
   5 , maxbytes/1048576 Max_MB
   6 from dba_data_files
   7* where tablespace_name = ‘UNDO_TBS’
   SQL> /

   FILE_NAME AUT MB INCREMENT_BY
   MAX_MB
   ——————————————— — ———- ————
   ———-
   /u10/oradata/VZCT/undo_tbs_02.dbf YES 3000 128
   3000
   /u11/oradata/VZCT/undo_tbs_01.dbf YES 2000 128
   2000
   /u13/oradata/VZCT/undo_tbs_03.dbf YES 1000 128
   1000

   TAR: 5337754.992
   —-

   PROBLEM:
   ——–

   1) Unused Undo segments are not being release, originally the database was
   running on 10.1 without problem, but after upgrade to release 10.2.0.2 the
   problem started.

   2) UNDO_RETENTION parameter was correctly set = 900

   3) Undo Tablespace was fixed sized, in other word the Undo tablespace was not
   enabled with Autoextensible option for the associated datafiles.

   4) Also, the Undo tablespace was never enabled with the guaranty retention
   option.

   5) So, after upgrade to 10.2 the problem is the TUNED_UNDORETENTION stayed
   very high causing UNDO_TABLESPACE run out of disk space and it is not
   releasing the unused undo segments.

   6) The Oracle Undo Advisor is always asking to increase the Undo tablespace
   (e.g. 17032 MB) which is not acceptable.

   7) TUNED_UNDORETENTION column (v$undostat) is always increasing and never
   returning back to 900 as on 10gR1:
   =============================================================
   SQL> get f1.sql
   1 select begin_time, end_time, undoblks, tuned_undoretention, maxquerylen,
   maxqueryid
   2* from v$undostat
   SQL> /

   BEGIN_TIME END_TIME UNDOBLKS TUNED_UNDORETENTION
   MAXQUERYLEN MAXQUERYID
   —————– —————– ———- ——————-
   ———– ————-
   04/15/06 12:37:38 04/15/06 12:40:00 1443 61233
   36031 gf37j3d3q2h15
   04/15/06 12:27:38 04/15/06 12:37:38 6285 61261
   36031 gf37j3d3q2h15
   04/15/06 12:17:38 04/15/06 12:27:38 5450 60206
   35430 gf37j3d3q2h15
   04/15/06 12:07:38 04/15/06 12:17:38 6348 60110
   34830 gf37j3d3q2h15
   04/15/06 11:57:38 04/15/06 12:07:38 5005 60094
   34229 gf37j3d3q2h15
   04/15/06 11:47:38 04/15/06 11:57:38 5440 59954
   33628 gf37j3d3q2h15
   04/15/06 11:37:38 04/15/06 11:47:38 6662 58994
   33028 gf37j3d3q2h15
   04/15/06 11:27:38 04/15/06 11:37:38 5197 58995
   32427 gf37j3d3q2h15
   04/15/06 11:17:38 04/15/06 11:27:38 5597 59184
   31826 gf37j3d3q2h15
   04/15/06 11:07:38 04/15/06 11:17:38 6035 59943
   31225 gf37j3d3q2h15

   04/15/06 06:47:38 04/15/06 06:57:38 5185 56068
   15607 gf37j3d3q2h15
   04/15/06 06:37:38 04/15/06 06:47:38 5002 54669
   15007 gf37j3d3q2h15
   04/15/06 06:27:38 04/15/06 06:37:38 4905 54491
   14406 gf37j3d3q2h15

   04/13/06 21:57:38 04/13/06 22:07:38 3474 345600
   213 0mdbrtbvdd9gu
   04/13/06 21:47:38 04/13/06 21:57:38 25 345600
   0
   04/13/06 21:37:38 04/13/06 21:47:38 22 345600
   0
   04/13/06 21:27:38 04/13/06 21:37:38 96 345600
   0

   236 rows selected.
   =============================================================

   DIAGNOSTIC ANALYSIS:
   ——————–

   1) This behavior was diagnosed through the v$undostat view (OWC session)

   2) Please check the undo_retention_too_much.txt log file.

   WORKAROUND:
   ———–

   None.

   RELATED BUGS:
   ————-

   None

   REPRODUCIBILITY:
   —————-

   It is always reproducible in the customer’s environment.

   TEST CASE:
   ———-

   None

   STACK TRACE:
   ————

   SUPPORTING INFORMATION:
   ———————–

   Analyst: Esteban Bernal
   AIM: ebernalus

   24 HOUR CONTACT INFORMATION FOR P1 BUGS:
   —————————————-

   DIAL-IN INFORMATION:
   ——————–

   IMPACT DATE:
   ————

   REDISCOVERY INFORMATION:
   Look for:
   – System Managed Undo
   undo_management=auto in init.ora
   – Fixed size undo tablespace
   select autoextensible from dba_data_files
   where tablespace_name=’‘
   returns “No” for all the undo ts datafiles.
   – The undo tablespace is already sized such that
   it always has more than enough space to store
   all the undo generated within the undo_retention
   time, and the in-use undo space never exceeds the
   undo tablespace warning alert threshold (see
   below for the query to show the thresholds).
   – The tablespace threshold alerts recommend that
   the DBA add more space to the undo tablespace:
   select creation_time, metric_value, message_type,
   reason, suggested_action
   from dba_outstanding_alerts
   where object_name=’‘;
   returns a suggested action of:
   “Add space to the tablespace”
   Or, this recommendation has been reported in the
   past but the condition has now cleared:
   select creation_time, metric_value, message_type,
   reason, suggested_action, resolution
   from dba_alert_history
   where object_name=’‘;
   – The undo tablespace in-use space exceeded the
   warning alert threshold at some point in time:
   To see the warning alert percentage threshold:
   select object_type, object_name,
   warning_value, critical_value
   from dba_thresholds
   where object_type=’TABLESPACE’;
   To see the (current) undo tablespace percent of
   space in-use:
   select
   ((select (nvl(sum(bytes),0))
   from dba_undo_extents
   where tablespace_name=’‘
   and status in (‘ACTIVE’,’UNEXPIRED’)) *100) /
   (select sum(bytes)
   from dba_data_files
   where tablespace_name=’‘)
   “PCT_INUSE”
   from dual;
   WORKAROUND:
   There are 3 possible alternate workarounds (any one of
   these should resolve the problem of the alerts triggering
   unnecessarily):
   1. Set the autoextend and maxsize attribute of each datafile
   in the undo ts so it is autoextensible and its maxsize is
   equal to its current size so the undo tablespace now has
   the autoextend attribute but does not autoend:
   alter database datafile ‘‘
   autoextend on maxsize ;
   With this setting, v$undostat.tuned_undoretention is not
   calculated based on a percentage of the undo tablespace
   size, instead v$undostat.tuned_undoretention is set to
   the maximum of:
   maxquerylen secs + 300
   undo_retention specified in init.ora
   2. Set the following hidden parameter:
   in init.ora: _smu_debug_mode=33554432
   or use: alter system set “_smu_debug_mode” = 33554432;
   With this setting, v$undostat.tuned_undoretention is not
   calculated based on a percentage of the fixed size undo
   tablespace, instead v$undostat.tuned_undoretention is
   set to the maximum of:
   maxquerylen secs + 300
   undo_retention specified in init.ora
   3. Set the following hidden parameter:
   in init.ora: _undo_autotune = false
   or use: alter system set “_undo_autotune” = false;
   With this setting, v$undostat (and therefore
   v$undostat.tuned_undoretention) is not maintained and
   and the undo_retention used is the one specified in
   init.ora
   RELEASE NOTES:
   ]]In 10.2, for a non-autoextend SMU undo tablespace which
   ]]is already adequately sized to handle the transaction
   ]]workload for the specified undo_retention time, the
   ]]tablespace threshold alert mechanism may still recommend
   ]]that the DBA add more space to the undo tablespace.

   Reply
2. 

   maclean

   July 2, 2011

   On an instance with
   – Automatic Undo Management
   – High number of concurrent transactions
   – Many offline undo segs
   – Space Pressure on the UNDO TS

   following an instance recycle the intial value of V$UNDOSTAT.TUNED_UNDORETENTION
   can be calculated too high preventing undo blocks to be expired and their allocated
   space is not immediatly reused.

   BEGIN TXN MAXQUERY UNEXPIRED EXPIRED TUNED_UNDO
   TIME COUNT LENGHT BLKS BLKS RETENTION
   ——– —– ——- ———- —— ———-
   10:09:58 3082 138 12458840 53792 345600
   10:19:58 24178 432 12458840 53792 345600
   10:29:58 90407 344 12446816 51048 182905

   As the number of transactions increases so is their need for space but if there is
   little space free because most is still allocated to unexpired blocks the sessions
   first search for free space in offline undo segments (OfUS).
   If there are many of OfUS the search for space can generate lots of hits on
   dc_rollback_segments, the latch and US enqueue.

   Top 5 Wait Events Waits Avg Wt(ms) %Total Call Time Wt
   ———————— ———— ———- —-
   latch: row cache objects 36,521,692 3 31.3

   Cache Get Requests
   ——————– ————
   dc_rollback_segments 274,882,689

   Latch Name Where Sleeps Waiter Sleeps
   —————– —————– ———- ——–
   row cache objects kqrpre: find obj ########## ########
   row cache objects kqreqd: reget 9,674,182 ########
   row cache objects kqreqd 7,044,274 ########

   SQL> select count(*) OfUS from dba_rollback_segs where status = ‘OFFLINE’;

   OfUS
   —-
   1999

   The fix sets a better intial value of TUNED_UNDORETENTION by accessing
   historical data on wrh$_undostat after startup and makes more efficient
   the search for free space and making SMON try to shrink the undo segment
   before placing it offline avoiding the search for space on them.

   Workaround:
   “_smu_debug_mode”=33554432 see bug:5387030

   Reply
3. 

   北在南方

   October 11, 2011

   你有没有 undo 分配extent的机制的文章？谢谢了。

   Reply
   1. 

      admin

      October 11, 2011

      一直想写，一直没空

      Reply
4. 【性能调优】Oracle AWR报告指标全解析 – Oracle数据库数据恢复、性能优化来问问AskMaclean – ParnassusData诗檀软件旗下网站

   November 11, 2014

   […] Min/Max TR (mins)   最小和最大的tuned  undo retention ，单位为分钟； tuned undo retention 是自动undo调优特性，见undo自动调优介绍。 […]

   Reply