回归江南旧梦
11g 创建数据库失败 ORA-03113: end-of-file on communication channel
andzen 发表于 2012-01-13 22:23:03
Errors in file /opt/oracle/diag/rdbms/amw/amw/trace/mman_3124.trc
ORA-27103: internal error
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: -1
Additional information: 1
MMAN (ospid: 3124): terminating the instance due to error 27103
Instance terminated by MMAN, pid = 3124
oerr 查一下 27103 ，等于白查
Cause: internal error
Action: contact Oracle support
Please add more information about this Error
再mman trace文件里：
Redo thread mounted by this instance: 0 <none>
Oracle process number: 8
Unix process pid:3124, image: oracle@linux58 (MMAN)
*** 2007-07-30 07:40:43.629
*** SESSION ID:(658.1) 2007-07-30 07:40:43.629
*** CLIENT ID:() 2007-07-30 07:40:43.629
*** SERVICE NAME:() 2007-07-30 07:40:43.629
*** MODULE NAME:() 2007-07-30 07:40:43.629
*** ACTION NAME:() 2007-07-30 07:40:43.629
error 27103 detected in background process
ORA-27103: internal error
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: -1
Additional information: 1
把上面的部分到oracle网站一查，果然第一页就是老大一个标题
ORA-27103 when Memory target parameter is set to more than 3 GB
Applies to:
Oracle Server - Enterprise Edition - Version: 11.1.0.7 to 11.1.0.7 - Release: 11.1 to 11.1
Linux x86-64
Changes
Applied the 11.1.0.7 patch set.
OR
ORA-27103: internal error
Linux-x86_64 Error: 25: Inappropriate ioctl for device
Additional information: -1
Additional information: 1
MMAN (ospid: 12249): terminating the instance due to error 27103
Instance terminated by MMAN, pid = 12249
OR
DBCA fails with ORA-03114 error
This issue is not reproduced in 11.1.0.6
Cause
=========
The problem is due to Bug:7272646, introduced in 11.1.0.7 patchset on 64bit Linux.
In some cases, after applying the 11.1.0.7 patch set on 64Bit Linux x86 the instance will not start when MEMORY_TARGET > 3GB.
Solution
==========
This bug is fixed in 11.1.0.8 patchset when released.
An interim Patch:7272646 is available on metalink for Linux x86-64 11.1.0.7.
After applying the patch, test with memory_target set > 3GB to verify patch resolves issue.
To workaround the issue:
1. Reduce value for kernel parameter SHMMAX below 4Gb (4294967296). This will cause more shared memory segments to be created for the instance SGA. There is no impact to setting SHMMAX lower.
把这个bug7272646相关的的interim patch 下载下来
看README.txt
unzip
opatch ....
等待关键的时刻到来，重新在刚才出错的DBCA上面点击“完成”（10g之后的版本很人性化，dbca出错了可以重试，记得9i时候错了窗口就关了，要重新一步一步设置），
进度条一点一点增加，20秒还没报错，显示进度19%，
超过每次出错的11%，
OK，搞定收工。
收藏:
QQ书签
del.icio.us
小心毒鱼，郭成林被抓案件，神州当代版指鹿为马？
andzen 发表于 2011-10-20 23:57:47
郭成林先生，在网络发表一篇文章，原版如下：
金龙鱼，一条祸国殃民的鱼！
看了下面的文字，如果说金龙鱼罪孽深重，一点都没有轻判！
金龙鱼打出来1：1：1的健康概念，蒙骗了13亿中国人，在中国取得了400多亿的销量，几乎垄断了中国食用油市场，这个外资品牌的产品实质是什么呢？是他宣传的健康概念吗？还是最近宣传的深海鱼油食用 油，不得不佩服，金龙鱼肮脏的产品居然能策划出一个个经典的概念 ！
首先，金龙鱼靠什么成功，就是靠一条全球转基因大豆产业链！金龙鱼在南美等地拥有转基因大豆和菜籽油种植基地，并通过国际期货交易赚钱，然后把这些转基因食品运到中国加工成油饼，卖给中国的饲料企业，赚完这两个环节的钱，剩下的副产品——转基因大豆油和转基因菜籽油倾销到中国的千万家超市。 然而，中国的消费者从来不看金龙鱼食用油的配料表！转基因农产品在欧洲和日本是绝对禁止人民食用的，因为对我们的儿孙身体有不可预测的风险！吃转基因食品的害处，只能在儿孙身体上才能实现！ 驴和马交配生产来的是骡子，而骡子丧失了生育能力，你琢磨一下转基因食品的害处有多大吧！
第二、金龙鱼的转基因食品成本极低，在中国的倾销彻底摧毁了中国农业的大豆产业链，东北原来的非转基因大豆基本上被摧毁了，现在的黑土地基本上全部沦陷，都种上了转基因大豆！我们每天喝的豆浆基本上都是转基因大豆制成的！
第三、金龙鱼大豆油是化学浸出法！这种工艺的优点是出油率高，企业能降低成本，缺点是产生两种物质：铅汞残留和反式脂肪酸！这两种物质是强烈致癌物质，不次于金浩茶油！！！而金龙鱼调和油70%的基油都是转基因化学浸出油，然而消费者从来不看配料表，被金龙鱼的花俏概念蒙在鼓里，包括金龙鱼的新品种“深海鱼油调和油” ，实质上仍然是“化学浸出非转基因大豆油”为主体成分！ 金龙鱼，卑鄙的大品牌，祸国殃民啊，中国的汉奸们在祸害国家和人民，戕害着国人的身体，摧毁着中国的大豆产业链！ 这就是这个外资品牌的卑劣！！你还买金龙鱼调和油吗？你还敢吃吗？吃了它使你不能生育后代，它能让我们的后代断子绝孙的！
1. 金龙鱼食用转基因原料做成食用油，事实清楚，无需证明。
2.其油化学浸出，也标示于包装之上，亦非诽谤。
郭成林牢狱之灾，乃阶级之利益之争，非道理之争，死生之斗，非理，乃武力也！ 我等皆等北方京师之大元定论，草民之策，顾自家之命，慎买毒鱼，颐养天年，岂能以卵与石击。 吾等青天重归之时，毒鱼束手。
文斯公言：昔有赵高庙堂之高，指鹿为马，今乾坤朗朗，郭生有屈难伸。判定此事不难，上有党国明律，只因下无明断之包拯。天下熙熙，皆为利来。 商不明商，官不明案，官商一体，鱼龙混杂。
半年前，乃有云南一案，作奸者，奸后杀一女，又倒摔一三岁幼童致其亡命，一人至二人迅疾殒命之案，然云南之法院，仅赐两年死缓，谓之少杀甚杀，其院长高呼曰：“此案必成十年之后之标杆！”，一时举国民怨遂起，至京师之都察院，钦令重审，三审作奸者终判极刑，立诛之。
欧阳修曰: 廉耻，立人之大节；盖不廉则无所不取，不耻则无所不为。人而如此，则祸败乱亡，亦无所不至；况为大臣而无所不取，无所不为，则天下其有不乱，国家其有不亡者乎？
今文斯曰:廉耻，立人之大节；盖不廉则无所不取，不耻则无所不为。无耻,专家亦不可免, 何其愚也! 悲哉,国将祸亦,法将不法!
收藏:
QQ书签
del.icio.us
如何快捷省时的使用logmnr
andzen 发表于 2011-09-29 23:31:56
今日一局方急电系统不能用了，开发人员检查说一个表数据一条都没有了。汗，如此低级的问题又出现了，敌特在破坏？
匆匆赶到维护部，还好是个静态表，变化少，
抱着侥幸的态度，数据库是10.2，尝试一下flashback table t_cat_resource to timestamp ...; 靠报没有启用flashback ，MD，不知道那个家伙配的。没有启动闪回。
只好先rename成别的名字，然后impdp导入单个表，3分钟就搞定，恢复了6万多条数据。然后把索引和主键建立，刚刚没有删除，所以impdp索引必然失败。
然后继续查谁把数据搞没了。又是得罪人的活。
看看配置，审计没有开。
只得 logmnr了。查看了一下发生时间内有四个日志存在相关记录的可能。
12 +DATA/orcl/onlinelog/group_12.283.752347173
14 +DATA/orcl/onlinelog/group_14.285.752061399
16 +DATA/orcl/onlinelog/group_16.287.752061431
1 +DATA/orcl/onlinelog/group_1.280.752347157
于是开始用老一套了：
create table t_tmp_logmin AS
select timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents where rownum <1 ;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_12.283.752347173');
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.addfile, logfilename=>'+DATA/orcl/onlinelog/group_14.285.752061399');
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.addfile, logfilename=>'+DATA/orcl/onlinelog/group_16.287.752061431');
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.addfile, logfilename=>'+DATA/orcl/onlinelog/group_1.280.752347157');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
发现在上面紫色一行停住不动了很久 ，无奈结束，是啊 这个表一行记录就超大，弄个几百行数据就几个G。
只得换了一种工作方法，化整为零。
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_12.283.752347173');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_14.285.752061399');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT * from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_16.287.752061431');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_1.280.752347157');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
这样感觉快了不少 2-4分钟基本上搞完了。OK， 收队。
匆匆赶到维护部，还好是个静态表，变化少，
抱着侥幸的态度，数据库是10.2，尝试一下flashback table t_cat_resource to timestamp ...; 靠报没有启用flashback ，MD，不知道那个家伙配的。没有启动闪回。
只好先rename成别的名字，然后impdp导入单个表，3分钟就搞定，恢复了6万多条数据。然后把索引和主键建立，刚刚没有删除，所以impdp索引必然失败。
然后继续查谁把数据搞没了。又是得罪人的活。
看看配置，审计没有开。
只得 logmnr了。查看了一下发生时间内有四个日志存在相关记录的可能。
12 +DATA/orcl/onlinelog/group_12.283.752347173
14 +DATA/orcl/onlinelog/group_14.285.752061399
16 +DATA/orcl/onlinelog/group_16.287.752061431
1 +DATA/orcl/onlinelog/group_1.280.752347157
于是开始用老一套了：
create table t_tmp_logmin AS
select timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents where rownum <1 ;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_12.283.752347173');
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.addfile, logfilename=>'+DATA/orcl/onlinelog/group_14.285.752061399');
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.addfile, logfilename=>'+DATA/orcl/onlinelog/group_16.287.752061431');
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.addfile, logfilename=>'+DATA/orcl/onlinelog/group_1.280.752347157');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
发现在上面紫色一行停住不动了很久 ，无奈结束，是啊 这个表一行记录就超大，弄个几百行数据就几个G。
只得换了一种工作方法，化整为零。
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_12.283.752347173');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_14.285.752061399');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT * from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_16.287.752061431');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
EXEC dbms_logmnr.add_logfile( options=>dbms_logmnr.new, logfilename=>'+DATA/orcl/onlinelog/group_1.280.752347157');
exec dbms_logmnr.start_logmnr(options=>dbms_logmnr.dict_from_online_catalog);
INSERT INTO t_tmp_logmin SELECT timestamp,scn,operation,sql_redo,sql_undo,seg_name,owner from v$logmnr_contents WHERE seg_name=UPPER('t_cat_resource') ;
exec dbms_logmnr.end_logmnr;
COMMIT;
这样感觉快了不少 2-4分钟基本上搞完了。OK， 收队。
收藏:
QQ书签
del.icio.us