Tag: awr

Database

How to Disable AWR and Prevent Violating Diagnostic Tuning Pack License

 , , ,

Hey folks,
Seems you like it, so on same line that the post from last week: Let’s say you want to prevent yourself to violate Oracle licensing of your Enterprise Edition database… But as you know, Oracle is tricky sometimes. For example, all Diagnostic Pack features are enabled by default, you just need a JR DBA to go there and used for you to be stuck.

By the way, here is the first mistake: No, AWR is not part of Enterprise Edition, it also requires Diagnostic Pack!

Ok Matheus, so how to prevent it? Here it goes:

Disable AWR with Oracle provided script

Use the script dbmsnoawr.plb provided in MOS Doc ID 1909073.1 to disable AWR once the database has been created.

To install, run the package as SYS from SQL*Plus:
SQL> @dbmsnoawr.plb

To execute the package, use the command:
SQL> begin dbms_awr.disable_awr(); end;

Modify the CONTROL_MANAGEMENT_PACK_ACCESS init parameter to NONE and disable the AWR related advisors.

Disable AWR Related Options

ALTER SYSTEM SET control_management_pack_access=NONE;

SQL> select client_name, operation_name, status from dba_autotask_operation;

CLIENT_NAME                                                      OPERATION_NAME                                                   STATUS 
---------------------------------------------------------------- ---------------------------------------------------------------- --------
auto optimizer stats collection                                  auto optimizer stats job                                         ENABLED
auto space advisor                                               auto space advisor job                                           ENABLED
sql tuning advisor                                               automatic sql tuning task                                        ENABLED


BEGIN
  dbms_auto_task_admin.disable(
    client_name => 'sql tuning advisor',
    operation   => NULL,
    window_name => NULL);

  dbms_auto_task_admin.disable(
    client_name => 'auto space advisor',
    operation   => NULL,
    window_name => NULL);

END;
/

SQL> select client_name, operation_name, status from dba_autotask_operation;

CLIENT_NAME                                                      OPERATION_NAME                                                   STATUS 
---------------------------------------------------------------- ---------------------------------------------------------------- --------
auto optimizer stats collection                                  auto optimizer stats job                                         ENABLED
auto space advisor                                               auto space advisor job                                           DISABLED
sql tuning advisor                                               automatic sql tuning task                                        DISABLED

Some reference on it?
– How To Avoid the AWR Usage Without Having Diagnostic Pack License (Doc ID 2276199.1)
– Controlling Diagnostic and Tuning Pack Usage (Doc ID 436386.1)
– Disabling and Uninstalling AWR (Doc ID 1909073.1)

Hope it helps!

Database, Enterprise Manager, Performance

Managing AWR Warehouse Repository Database

 , , , ,

1. Change Retention Period Of AWR Warehouse Repository Database

This retention of the AWR on the Repository Database can be changed by the following:

<OMS_HOME>/bin>./emcli awrwh_reconfigure -retention=<New retention period (in years)>
For example: 
[oracle@oem13c oms]$ emcli awrwh_reconfigure -retention=5

2. Change Staging Location Of AWR Dump Files

For the AWR Warehouse, the target database by default creates dump file in home directory. So after adding the target to AWR warehosue, we need to reconfigure it from OEM CLI to change the dump files directory as following:

<OMS_HOME>/bin>./emcli awrwh_reconfigure_src -target_name=<target database name> -target_type=rac_database -src_dir="<directory path>"
For example: 
[oracle@oem13c ]$ ./emcli awrwh_reconfigure_src -target_name=greporadb -target_type=rac_database -src_dir="/arwdata/awrw"

3. Change Upload Interval Of SnapShots In AWR Warehouse Repository Database

This configuration can be changed by the following:

<OMS_HOME>/bin>./emcli awrwh_reconfigure -upload_interval <New upload interval>
For example: 
[oracle@oem13c oms]$ ./emcli awrwh_reconfigure -upload_interval=12

4. List Current Configuration

This can be accomplished by the following:

[oracle@oem13c oms]$ emcli awrwh_reconfigure -list
Upload Interval (hours) = 12
Retention (years) = 5
Dump Location = /awrdata/awrw/
AWR Warehouse reconfigured successfully
[oracle@oem13c oms]$

Reference: 
EM13c: How To Change Retention Period Of AWR Warehouse Repository Database In 13.2 OEM Cloud Control (Doc ID 2247437.1)
EM13c: How To Change Staging Location Of Dump Files On AWR Warehouse Repository Database In 13.2 OEM Cloud Control (Doc ID 2247439.1)
EM13c: How To Change Upload Interval Of SnapShots In AWR Warehouse Repository Database In 13.2 OEM Cloud Control (Doc ID 2247438.1)

Database, Errors and Bugs

Orphan AWR Data Consuming SYSAUX Space

 , ,

Hi all!
Some time ago I faced the this situation in a client. SYSAUX was simply growing with no reason, but retention and everything has not changed.

After some research, could map issue to Bug 14084247: STBH: ORA-01555 DUE TO WRH$_ACTIVE_SESSION_HISTORY NOT PURGED.

There is an one-ooff patch, but needs also extra steps to make it work, as stated on MOS: Excessive AWR Growth From Partitioned Objects Such as SYS.WRH$_EVENT_HISTOGRAM Causing Sysaux to Grow (Doc ID 1912201.1):

However, even after applying bug patch 14084247, this fix will not have an immediate effect and may take some time to "catch up".

The good new is that this can also be applied in on-line patching mode. I did another post documenting this patch applying: Online Data Patch Apply with multiple Databases on same Oracle Home: OPatch failed with error code 26

Some other relevant MOS Documents under this subject are:
– WRH$_ACTIVE_SESSION_HISTORY Does Not Get Purged Based Upon the Retention Policy (Doc ID 387914.1)
– Suggestions if Your SYSAUX Tablespace Grows Rapidly or Too Large (Doc ID 1292724.1)

Ok, but waht can I do right now?
You can purge the top AWR tables, as described on MOS: WRH$_LATCH, WRH$_SYSSTAT, and WRH$_PARAMETER Consume the Majority of Space within SYSAUX (Doc ID 2099998.1).

Check steps below on how it can be done:

More“Orphan AWR Data Consuming SYSAUX Space”

Database, Performance, SQL | PLSQL

Oracle TPS: Evaluating Transaction per Second

 , , , , ,

Sometimes this information has some ‘myth atmosphere’… Maybe because of that Oracle doesn’t have this information very clear and it’s not the most useful metric.
But for comparison to another systems and also to performance/’throughput’ with different infrastructure/database configuration, it can be useful.

It can be seen by AWR on “Report Summary” section, on “Load Profile”, “Transactions” item:

awr_tps

But if you want to calculate it through SQL query?
And if you want to have a historic from this metric?

I found a reference for this calculation here, using v$sysstat.
It’s the only reference I found, and it on 10g documentation… It refers this metric as:

Number of Transactions = (DeltaCommits+DeltaRollbacks)/Time

It also refers as DeltaCommits and DeltaRollbacks, respectively, “user commits” and user “rollbacks”.

Where it goes a possible SQL to do that:

WITH hist_snaps
AS (SELECT instance_number,
snap_id,
round(begin_interval_time,'MI') datetime,
(  begin_interval_time + 0 - LAG (begin_interval_time + 0)
OVER (PARTITION BY dbid, instance_number ORDER BY snap_id)) * 86400 diff_time
FROM dba_hist_snapshot), hist_stats
AS (SELECT dbid,
instance_number,
snap_id,
stat_name,
VALUE - LAG (VALUE) OVER (PARTITION BY dbid,instance_number,stat_name ORDER BY snap_id)
delta_value
FROM dba_hist_sysstat
WHERE stat_name IN ('user commits', 'user rollbacks'))
SELECT datetime,
ROUND (SUM (delta_value) / 3600, 2) "Transactions/s"
FROM hist_snaps sn, hist_stats st
WHERE     st.instance_number = sn.instance_number
AND st.snap_id = sn.snap_id
AND diff_time IS NOT NULL
GROUP BY datetime
ORDER BY 1 desc;

I like to use PL/SQL Developer to see this kind of data. And it regards us to make very good charts very quickly. I try it in a small database here, just for example:

7days_tps

Jedi Master Jonathan Lewis wrote a good post about Transactions and this kind of AWR metric here.

See ya!
Matheus.