Syed Saad Ali

Oracle ACE Pro

Oracle Solution Architect

Oracle E-Business Suite

Oracle Cloud Infrastructure

Oracle Fusion Middleware

Oracle Database Administration

Oracle Weblogic Administration

Syed Saad Ali

Oracle ACE Pro

Oracle Solution Architect

Oracle E-Business Suite

Oracle Cloud Infrastructure

Oracle Fusion Middleware

Oracle Database Administration

Oracle Weblogic Administration

Author: Syed Saad Ali

April 16, 2023 OUTPUT POST PROCESSOR (OPP) LOG CONTAINS ERROR
APPS DBA

[edsanimate_start entry_animation_type= “fadeIn” entry_delay= “0” entry_duration= “1” entry_timing= “linear” exit_animation_type= “” exit_delay= “” exit_duration= “” exit_timing= “” animation_repeat= “infinite” keep= “yes” animate_on= “load” scroll_offset= “” custom_css_class= “”]OUTPUT POST PROCESSOR (OPP) LOG CONTAINS ERROR “JAVA.LANG.OUTOFMEMORYERROR”[edsanimate_end]

 

(more…)

April 10, 2023 Tablespace Level Fragmentation
Installation/Configurations12c

Tablespace Level Fragmentation in Oracle Database

Introduction

In this article, I will discuss tablespace level fragmentation, which causes slowness and wastage of space. Fragmentation is a common issue in Oracle databases due to excessive dml operations like insert followed by an update and delete operations.

Brief Explanation:

In Oracle, tablespace level fragmentation refers to space fragmentation within a tablespace, leading to inefficient storage utilization and potential performance issues. It occurs when free space within the tablespace is fragmented into smaller, non-contiguous extents.

Tablespace level fragmentation can occur due to various reasons, such as:

Data Insertions, Updates, and Deletions: Frequent data modifications can result in fragmented free space within the tablespace as objects grow and shrink.

Improper Storage Allocation: Inadequate or incorrect storage allocation settings can lead to fragmentation, especially if the initial extent sizes are too small or if automatic segment space management is not utilized.

Uneven Object Growth: When objects within the tablespace grow at different rates, it can lead to uneven distribution of free space and fragmentation.

Inefficient Reorganization or Maintenance: Lack of regular tablespace maintenance activities, such as the reorganization or shrinking of objects, can contribute to fragmentation over time.

The presence of tablespace level fragmentation can negatively impact database performance, leading to slower query execution, increased I/O operations, and inefficient use of storage resources.

Migrating tables and indexes to new tablespaces can indeed be an efficient and effective way to defragment and shrink a large tablespace in Oracle. This approach involves moving the objects from the fragmented tablespace to a new, properly-sized tablespace, thereby consolidating free space and optimizing storage utilization. Here’s an overview of the process:

Step 1. Log in with the dba account and create new tablespaces for the database user.

Sample SQL:
create tablespace XX_ERP2 datafile ‘/path/to/XX_ERP2.dbf’ size 256m autoextend on next 128m maxsize unlimited;

Step 2. Log in with the Database owner’s username/password

Step 3. Run the script below to generate a table migration script for migrating tables to a new tablespace

spool /home/oracle/movTbl.sql
select ‘alter table ‘ || SEGMENT_NAME || ‘ move tablespace XX_ERP2;’
FROM dba_Segments a,
dba_data_files b
WHERE b.file_id=a.relative_fno
and a.tablespace_name=’XX_ERP’ and segment_type=’TABLE’
order by FILE_NAME,segment_name;
spool off;

Step 4. Run the script below to generate an Index migration script for migrating the Index to a new tablespace

spool /home/oracle/movIndex.sql
 SELECT ‘alter index ‘ || SEGMENT_NAME || ‘ rebuild tablespace XX_ERP2;’
FROM dba_Segments a, dba_data_files b
WHERE b.file_id = a.relative_fno
AND a.tablespace_name = ‘XX_ERP’
AND segment_type = ‘INDEX’
ORDER BY FILE_NAME, segment_name;
spool off;

Step 5. Run the script below to generate the LOB Segments script for migrating the LOB Segments to a new tablespace if available.

spool /home/oracle/movLobSeg.sql
select ‘ALTER TABLE ‘ || table_name || ‘ move lob(‘ || COLUMN_NAME || ‘) STORE AS (TABLESPACE XX_ERP2);’
from dba_tab_columns
where owner=’XX_ERP’ and data_type=’CLOB’;
spool off;

Step 6. Check if anything is missing in the Original Tablespace to be Migrated

set lines 300
col owner format A26
col segment_name format A26
col segment_type format A26
col tablespace_name format A26
col relative_fno format 99999
col file_name format A50
SELECT owner, segment_name, segment_type,a.tablespace_name, a.relative_fno, b.file_name
FROM dba_Segments a,
dba_data_files b
WHERE b.file_id=a.relative_fno
and a.tablespace_name=’XX_ERP’
order by FILE_NAME,segment_name;

Step 7. Do not forget to change the default tablespace of the user to the Newly Created One

ALTER USER default tablespace XX_ERP2;

Step 8. Change the Old Tablespace Offline once all the Objects are transferred to the newly created Tablespace with the Scripts Generated.

alter tablespace XX_ERP offline;

 

March 11, 2023 Cleaning Up older records in AUD$ table
Installation/Configurations19c

Cleaning Up older records in AUD$ table

Auditing refers to the process of monitoring and collecting specific user database actions and storing this information in designated tables. It is a feature that is consistently enabled in Oracle Database. During or after the execution of audited SQL statements, Oracle Database generates audit records. However, it’s important to note that the growth of the AUD$ table can have an impact on the overall performance of the database.

The AUD$ table is primarily used for the purpose of database auditing, including:

  1. Storing audit records: The AUD$ table serves as the repository for storing the audit records generated by Oracle Database during or after the execution of audited SQL statements.

  2. Tracking user actions: The table records information about various user actions, such as logins, logouts, data modifications, privilege changes, and other database activities.

  3. Compliance and security: The audit records stored in the AUD$ table are essential for meeting regulatory compliance requirements and ensuring the security of the database. They provide an audit trail that can be reviewed for investigation, analysis, and forensic purposes.

  4. Monitoring user activity: By analyzing the data in the AUD$ table, administrators can monitor and analyze user activity to identify potential security breaches, suspicious behavior, or policy violations.

  5. Reporting and analysis: The AUD$ table data can be queried and analyzed to generate reports on user actions, system usage, and overall database activity, enabling administrators to gain insights and make informed decisions regarding database performance, security, and compliance.

While the AUD$ table is critical for auditing purposes, it’s important to manage its growth effectively to avoid performance impacts on the database. This can involve implementing retention policies, archiving old audit data, or utilizing other auditing features available in Oracle Database to strike a balance between auditing requirements and performance considerations.

Starting from Oracle Database 11g and onwards, when the AUDIT_TRAIL parameter is set to either the “DB” or “DB_EXTENDED” value, the auditing feature is activated by default. This means that the database will automatically generate audit records for audited SQL statements and store them in the AUD$ table. The default value for AUDIT_TRAIL is “DB”, indicating that the database auditing is enabled.

By setting AUDIT_TRAIL to “DB”, the database ensures that basic auditing is performed, capturing essential information about user actions and database activities. The “DB_EXTENDED” value provides more detailed auditing, capturing additional information such as bind variables and other specific details related to the SQL statements.

It’s important to note that while the AUDIT_TRAIL parameter is set to “DB” by default, it can be modified to other values based on specific auditing requirements. This allows administrators to customize the auditing configuration according to their needs, whether it involves more detailed auditing, sending audit records to the operating system audit trail, or redirecting them to a different destination.

Overall, starting from Oracle Database 11g, AUDIT_TRAIL is activated by default, set to “DB”, ensuring that the database generates audit records for audited SQL statements, unless it is explicitly disabled or modified to a different value.

To maintain the AUD$ table and manage its growth effectively, you can follow these step-by-step actions:

1. First, Check your current parameters

SQL> show parameter                                                                 

    NAME           TYPE    VALUE
--------------   -------   -----  
audit_trail       string    DB

     2. Let us check which tablespace is using by AUD$ table. Default tablespace is in SYSTEM tablespace.

SQL> select owner,segment_name,segment_type,tablespace_name,(bytes/1024/1024/1024) as SizeinGB from dba_segments where segment_name=’AUD$’;

OWNER SEGMENT_NAME     SEGMENT_TYPE TABLESPACE_NAME SizeinGB
------ -------------- ------------ ---------------- ----------
SYS         AUD$        TABLE          SYSTEM          115

    3. In In this case, our Auditing table AUD$ is in SYSTEM tablespace so we will create a new tablespace named “AUDIT_TS”  and then move the AUD$ to our newly created Tablespace

CREATE TABLESPACE AUDIT_TS DATAFILE ‘/path/to/audit_ts.dbf’ SIZE 10G AUTOEXTEND ON NEXT 8K MAXSIZE UNLIMITED;

 Note:  Add Datafiles More Datafiles to the Tablespace created according to the size of your AUD$ Table

    4. After creating a new tablespace run the below command as sysdba user.

BEGIN
DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,audit_trail_location_value => 'AUDIT_TS');
END;
/

    5. Now check AUD$ table is moved to our new tablespace with the query given below:

SQL> select owner,segment_name,segment_type,tablespace_name,(bytes/1024/1024/1024) as SizeinGB from dba_segments where segment_name=’AUD$’;

OWNER SEGMENT_NAME     SEGMENT_TYPE TABLESPACE_NAME SizeinGB
------ -------------- ------------ ---------------- ----------
SYS         AUD$        TABLE          AUDIT_TS       115

     6. Now we can use some options to maintain for SYS.AUD$ table.,

Here are Some options that can be used to Maintain and Purge the Audit Records:

1: Regularly run the truncate command for SYS.AUD$ table by Syntax given below:

TRUNCATE TABLE SYS.AUD$;

 2: Purge the audit trail records by using DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL procedure by Syntax given below:

BEGIN
DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(
AUDIT_TRAIL_TYPE => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
USE_LAST_ARCH_TIMESTAMP => TRUE );
END;
/

 3: Initialize the clean job. If you haven’t moved the AUD$ table out of the SYSTEM tablespace, then the below script will move the AUD$ to the SYSAUX tablespace by default. Syntax is:

BEGIN
DBMS_AUDIT_MGMT.init_cleanup(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,default_cleanup_interval => 12 /* set_hours */);
END;
/

 Check whether initialization is a success or not by the Procedure Given Below:

SET SERVEROUTPUT ON
BEGIN
IF DBMS_AUDIT_MGMT.is_cleanup_initialized(DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD) THEN
DBMS_OUTPUT.put_line('YES');
ELSE
DBMS_OUTPUT.put_line('NO');
END IF;
END;
/
February 24, 2023 Oracle Database 19C Enterprise Manager Express Not Working
Installation/Configurations19c

Oracle Database 19C Enterprise Manager Express Not Working

Our client, who is currently utilizing Oracle 19c Database, has expressed their desire to leverage Oracle Enterprise Manager (OEM) to monitor and analyze their database usage.

Now Let us check some values from the database

SQL> select dbms_xdb_config.gethttpsport from dual;
GETHTTPSPORT
------------
   0

SQL> select dbms_xdb_config.gethttpport from dual; GETHTTPPORT ------------ 0

As we see ‘0’ in both the above statements we will execute the procedures given below.

SQL> exec dbms_xdb_config.sethttpsport(5500);

SQL> exec dbms_xdb_config.sethttpport(5550);

Let’s assume that you still cannot able to connect, check the wallet files. Check the directory of wallet files, run this command fist;

[oracle@devdb]# lsnrctl stat | grep HTTP

output is;

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcps)(HOST=localhost)(PORT=5500))(Security=(my_wallet_directory=/u01/app/oracle/admin/devdb/xdb_wallet))(Presentation=HTTP)(Session=RAW))

Now you have to copy the wallet directory and run ls -l command to check the permission of the wallet files.

[oracle@devdb]# cd /u01/app/oracle/admin/devdb/xdb_wallet
[oracle@devdb xdb_wallet]# ls -l
-rw——-. 1 oracle oracle 3880 Jan 16 10:24 cwallet.sso
-rw——-. 1 oracle oracle 3835 Jan 16 10:23 ewallet.p12

 

Now as you see it is having the permission on user level only and not the Group level. You have to set it with -rw-r. Changing mode to 640 to allow for the group to read the wallet files makes the EM Express page available via browser.

[root@devdb xdb_wallet]#chmod 640 ewallet.p12

oracle@devdb xdb_wallet]#chmod 640
[oracle@devdb xdb_wallet# ls -l
-rw-r—–. 1 oracle oracle 3880 Jan 16 10:35 cwallet.sso
-rw-r—–. 1 oracle oracle 3835 Jan 16 10:35 ewallet.p12

Now you can connect with browser.

https://devdb:5500/em