we got a error message when export user data from 10.2.0.3 database using 10.2.0.4 oracle client..

exporting table TKEYTAB
EXP-00008: ORACLE error 904 encountered
ORA-00904: “IFREEPOOL”: invalid identifier

some notes may help as remind.

Applies to:
Oracle Server – Enterprise Edition – Version: 10.2.0.3 to 10.2.0.4
This problem can occur on any platform.

Symptoms
Export reports ORA-00904 “IFREEPOOL”: invalid identifier while using a version 10.2.0.4.0 export client to export from a 10.2.0.3.0 database.

Export Log File ————— . . Export der Tabelle CALCULATEDFIELDS EXP-00008: ORACLE-Fehler 904 aufgetreten ORA-00904: “IFREEPOOL”: invalid identifier Cause
This is an expected behaviour.

The version of the Export utility must be equal to the earliest version of the source or target database. Here, the source database is based on release 10.2.0.3.0 and hence the export client has to be a version 10.2.0.3.0.

An export client of a later release cannot be used for the following reasons:

•The export utility is continuously accessing dictionary objects such as SYS.EXU9LOB.
•Starting with release 10.2.0.4.0 we introduced additional columns such as ‘IFREEPOOL’. This column is not available in 10.2.0.3.0 and hence the client cannot handle this and ORA-00904/EXP-00008 appears.

Client 10.2.0.4.0 is not supported to export from 10.2.0.3.0 database.
Solution
FIX

The version of the Export utility must be equal to the earliest version of the source or target database.

WORKAROUND

None. – This is an expected behaviour.

a email was arrived from a friend to query about the abnormal information in trace file which contains something like “opiino: Attach failed!….”. while left no “ORA-” error msg in alert file.

after checking the support.oracle.com, I had something to share,check below:

It’s quite useful.

“opiino: Attach failed! error=-1 ifvp=0″ written in Database UDUMP file [ID 399727.1]

…

---

Modified:Jun 10, 2011Type:PROBLEMStatus:PUBLISHEDPriority:2

Comments (0) To Bottom

In this Document
  Symptoms
Changes
Cause
Solution
References

---

 

 

Applies to:

Oracle Server – Enterprise Edition – Version: 10.2.0.1 to 10.2.0.4 – Release: 10.2 to 10.2
Oracle Net Services – Version: 10.2.0.1.0 to 10.2.0.4.0   [Release: 10.2 to 10.2]
Information in this document applies to any platform.
Checked for relevance on 09-JUNE-2011

Symptoms

When a client process is abnormally disconnected from the Database (server) process, specifically at a point where the Database needs to negotiate and communicate certain OCI / TWO-TASK data to the client such as with character sets, OCI, etc., then the Database may throw one of the following errors in a UDUMP trace:

opiino: Attach failed! error=-1 ifvp=0

or


opiino: Attach failed! error=-1 ifvp=(nil)

Changes

Perhaps an abnormally high increase in connection activity from App Servers or a network condition or change causing instability.

Cause

There are various reasons why this error might be reported by the Database and some are offered below, but it should be noted that it is “post-connection” generated meaning that the Client connection has been handed off successfully by the Listener process (shown as “Established” in the listener log and services summary) and is generated by the Database itself.

1. The error is being caused by an abnormal disconnection at the OPI / OCI (TWO-TASK) level of the Client process by the Database.
This will occur if the client is terminated (abnormally) before the Database can complete the TWO-TASK communication functions. Please see the reference note on TWO-TASK analysis and resolution.

2. Another possible cause and one that can contribute to a high increase of connections or a cause of disconnections, is a default (or lower) setting of the INBOUND_CONNECT_TIMEOUT value introduced with 10g and which was found to have a default value that was too low for many environments. Another error that might be reported in the Database alert log for the same type of abnormal disconnection and especially with 11g, is ORA-609 “opiodr aborting process unknown ospid”. These two are very similar in that they are generated from the “opi” Database layer and due to an abnormal client termination (with the “ORA-609″ being more common in 11g and the “Attach failed” being more common in 10g).

3. Another potential (but rare) cause is if the Listener being used for Client access is of a LOWER version than the Database being accessed. For example, using a 9.2.x listener to access a 10.x Database which is not certified or supported and will cause abnormal conditions for connections.

Solution

1. Due to the fact that this is a generic error within the Database OPI code, the error itself is not useful in determining any actual cause or in assisting to provide a solution.
Analysis needs to be done on what was happening between the clients and the Database server at the time these were thrown and which caused the failure.
Some examples of questions to ask and data to collect:
- was the network between the affected clients and the Database in a stable condition?
- was there a sudden and abnormal increase in connection activity that may have flooded the Database with connections?
- was the Client abnormally terminated on its side (such as a machine failure)?

2. To ensure that this is not related to a possible INBOUND_CONNECT_TIMEOUT issue (IBCT), make certain to set both the IBCT in the listener.ora file and sqlnet.ora file on the Database Server side (these are INBOUND CONNECT settings so only affect incoming client connections requests) to a higher value, such as 120.
Please note, that this increase in IBCT will not have a negative effect on how long a client connection will take to be established. This setting is a security feature and is a threshold used to determine how long to wait before an unresponsive connection is terminated (used specifically to prevent Denial of Service attacks on the Database). See the notes referenced for complete details.

3. If this occurs ALL the time and there is an indication that a lower version listener is used for a higher version Database, then the same (or higher) version listener should be started and used for the Database.
See reference notes following on this.

References

NOTE:1012295.102 – HOW TO SUPPORT TWO-TASK COMMON ERRORS
NOTE:149628.1 – Creating Multiple Listeners on UNIX – Including Migration or Upgrades
NOTE:151812.1 – Setting up Multiple Listeners on Windows – Including Migration or Upgrades
NOTE:345197.1 – Connections that Used to Work in Oracle 10.1 Now Intermittently Fail with ORA-3113,ORA-3106 or ORA-3136 from 10.2 Onwards
NOTE:609.1 – ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log
NOTE:1121357.1 – Troubleshooting ORA-609 : opiodr aborting process unknown ospid

Related …

Products …

• Oracle Database Products > Oracle Database > Oracle Database > Oracle Server – Enterprise Edition > RDBMS > Generic issues-rollback redo logs db creation
• Oracle Database Products > Oracle Database > Net Services > Oracle Net Services > SQL*Net > Listener issues

Errors …

ORA-609

与她交流实在太伤元气了，但每次又不得不做，没办法，责任所在。几个小时，竟然是几个小时，长时间的东扯西扯，还要不时的把她从无关的话题中拉回来，时刻提醒谈话的重点、主题。我很奇怪，世间竞有如此之人，不顾他人感受，只想到自己，这是何等的自私，让我觉得发指，但不时的宽容又从她那里放出来，让你觉得一丝希望，但每每此时，新的、无关的话题又被她启动，我们的谈话又奔向远方。

“人不能要求别人，为自己做任何事情”，这是我的观点。所以，这提醒我，己所不欲、勿施于人。人，不能自顾自己，不及他人，尤其你的动向会影响到其他人的时候。我是多么希望她能认同这浅显的道理。

在逛旅游论坛的时候，偶然看见这篇文章。文风不错，是我喜欢的类型，转载贴在这里。

原文在:http://www.daododo.com/viewthread.php?tid=23481&extra=&page=1

如果是大学时候跟朋友去长滩岛，一定会被动的迷失在其中的，mars哥的歌词里面说：beautiful girl~all over the world~现在你不用去周游世界了，因为世界各地的美女都在这里，没有夜店的浓妆，身着各式比基尼，所有的优点都暴露在热带的阳光之下；如果是刚工作那 会去长滩岛，一定会主动要求迷失在这里的，因为没有毫无建树而庸庸碌碌的工作，没有同事冷漠的目光，没有巨大差距下的渺小感，只有热情的妹子，火辣的妹 子，开朗的妹子……各种妹子……

好吧，如果年轻那会没有记忆中那么不堪，不会大夏天买个冰淇淋在西单门口傻坐着，更没有满脑子都在想哪里有大片的辣妹，那么那会我也至少也是个吃货……

吃货还是不要去长滩了，一只1斤的龙虾220人民币， 两只一斤半的螃蟹做好了摆在你面前90人民币，还有130元18寸大的四季披萨，脸大的汉堡，屁股大的盆装水果缤纷雪糕，各种的100%芒果汁，菠萝汁， 好吧不去饭店，去超市转转，有种瓶装奶第一次喝完，每天都想喝，雀巢的雪糕里面夹着棉花糖和巧克力豆……每天都能发现新的美食，年轻的时候如果学会自制， 也不会发展成今天的这个体型……

由于每天活在国内的媒体中，活在网络的激愤中，报完团之后得知中菲开始对峙，无数次想去退钱，因为怕当地人仇恨的目光，可是到了之后才发现人家电视台放的 最多的是单身总统和韩国籍美女的各种新闻，当地人开车会主动等你过马路，3块钱的小费换来的是殷勤的服务和感谢的目光，司机师傅不会因为你语言不通就拉着 你转，买家也不会因为价钱不满意而给你短斤缺两，不知是信仰天主的缘故还是良好的契约精神，骗你最多的人反倒是领队和当地的台湾籍地接。

回来看有人还在刨历史，大讲黄岩岛的历史归属，其实大可不必，元也好，明清也好，这历史不属于这个党派，也不属于这个国家，弱肉强食而已，何必披上道理的皮。内心和武力都强大的国家占领最多的资源，和狗吃屎一样，自然道理而已。

读万卷书，行万里路总有个先后顺序，我想象不到，那个总是欲望打败自制力的年代，我该怎样分清梦想和现实……

1.create a text based file for spfile

SQL> create spfile from pfile=’f:\initAAA.ora’;

file created.

2.edit the flat file just created in the path of control file

3.start the database using pfile just created and recreate a new spfile
SQL> startup
Total System Global Area 612368384 bytes
Fixed Size 1304728 bytes
Variable Size 167774056 bytes
Database Buffers 436207616 bytes
Redo Buffers 7081984 bytes

SQL> show parameter spfile;

NAME TYPE
———————————— ————-
VALUE
——————————
spfile string
C:\ORACLE\PRODUCT\10.2.0\DB_1\
DATABASE\SPFILEAAA.ORA

changing the path of REDO log file is the same as datafile and temporary file

1.keep the instance shutdown
SQL> SHUTDOWN IMMEDIATE
2.host copy the datafile to new location

SQL> HOST COPY F:\oradata\aaa\REDO01.DBF F:\oradata2\aaa\REDO01.DBF
The system cannot find the file specified.

SQL> HOST COPY F:\oradata\aaa\REDO01.LOG F:\oradata2\aaa\REDO01.LOG
1 file(s) copied.

SQL> HOST COPY F:\oradata\aaa\REDO02.LOG F:\oradata2\aaa\REDO02.LOG
1 file(s) copied.

SQL> HOST COPY F:\oradata\aaa\REDO03.LOG F:\oradata2\aaa\REDO03.LOG
1 file(s) copied.

3.start the database to mount stage

SQL> STARTUP MOUNT;
Total System Global Area 612368384 bytes
Fixed Size 1304728 bytes
Variable Size 167774056 bytes
Database Buffers 436207616 bytes
Redo Buffers 7081984 bytes

3.change the path of redo log file
SQL> alter database rename file ‘F:\ORADATA\AAA\REDO01.LOG’ to ‘F:\ORADATA2\AAA\REDO01.LOG’;

database altered

SQL> alter database rename file ‘F:\ORADATA\AAA\REDO02.LOG’ to ‘F:\ORADATA2\AAA\REDO02.LOG’;

database altered

SQL> alter database rename file ‘F:\ORADATA\AAA\REDO03.LOG’ to ‘F:\ORADATA2\AAA\REDO03.LOG’;

database altered

SQL> ALTER DATABASE OPEN;

database altered

SQL>
SQL> select status from v$instance;

STATUS
————————
OPEN

ok,everything was done!!

1.oracle was on the open status,and check the datafile information
SQL> col file_name for a50
SQL> select file_id,file_name from dba_data_files;

FILE_ID FILE_NAME
———- —————————————–
4 F:\ORADATA\AAA\USERS01.DBF
3 F:\ORADATA\AAA\SYSAUX01.DBF
2 F:\ORADATA\AAA\UNDOTBS01.DBF
1 F:\ORADATA\AAA\SYSTEM01.DBF
SQL> shutdown immediate
database closed

2.copy the datafile to new path
SQL> host copy F:\ORADATA\AAA\USERS01.DBF F:\ORADATA2\AAA\USERS01.DBF
1 file(s) copied.

SQL> host copy F:\ORADATA\AAA\SYSAUX01.DBF F:\ORADATA2\AAA\SYSAUX01.DBF
1 file(s) copied.

SQL> host copy F:\ORADATA\AAA\UNDOTBS01.DBF F:\ORADATA2\AAA\UNDOTBS01.DBF
1 file(s) copied.

SQL> host copy F:\ORADATA\AAA\SYSTEM01.DBF F:\ORADATA2\AAA\SYSTEM01.DBF
1 file(s) copied.

3.start database mount and change the path of datafile

SQL> startup mount
Total System Global Area 612368384 bytes
Fixed Size 1304728 bytes
Variable Size 167774056 bytes
Database Buffers 436207616 bytes
Redo Buffers 7081984 bytes

SQL> alter database rename file ‘F:\ORADATA\AAA\USERS01.DBF’ to ‘F:\ORADATA2\AAA\USERS01.DBF’;

database altered

SQL> alter database rename file ‘F:\ORADATA\AAA\SYSAUX01.DBF’ to ‘F:\ORADATA2\AAA\SYSAUX01.DBF’;

database altered

SQL> alter database rename file ‘F:\ORADATA\AAA\UNDOTBS01.DBF’ to ‘F:\ORADATA2\AAA\UNDOTBS01.DBF’;

database altered

SQL> alter database rename file ‘F:\ORADATA\AAA\SYSTEM01.DBF’ to ‘F:\ORADATA2\AAA\SYSTEM01.DBF’;

database altered

SQL> alter database open;

SQL> select file_id,file_name from dba_data_files;

FILE_ID FILE_NAME
———- ————————————————–
4 F:\ORADATA2\AAA\USERS01.DBF
3 F:\ORADATA2\AAA\SYSAUX01.DBF
2 F:\ORADATA2\AAA\UNDOTBS01.DBF
1 F:\ORADATA2\AAA\SYSTEM01.DBF

now,the datafile was relocated to the new path….

ps: if you want to change the path of temporary file, it’s the same process as datafile

日子过得实在太快了，让人无法接受，更没法接受的是自己稍显懒惰了。有些事情一拖再拖，实在有悖自己的风格。这不，紧接着，报应来了，作息不过规律，口腔溃疡，疼痛需自忍。另外一件事情，最近花钱有些多，需要控制控制，上学时候良好的习惯可不能丢掉呀。

不过，值得高兴的是，5.1看望了母亲，主要是让她宽心，毕竟跑出去大半个月，她有无限的联想，你只需站在她面前，一切就解释清楚了。陪她聊到很晚，不知不觉几个小时过去，一点点给她解释地理知识，历史知识，错误了，还需要及时纠正她。很难想象，犹如井底之蛙一般，她就像true man show里面的主人公一样，活着自己圈定好的世界里。但外界才不会管你那么多，没人会同情你。

我记得很早之前，周遭的一切，让我觉得：没人能帮你，只有靠自己。就像我的logo写的，”survival of the fittest”，适者生存。没有顽强的能力，没法生存。这一点，很难和母亲讲通，她还停留在”一切找组织”的想法以及自己给自己设计的n多假设和余地中。生活有时候好比战斗，你没有退路。我曾经一遍一遍的灌输给母亲，不管接受多少，还是需要继续潜移默化的影响，过程可以漫长，但一定需要坚持。

回想自己最近10年，15年。早期的无助和茫然，也给了我不少帮助。使我坚信，如果自己不够强悍、强硬，你不会赢得别人的尊重。最近想的事情比较多，好事，也是坏事，但每每都是洗澡的时候，说也奇怪。别那么多废话了，好好战斗吧，会很久。

好久没有写东西了，最近比较忙，先是从国外刚回来，很多收集的资料很宝贵，趁热打铁，将它们融合成报告，紧接着是出国期间堆积了很多工作需要处理，抽时间、加班逐一解决，不过这都是工作而已。简单聊聊欧洲之行给我的感受吧。
其实不管叫什么”资本主义”，还是”社会主义”，我都觉得过于狭隘，对于个人来讲，都是生活。不过，显然，老外的生活要比我们爽太多了，而且还是有很多值得我们学习的地方，从个人财产的尊重、规则的遵守，你说他死板也好，榆木脑袋也罢，到与生活相关的食品监管之严格。。。等等。在一个好的游戏规则之下，大家违规的成本很高，自然没有那么多乱七八糟的事情。有的时候看着蓝蓝的天空，你会想，”同一个世界，真是不同的梦想”，一味的强调”梦想的一致”倒是显得非常奇怪了。
看着那蓝天，看着所谓”雾都”的伦敦的蓝天，不禁想笑，这tmd空气比北京强了千百倍，真是冤枉伦敦了，或者。。。伦敦相比瑞士、德国可能空气算差的，但即使这样，相比北京的空气，要好太多了。不禁感叹，国内这些年的发展，是在牺牲环境的代价换来的，其实也没有什么好宣扬的，因为，这多少有点反自然了。在德国和伦敦的时候，抽空还去了两次超市，印象很深刻，超市基本生活品的价格已经快低于北京了，这点让我很震惊，原来国内的cpi确实涨得太凶了，北京的物价水平竟然已经赶上了伦敦，有些甚至超过。。我看看红酒的价格，笑了，基本在9镑左右，比北京便宜，什么奶粉、蔬菜等等基本如此，最夸张的是奶粉的价格竟然是国内的三分之一，而且容量比国内大。。。但所有最关键的是，食品安全不用操心，顿时觉得心灰意冷极了。。。想了好久。我们确实没有资格批评别人，先把这些基本的搞定，再来解释吧。比较讽刺，在国外吃了几次中餐，感觉不错，但价位竟然比国内便宜，让人难以接受的现实。。。再说说”素质论”，其实老外和国人的素质基本一样的，都是人，都有杂念，但不同的是，伦敦违规的成本要比过国内高，而且没有backdoor之说。其实，国人的素质要算是好的，你看看05年美国飓风，大兵带着冲锋进灾区，再想想08地震，我们的官兵是否端着ak进灾区呢？显然，素质论不成立。人非圣贤，前提定义人就是会犯各种错误的，而关键的是定义好规则，游戏规则，这是关键。有的时候，也能归结到一条：人口因素。确实国内人太多了，人一多，各种的问题立马显现。frankfurt，号称欧洲第二大航空港，整个城市只有60万人口，爱丁堡，苏格兰首都，尼玛只有40万人。。。。。而我们的天通苑，加上回龙观，基本可以秒杀他们了。所以，人口这么多，很多问题很容易就显现出来。不过尽管如此，我们仍应反思，还是由于很多管理、经营上的问题，没有解决大家的切实问题，这方面，没什么可逃避的，we are not good enough…

如何有效沟通是个问题，尤其和母亲之间，避免争执，谈一些她感兴趣的吧，否则大家都会进入死胡同，关键是这样对大家都不好。