Peter Ramm's Oracle performance analysis stuff

Consider the following requirement: There are two tables. Table MASTER is referenced from table DETAIL. CREATE TABLE Master ( ID NUMBER PRIMARY KEY , Company_ID NUMBER ); CREATE TABLE Detail ( ID NUMBER GENERATED BY DEFAULT ON NULL AS IDENTITY PRIMARY KEY, Master_ID NUMBER REFERENCES Master(ID), Value NUMBER ); The content of the table DETAIL should be unique in a combination of two values: the column DETAIL.VALUE and the column MASTER.COMPANY_ID from a directly referenced table. Each column of this tables except the primary key columns can be changed. Limits of solution approach with function based index A first thought when securing uniqueness across table boundaries is often the use of function based indexes with a function that selects the second value from the referenced table. CREATE OR REPLACE FUNCTION Get_Company_ID(p_Master_ID IN NUMBER) RETURN NUMBER DETERMINISTIC IS v_Company_ID NUMBER; BEGIN SELECT Company_ID INTO v_Comp...

The most efficient way of processing GROUP BY or SORT operations is often if they are executed only at the really necessary DB objects and the smallest number of rows and columns.  The optimizer itself tends to move GROUP BY and SORT operations out to the last operation of a SQL, thus executing these operations on larger data sets than necessary.  One way to improve that is to use the so called VIEW_PUSHED_PREDICATE feature forced by the NO_MERGE hint. Prepare example task You have two tables ORDER and POSITION. CREATE TABLE Orders ( ID NUMBER, Customer_ID NUMBER, CreationDate DATE ); INSERT INTO Orders SELECT Level, dbms_random.random, SYSDATE - Level/10000.0 FROM DUAL CONNECT BY Level <= 1000000 ; COMMIT; ALTER TABLE Orders ADD CONSTRAINT Orders_PK PRIMARY KEY (ID); CREATE INDEX Order_Customer ON Orders(Customer_ID); EXEC DBMS_Stats.Gather_Table_Stats(SYS_CONTEXT('USERENV', 'SESSION_USER'), 'ORDERS'); CREATE TABLE Positions ( Order_ID...

 If you want avoid blocking locks while using referential integrity constraints in an Oracle-DB, it is suggested to protect a foreign key constraint by an index. Not always it is useful and necessary to protect a foreign key constraint with an index. But this question was considered separately in this blog post. The question today is: What column structure must an index have to be accepted by the Oracle DB as protection for a multi-column foreign key constraint? To answer this question, several scenarios are tested. Test setup: CREATE TABLE Dim(ID1 NUMBER, ID2 NUMBER, ID3 NUMBER, Name VARCHAR2(200)); ALTER TABLE Dim ADD CONSTRAINT Dim_PK PRIMARY KEY (ID1, ID2, ID3); INSERT INTO Dim VALUES(1,1,1, 'First'); INSERT INTO Dim VALUES(2,2,2, 'Second'); CREATE TABLE Fact(ID1 NUMBER, ID2 NUMBER, ID3 NUMBER, Name VARCHAR2(200)); ALTER TABLE Fact ADD CONSTRAINT Fact_Dim_FK FOREIGN KEY (ID1, ID2, ID3) REFERENCES Dim(ID1, ID2, ID3); Scenario 1: No index second session is blo...

Why Oracle DB allows retrospective evaluation of workload of active sessions by Active Session History (ASH) if you have Enterprise Edition and Diagnostics Pack. The default retention time for ASH is 7 days back from now, usual settings for production are around 30 days. But sometimes you need to analyze the evolution of database load over longer periods like over many years (e.g. as base for hardware planning and capital budgeting). There are less builtin alternatives yet: Increase the ASH retention time up to years leads to a huge amount of data, cumbersome or impossible to handle Using the AWR-warehouse function in an EM Cloud Control installation may fit your needs, but especially for single or less database instances this causes an inappropriate effort. What Panorama-Sampler allows you to extract some information from ASH and store it compressed as summary other periods between one hour and one day. The Panorama-GUI contains table-views and diagrams for evaluatio...

In addition to various functions, the free performance analysis tool  Panorama now also offers a browser dashboard for real-time monitoring of Oracle database performance. This shows key indicators for active sessions by wait class as well as top sessions and top SQLs in considered time period. Several values within this dashboard are presented as links which allow to dig in deeper using Panorama's  standard analysis workflows.  Choose menu entry "DBA general"/"Dashboard", the time to cover until now and a refresh rate: As long as gv$Active_Session_History has retrospective data it is shown in the graph for the chosen time period grouped by wait class. At next refresh time only the delta since last refresh is transferred from gv$Active_Session_History to your browser instance. Investigate a particular time period within the presented data The top sessions and SQLs are related to the current time frame you can select within the chart. If you select a particular ...

A problem using interval partitions may be that the number of partitions may not exceed 1.048.575 (1024*1024-1).  If using interval partitions not only the physical partitions count. Instead, the number of possible partitions between the required first range partiton and the last interval partition counts for the limit (in consideration of the used interval).  If you exceed the limit, ORA-14300 (partitioning key maps to a partition outside maximum permitted number of partitions) is raised .  So if you have a rolling window with interval partitions, where new interval partitions at the upper bound are created and older partitions are dropped if no longer needed, you may run into ORA-14300 if your initially created range partition becomes to far away from the upper bound of interval partitions.  A possible solution should be to increase the high value of the initial range partition to lower the distance to the highest interval partition.  But how to do that? ...

Unfortunately the audit trail of the Oracle-DB uses a different session identifier (AudSid) than the Active Session History (SID + Serial#). Both identifiers are available in v$Session (AudSid, SID, Serial#). So during lifetime of a session it is possible to link between the session info from v$Session an audit trail. But neither the AudSID is stored in ASH (v$Active_Session_History) nor the SID + Serial# is stored in audit trail. This prevents from combining session info of both sources after the session is closed. There is a possible way to link audit trail with ASH by establishing a logon trigger for that. The LOGOFF records in audit trail (if AUDIT SESSION is active) record also the Client_Identifier from v$Session. So supplying v$Session.Client_Identifier with the needed info allows to retrieve it from DBA_Audit_Trail.Client_ID.  This logon trigger does it: CREATE OR REPLACE TRIGGER Client_ID AFTER LOGON ON DATABASE -- Put unique session identifier into client-id to have ...

 A generally assessed poor technique is to create an own dedicated database session for each atomic DB activity. You may sometimes encounter such strategies like: processing a large amount of items in a loop, each processing step in the loop creates a DB session, executes a small set of SQL statements and terminates the session a polling process checks a SQL result one time a second, each in a new DB session But what costs are generated by frequently connecting and disconnecting DB session? The internal recording of database activity (AWR/ASH) has no answer because establishing the DB connection is not a SQL activity. A simple comparison of system load gives a fuzzy hint to the price of connection creation. Example: An idle database instance on a single host with 4 older CPU cores (Intel Xeon E312xx, 2,6 GHz) an external (not on DB host) SQLPlus client which executes a single "SELECT SYSTIMESTMP FROM DUAL" per DB session Delay between the SQLPlus calls is calculated so that o...

The recorded session activity in Oracle databases (Active Session History / ASH) enables the retrospective analysis of locking scenarios between database sessions. This post shows how the free performance analysis tool  Panorama  supports this investigation. Precondition for using ASH is the Enterprise Edition of Oracle DB and the licensing of the Diagnostics Pack. If you don't have licensed Diagnostics Pack or you are running Standard or Express Edition, then you can use the similar function of Panorama-Sampler to record the session activity. Panorama evaluates both sources (AWR/ASH or Panorama-Sampler) transparently in the same way. In general there are several ways in Panorama for retrospective evaluation of previous blocking lock situations: Top down analysis of lock dependency tree to identify a root blocking session Top down analysis of wait event dependencies to get an overview based on blocking and blocked events (new in Panorama) Bottom up analysis to find the root c...

Even if you think to have enough free space in tablespace your operation may end up in: ORA-01653 unable to extend table <xy> by <z> in tablespace <TS> The reason for this often unexpected behavior is: The table needs a contiguous free space in tablespace in next extent size to allocate a new extent. If free space in total is enough available but only in smaller slices than the required size of the extent to allocate than this will happen. Several years / Oracle versions ago fragmentation issues have been addressed by uniform extent size for tablespaces. Today this issue ist mostly addressed by locally managed tablespaces with an automatically defined limited number of used extent sizes. Locally managed tablespaces reduce the risk of fragmentation issues, but not completely. So especially if less space remains available in tablespace fragmentation sometimes becomes important. One way to check a database for the risk of running into ORA-01653 is to look fo...

A sensitive issue for DBAs and developers is often the detection and removal of indexes in Oracle databases that are not or no longer needed. In practice systems can be found that allocate more than 50% of the storage with indexes without any productive relevance. Nevertheless, this potential for a simple reduction of storage requirements and system load is regularly not used, freely after "never touch a running system" or "why should I burn my fingers here and then this index is still needed somewhere". This article demonstrates how to securely determine irrelevant indexes using the freely available analysis tool " Panorama ". Why define indexes on tables Optimizing accesses from User-SQL - Reduction of access to the result-relevant records when reading table data Guarantee of uniqueness - Declaration of unique indexes or use of the index for primary key or unique constraints Protection of Foreign Key Constraints - Preventing full table scans w...