Oracle VM Site Review - Oracle VM Health Check
view counter

Database Feed

Oracle Database, Oracle 10g, Oracle 11g, Oracle XE, Oracle RAC, Oracle Instant Client, Oracle Data Guard and Oracle Exadata resources, news, and support articles.

Encrypted database case #1

Encrypted database case #1

Truncate – 2

Following on from my earlier comments about how a truncate works in Oracle, the second oldest question about truncate (and other DDL) appeared on the OTN database forum“Why isn’t a commit required for DDL?”

Autonomous transaction to the rescue

System is in manitance mode. Please try again later OBIEE

When trying to update any reports in OBIEE the below errors appears :-to solve this issue just follow the screen :-


The old question about truncate and undo (“does a truncate generate undo or not”) appeared on the OTN database forum over the week-end, and then devolved into “what really happens on a truncate”, and then carried on.

Less calls…more performance (part 2)

In the previous post, I mentioned that for a programming environment fetching rows from the database, then the method of

  • open a ref cursor
  • issue a fetch call
  • close the ref cursor

might not be appropriate for those situations where the result set is known be a single row (eg primary key lookup).
A better option might be to call a procedure and get those outputs as parameters.
And I broke a cardinal rule… I effectively said “Here’s something that I know to be true…

Less calls…more performance

In various programming environments, a common metaphor is to open a cursor on the database (a REF CURSOR in Oracle parlance), return that cursor handle to the calling environment, and then that cursor is used to fetch or “fill” a data object, which may map to a grid on screen, or just to an array in memory.
And that’s totally fine – its an effective means to obtain a result set from the database to the calling environment.
For example, a typical PLSQL routine might look like:


Clear the cache memory in oracle database for performance tuning in test environment

I am checking SQL Query execution time in Testing database.

SQL Query has been taken 8 minutes to execute in First time. After that, it has been taken 5 seconds to execute in second time. I think, it has been taken output from buffer memory. So execution is fast.

To check actual time of execution time, i have cleared the buffer using below command and re-execute the query.

alter system checkpoint;
alter system flush shared_pool;
alter system flush buffer_cache;

Oaktable World 2015 San Francisco, Oct 26 & 27

Agenda for Oaktable World 2015, located at Creativity Museum, is

APEX 5 Source Used attribute - tolerating less mistakes

If you've upgraded to APEX 5 and find yourself with an error complaining about the 'Source Used' attribute:
then you should thank APEX 5 for finding (and no longer tolerating) a logic bug in your application.

view counter