Debug Methods Oracle (Coarse Grained Auditing)



Scenario
There are many times, where there was an issue in production and you did not have any idea how it happened. The following article will give you some direction. Please note there are many other ways too. Currently, I will just focus on a method I had used during a similar situation.

This error information is from the latest logs from Production said:
ORA-00001: unique constraint (TABLE_ABCD.SYS_C006189415) violated

      Now the constraints to troubleshoot the above scenario are:
  • You have limited access/privilege in production environment.
  • The above was due to a duplicate record that came in and your process tried to insert that duplicate data.
But what was that data that caused disruption? The answer could have been found out by using FlashBack Query feature from Oracle. This however is version specific. Let’s look into some other aspects of debugging.

Observation

  • There is no clue to the data that was being inserted at the time this exception was thrown.
  • Not much information either from any of the relevant log files about the metadata.
  • The respective process tables handle massive number of records which makes it further more   cumbersome to troubleshoot or pin point the culprit.
  • No bulletin or logs from front end either.


Other Debug Options
 In this scenario we have a few options to explore and figure out the corrupt data:
  • Putting ON our Application Debug option – Heavy On Performance & Resource (Not always helpful either)
  • Get the trace log files inspected by the DBA (if at all the relevant data is set to be captured) – Complex, Heavy On Performance & Resource
  • There are other DBMS packages like DBMS_ERRLOG, DBMS_MONITOR, DBMS_RLS  etc. – Little More Coding and better with live capture instead of historical
  • Triggers to capture & hold the data. – Needs another table to be created to hold the bad data
  • There are some other ways as well not mentioned for now

A Simpler Option (for database issues)

Auditing, at Statement Level.
There are other variations to this as well like Object level, Privilege level, Fine Grained Auditing to increase the granularity of data captured.

PREREQUISITES: The system parameters, AUDIT_SYS_OPERATIONS are set to TRUE & AUDIT_TRAIL is set to DB_EXTENDED (This setting required to capture the SQL_BIND data).  Check V$PARAMETER view. Since by default there will be a certain level of auditing enabled for any database, luckily these settings might pre-exist. In case it doesn’t, enhanced privileges will be required to modify them.

SWITCH ON AUDIT (FOR THE TABLE ONLY):   
AUDIT INSERT, UPDATE ON <OWNER>.<TABLE_NAME>                                                                                                                                          
BY ACCESS – Can be BY SESSION as well                                                                                                                                               
WHENEVER NOT SUCCESSFUL;

CHECK RESULTS: Query the USER_AUDIT_TRAIL table and check the fields, SQL_BIND (the data of interest), SQL_TEXT (the query which caused the failure), ACTION and RETURN CODE (0 for Success)
e.g. select * from USER_AUDIT_TRAIL where owner = 'OWNER_NAME' and OBJ_NAME= 'TABLE_NAME';
The bound data from SQL_BIND column will provide the solution:
               
SWITCH OFF AUDIT:  NOAUDIT INSERT, UPDATE
                                                                                 ON <OWNER>.<TABLE_NAME>
                                                                                  WHENEVER NOT SUCCESSFUL;

NOTE: The above is also an instance where we made use of a minimal elevated privilege.

Refer to the following links for more details:
http://www.oracle-base.com/articles/8i/auditing.php
http://www.oracle-base.com/articles/10g/auditing-10gr2.php
http://docs.oracle.com/cd/B10501_01/server.920/a96524/c25audit.htm

Comments

Post a Comment

Popular posts from this blog

Automatic Replenishment ~ Warehouse Management (WM) in SAP

Image
This article is intended for SAP functional consultants to configure automatic replenishment of a particular storage type for transfer orders. Whenever the stock in a bin falls below the MIN value (predefined minimum quantity), it will trigger replenishment or transfer request (TR) which will in turn get converted into a transfer order, so that the workers in the warehouse can carry out the actual physical transfer of stock. We have a provision of assigning a definite storage type from where the stock will be picked up for replenishment.   Step 1 : Material Master has to be maintained with Warehouse Views. Under Warehouse Mgmt 2 Storage bin, Maximum bin Quantity, Minimum bin Quantity and Replenishment Quantity has to be maintained. Configuration Changes: Step 2 : Movement type 320 is copied from existing movement type 319 under Logistics Execution ->Warehouse management->Activities->Transfers->Define Movement Types. Movement type 320 is configured as the follo...
Read more

Teradata - Month End Date

Sql Server: Calculating the last day of the month in SQL Server is pretty simple. Run the following piece of code and its done. SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0)) CurrentMonthEnd_Day ResultSet: CurrentMonthEnd_Day ———————– 2010-08-31 23:59:59.000 Teradata: However, with reference to Teradata SQL, in our day to day queries in a datawarehouse environment very frequently we need to play with the month end dates that are mostly kept in the date dimension table with one field, i.e. the month end date field. You might require to fetch the month end date which is 4 years back. usually the simplest way in this case will be to calculate 48 months back from the current month end date (in case the monthe end date that long is not stored into the database). This is fair. The piece of code required to do is simple. SELECT (ADD_MONTHS(CAST('2012/08/31' AS DATE),-48)) Result: 2008/08/31 Now trying this simple thing will not work if its a leap year a...
Read more

SQL Optimizer Parameterization

Image
Plan Recompilation Once the Query Optimizer has come up with a plan, which may have taken a considerable amount of work, SQL Server does its best to ensure that you can leverage all that costly work again. It does this by caching the plan it just created, and taking steps to ensure that the plan is reused as widely as possible. It does this by using parameterization options. Parameterization Parameterization is a process whereby SQL Server will take the T-SQL you entered and look for ways to replace values that may be variables with a token, so that if a similar query is processed, SQL Server can identify it as being the same underlying query, apart from some string, or integer values, and make use of the already cached plan. For example, the following is a basic T-SQL query to return data from the Adventure Works 2008 database:    select *    from person.person    where lastname = 'fluffy' The parameterization of this query would result in the string...
Read more