ORA-38760: This database instance failed to turn on flashback database

ORA-38760: This database instance failed to turn on flashback database
As per Oracle :

Error: ORA-38760

Cause: Database flashback is on but this instance failed to start
generating flashback data. Look in alert log for more specific
errors. Action: Correct the error or turn off database flashback.


Solution A:

To Enable flashback:

1.Shutdown the database either in immediate or normal mode.

2.Mount the database.

3.Enable flashback.

SQL>Alter database flashback on;

4.Open the database.

Sometimes even after solution A you are still getting errors:

SQL> startup mount;
ORACLE instance started.

Total System Global Area 1.4798E+10 bytes
Fixed Size 2046472 bytes
Variable Size 671090168 bytes
Database Buffers 1.4110E+10 bytes
Redo Buffers 14729216 bytes
Database mounted.
SQL> alter database flashback off;

Database altered.

SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-38760: This database instance failed to turn on flashback database

SQL>

Then you should apply solution B.

Solution B:

1. Startup mount.

2. Check db_recovery_file_dest parameter and ensure this directory exists.

3. Check restore points:

select NAME,SCN,GUARANTEE_FLASHBACK_DATABASE,DATABASE_INCARNATION#
from v$restore_point;

4. Drop restore point:

drop restore point ;

5. alter database flashback off;

6. Shutdown immediate;

7. Startup

Mining Information from the listener Log

Mining Information from the Listener Log

An Oracle database infrastructure has several components — the database, the listener, and the clustering components (CRS, CSS, ONS, and so on, if it’s a RAC database). All these components produce extensive logs to let you know what’s happening behind the scenes. These logs show information vital to understanding the working of the database. Perhaps the most popular and most commonly used is the database alert log, which offers a running commentary on the operation of the database. You may find many utilities and tools, including the Grid Control and Database Console interfaces from Oracle itself, to parse the alert log and reveal valuable information.

However, a very useful source of information is often overlooked — the listener log. The listener log shows some information that is not available anywhere else (for example, the service names used by the clients). Some of the information can also be obtained by other means, such as via the IP address of the clients recorded in audit trails.
But even in such cases, the listener log provides a non-intrusive source for which you don’t have to place instrumentation inside the database, as you must do when turning on auditing. In addition, listener logs also record the listener operations, both successful and unsuccessful, which can show attacks against the listener. Since listener is usually the target of many database attacks, this information can reveal valuable clues and help you build better defenses. In summary, listener logs provide far too much valuable information to be ignored.

Part 1
Part 2
Part 3

Diagnosing Oracle® Database Performance on AIX®

For Oracle Database environments, ongoing performance monitoring and tuning activities are essential to getting the most of your systems investment. In order to be most effective, monitoring and tuning must be performed at multiple levels of the solution stack. This includes the hardware, Operating System, Database and Application levels.

This paper discusses two commonly available performance monitoring tools – Oracle Statspack and IBM NMON – and how they can be used to monitor and analyze possible performance issues for Oracle Database applications running in an AIX/System p™ server environment. In Oracle10g environments, Automatic Workload Repository (AWR) reports can be used in place of Statspack. A number of real-world examples of Statspack and NMON data are provided.

This paper assumes that the reader is familiar with Oracle Database as well as the AIX/System p-server environment.