ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier

[Problem]

Export: Release 9.2.0.8.0 - Production on Wed Jul 25 10:47:29 2007

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Connected to: Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses UTF8 character set (possible charset conversion)

About to export specified tables via Direct Path ...
Current user changed to DBAPL
. . exporting table RPT_LOCAL__01 1012208 rows exported
EXP-00056: ORACLE error 904 encountered
ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier
Export terminated successfully with warnings.

[Root Cause]

It caused by different DB version in the server , as below two version is installed:

DB1 V9.2.0.8 , while DB2 is 9.2.0.5

In operator id 's env , the ORACLE_HOME is point to 9.2.0.8, caused using higher version exp to exp data from lower version db.

[solution]
in the script , explicitly specify the path of exp , i.e:

/software/oradb1/product/9.2.0/bin/exp $RPT_CONNECT@$RPT_DB file=$expfile log=$LOGFILE direct=y recordlength=65535 buffer=10240000 compress=N tables=${tab_name} statistics=none

Today 21-Jan-2009, hit another similar case. get new findings from metalink

Doc ID:

358508.1

.

Applies to:

Oracle Server - Enterprise Edition - Version: 9.2.0.1 to 10.2.0.1
This problem can occur on any platform.

Symptoms

Export fails with:

EXP-00056: ORACLE error 904 encountered
ORA-00904: "SYS"."DBMS_EXPORT_EXTENSION"."FUNC_INDEX_DEFAULT": invalid identifier

Changes

A patchset was recently installed against the database.

Cause

After the patchset installation, the data dictionary components have not been upgraded to the patchset release (e.g. 10.1.0.4)

A patchset (e.g. 10.1.0.4) was applied to an existing ORACLE_HOME install but one or more of the patchset steps were not performed per the patchset readme to bring the database components up to the same version as the patched software as shown in DBA_REGISTRY.

If the database components versions do not match the software and the running instance, then the exp utility fails as it finds an earlier version of the exp packages in the database.

Solution

Follow the Post-Installation Tasks section of the Oracle Database Server Patch Set Notes to run the catpatch.sql script with the database started in migrate mode and then retry the export.

Connect to the database as SYSDBA and run:

SQL> STARTUP MIGRATE
SQL> SPOOL patch.log
SQL> @?/rdbms/admin/catpatch.sql
SQL> SPOOL OFF
SQL> SHUTDOWN
SQL> STARTUP

Flashback drop a table

Today I have change to use flashback drop table. A developer came to me and tell me what happend in one 10g databse.

With the help of "flashback table abc to before drop", I recovered it within minutes.
Compare to doing the same thing in 9i,
1. use lominer to find the time when the table was dropped.
2. Restored the database in anothe place
3. Perform incomplete revoery to the timestamp using backup controlfile
4. Export the table and import to production.

Guess how many time is needed.

More to add
flashback doesn't use undo tablespace.
You can recover a dropped table using Oracle’s recycle bin functionality: a dropped table is
stored in a special structure in the tablespace and is available for retrieval as long as the space
occupied by the table in the tablespace is not needed for new objects. Even if the table is no
longer in the tablespace’s recycle bin, depending on the criticality of the dropped table, you can
use either tablespace point in time recovery (TSPITR) or Flashback Database Recovery to
recover the table, taking into consideration the potential data loss for other objects stored in the
same tablespace for TSPITR or in the database if you use Flashback Database Recovery.

ora-2393 cpu_call exceed profile limit

Wed Jul 25 10:24:30 2007
Errors in file
ORA-00604: error
occurred at recursive SQL level 1
ORA-02393: exceeded call limit on CPU
usage
ORA-00604: error occurred at recursive SQL level 1
ORA-02393:
exceeded call limit on CPU usage
ORA-00604: error occurred at recursive SQL
level 1
ORA-02393: exceeded call limit on CPU usage
ORA-02393: exceeded
call limit on CPU usage

Error:  ORA 2393
Text:   exceeded call limit on CPU usage
-------------------------------------------------------------------------------
Cause:  An attempt was made to exceed the maximum CPU time for a call, a parse,
       execute, or fetch, allowed by the CPU_PER_CALL clause of the user
      profile.
Action: If this happens often, ask the database administrator to increase the
      CPU_PER_CALL limit of the user profile.

CentOS 4.4 upgrade to CentOS 5

During start transaction, hit the error message : installation failed due to the follwing reason (no reason it is shown, instead it is blank).

What I did are:
1. Remove unnecessary repository from /etc/yum.repo.d .
2. Free up disk space (/) to 11Gb. (Think it was due to this reason,as failed twice when free space was <6Gb)
3. Tried to upgrade in text mode.

Don't know which of above is the exact cause/solution, anyway it suceed after near four hours upgrade.


After that, need the folloings to make live udpate available.

cd /etc
cp yum.conf.rpmnew yum.conf
cd /etc/yum.repos.d
cp CentOS-Base.repo.rpmnew CentOS-Base.repo

Cheers.

References:
http://www.linuxfans.org/bbs/redirect.php?tid=178447&goto=lastpost&highlight=

Purging the Audit Trail

Database audit records for statement, privilege, and object auditing are stored in the table
SYS.AUD$. Depending on how extensive your auditing and retention policies are, you will need
to periodically delete old audit records from this table. The database does not provide an inter-
face to assist in deleting rows from the audit table, so you will need to do so yourself. To purge
audit records older than 90 days, execute the following as user SYS:
DELETE FROM sys.aud$ WHERE timestamp# < SYSDATE -90;

Default database tablespace

If the default tablespace is not specified during the database creation, it defaults to SYSTEM. But how do you know which tablespace is default for the existing database? Issue the following query:

SELECT PROPERTY_VALUE
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME = 'DEFAULT_PERMANENT_TABLESPACE';

The DATABASE_PROPERTIES view shows some very important information, in addition to the default tablespace—such as the default temporary tablespace, global database name, time zone, and much more.


To change the database default permenantly/temporary tablespace, use the ALTER DATABASE statement,
like this:
ALTER DATABASE DEFAULT TABLESPACE users;ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp;

Eclipse Intro error

Problem : Error message Windos "Intro error " prompted during initialistion OF "Eclipse IDE for C / C++ Developers".

Could not find a valid configuration for intro Part: intro element" in
extension: org.eclipse.ui.intro in Bundle: org.eclipse.ui.intro.universal

Check Error Log view for details

CAUSE:
No JAVA_HOME is exported.

Solution:

1. download the J2SE from java.com, choose the tar.gz file instead of the auto extracted file.
2. Export the JAVA_HOME