Month: November 2017

Database, Errors and Bugs

11g Feature: PLS-00436 Restriction in FORALL Statements Removed

 , ,

Hi All!
I was reviewing some features in Oracle and, basically, every single time I review them I find something new. Seems Oracle Databases’ features are near to infinite and we frequently find some that can really add value to our solutions.

So I decided to make a serie of posts with really quick notes about each one of them.
You can see all posts in this serie in my page of posts and some others more.

Ready? Here it goes:

11g Feature: PLS-00436 Restriction in FORALL Statements Removed

In 11g, the PLS-00436 restriction has been removed, meaning individual elements of a collection can be referenced with SET and WHERE clauses in a FORALL construction.

Please check the following example, setting text of my_table to ‘Line x’ where x is the line number (also ID column):

DECLARE
  TYPE t_test IS TABLE OF my_table%ROWTYPE;
  l_test t_test;
BEGIN
  SELECT * BULK COLLECT INTO l_test FROM my_table;
  
  FOR i IN l_test.first .. l_test.last LOOP
    l_test(i).text := 'Line ' || i;
  END LOOP;

  FORALL i IN l_test.first .. l_test.last
    UPDATE my_table SET text = l_test(i).text WHERE id = l_test(i).id;
  COMMIT;
END;
/
Database, Linux, Shell Scripts

How to Setup Automatic Startup and Shutdown of an Oracle Database on Linux (Not Using Oracle-Restart)

 , , ,

Ok, we all have done it several times. I, myself, made some scripts to do it in past. However, do you know there is an official way/script for that?
You can accomplish this with dbstart and dbshut scripts, which are located in the $ORACLE_HOME/bin directory.
This is documented for 12.1 in Stopping and Starting Oracle Software .

Of course that, if you have Oracle Clusterware configured, you can use Oracle Restart and SRVCTL tool, and Clusterware automatically starts and stops the Oracle database instances and listeners. Which is way better.
This post refers to official procedure in case you haven’t Clusterware configured.

Quick Guide:

More“How to Setup Automatic Startup and Shutdown of an Oracle Database on Linux (Not Using Oracle-Restart)”

Database

11g Feature: Skip Locked Syntax in SELECT FOR UPDATE

 ,

Hi All!
I was reviewing some features in Oracle and, basically, every single time I review them I find something new. Seems Oracle Databases’ features are near to infinite and we frequently find some that can really add value to our solutions.

So I decided to make a serie of posts with really quick notes about each one of them.
You can see all posts in this serie in my page of posts and some others more.

Ready? Here it goes:

Skip Locked Syntax in SELECT FOR UPDATE

This is an 11g feature, and it’s a bit controversial. Why?
The SELECT FOR UPDATE statement is well known and responsible by several problematic operations, mainly in transactional databases. It’s not rare to face issues like errors below when trying to perform large updates on database:

ORA-30006: resource busy; acquire with WAIT timeout expired
ORA-00054 resource busy and NOWAIT specified

Worse than this, if a select for update task aborts, a zombie process may hold the row locks long term, requiring DBA intervention.

In 11g, the clause SKIP LOCKED has been released, allowing to skip-over any rows that are already locked. Check below for a simple example:

select COLUMN1, COLUMN2 from MYTABLE 
where COLUMN1='DESIRED_VALUE' for update skipped locked;

This is very useful in transaction environments, specially when facing errors mentioned above, however can cause logical corruption.
The reason is obvious, if some rows be in lock, those are not being updated. In this case, if the table has 100 entries where COLUMN1=’DESIRED_VALUE’ but 10 of them are in lock, only 90 will be actually selected, making statement invalid in some circumstances.

This is very useful in transaction environments, specially when facing errors mentioned above, however can cause logical corruption.
The reason is obvious, if some rows be in lock, those are not being updated.

Additional Note: In some cases, increasing the table’s initrans allows more buckets for locking:

alter table MYTABLE move initrans xxxx;

Here is a very interesting post by Jonathan Lewis about it.

See you next week!

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, GoldenGate

Downstream database with ORA-00317: file type 0 in header is not log file

You missed some Downstream archived log?

Is this archived log on Downstream area either it’s not read by Logminer.

Try to run to the hills or read GrepOra posts.

In alert log is tracing like these:

ORA-00317: file type 0 in header is not log file
ORA-00334: archived log: '/oracle/dowstream-archive/2_136361_87643997.dbf'
LOGMINER: Error 317 encountered, failed to read corrupt logfile /oracle/dowstream-archive/2_136361_87643997.dbf
LOGMINER: Encountered error 1291 while adding logfile /oracle/dowstream-archive/2_136361_87643997.dbf to session 1

Copy the archived log from RMAN to Downstream, register logical logfile. Wait for while to Logimer start to provide LCR GoldenGate Integrated Extracts to Logminer new registered archived log.

Try register achived log on Dowstream database as below:

ALTER DATABASE REGISTER LOGFILE '/oracle/dowstream-archive/2_136361_87643997.dbf' FOR 'OGG$CAP_EXT_1';
ALTER DATABASE REGISTER LOGFILE '/oracle/dowstream-archive/2_136361_87643997.dbf' FOR 'OGG$CAP_EXT_2';

 

integratedcapture[1]

Database, Errors and Bugs, PostgreSQL

Oracle Heterogeneous Services for PostgreSQL (ODBC Driver): Error (HY000,NativeErr = 1)

Hi all!
Some time ago a client reported issues when integrating Oracle and PostgreSQL. The error:

ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
No query has been executed with that handle;
Could not send Query(connection dead) {HY000,NativeErr = 1}

Braking down errors:
– Oracle: Connection from ORACLE to a non-Oracle system returned this message
– PostgreSQL: {HY000,NativeErr = 1} Could not send Query(connection dead)

Both are general errors:
– Oracle’s one is for any error returned by remote service, when using Oracle Heterogeneous Services (old Database Gateway).
– Postgre’s one is for connections ended.

I also found some other similar errors:
– Oracle: ORA-28511: lost RPC connection to heterogeneous remote agent using SID
– PostgreSQL: {08S01,NativeErr = 26} Error fetching next row

In summary, the root cause was a firewall configuration ending connection. But what I want to share with you the workaround. 🙂
You know that sometimes, due certain rules, firewall rules may require formal change requests and procedures, so what you can do on database side is basically disable parameter UseDeclareFetch (default is false) in ODBC descriptor, as per below.

More“Oracle Heterogeneous Services for PostgreSQL (ODBC Driver): Error (HY000,NativeErr = 1)”