EBS升级成功案例【应用+数据库】

案例一:国华电力R12升级

国华电力

项目情况:

国华电力有限公司使用Oracle应用产品11.5.9系统. 客户主要使用财务,人力资源及商业智能系统, 原来的系统分布于IBM P570服务器上,操作系统为AIX.

当时,国华电力准备实施新的物流模块,同时新增业务点. 基于此楔机, ORACLE提供现场服务,帮助客户评估现有的系统构架,审核现有系统的稳定性、数据安全性及维护性。

ORACLE通过检查系统并充分调研,发现现有系统在处理能力、维护性、数据安全及功能方面已不能完全满足国华现在及将要实施新模块的业务需求。因此建议国华升级ERP系统至新版本R12,同时实施多节点策略,以增强系统高可用性及稳定性;同时,为了提高可维护性及降低成本,采用多台LINUX服务器组成的集群来升级现有的系统。

 

国华电力是Oracle R12推出后,在亚太地区第一个从11i升级到R12的客户。曾经有一家替国华电力做ERP运维的实施商在测试环境中做R12升级,但是由于碰到太多问题无法及时解决导致升级失败,Oracle OSS部门接到此案例后和Oracle技术支持团队紧密配合,在规定项目时间内顺利完成升级目标。

 

升级周期:

2007.2 ~ 2007.8

 

升级后情况:

EBS升级到R12, 数据库升级到10gR2, 数据库配置RAC,应用配置PCP。

 

QQ截图20160105171118

 

案例二:内蒙古北方重型汽车R12升级

内蒙古北方重型汽车R12升级

项目情况:

北方重汽EBS系统2001年上线至今已将近9年时间,实施模块包括:财务、制造、分销、库存管理等,其应用版本11.5.6, 数据库版本8.1.7已经大大超出了Oracle技术支持期限,考虑到北重目前业务的迅速发展,EBS系统持续、稳定的发展,北重决定将当前EBS系统升级到Oracle EBS R12.1版本.

实施周期:

2009.9 ~ 2010.2

升级后情况:

EBS升级到R12.1, 数据库升级到11gR2, 数据库单节点,应用也是单节点。

QQ截图20160105171223

 

 

案例三:华为ERP R12升级

项目情况:

华为的ERP系统使用了将近10年的时间,数据量将近3T的,应用是11.5.9版本,为了保持企业的核心竞争力,华为的ERP系统进行了升级。

实施周期:

2010.3 ~ 2010.12

升级后情况:

EBS升级到R12.1, 数据库升级到11gR2, 数据库RAC架构,应用也是PCP价格。

 

QQ截图20160105171253

 

案例四:新飞电器R12升级

项目情况:

新飞电器EBS系统至1997年上线至今已有进13年时间,现在由于企业业务的发展,使用用户数的增加,系统压力的增大,Oracle EBS产品支持期限到期等原因,新飞EBS运维团队正在寻求有效的方案以保障EBS系统持续、稳定、有效运行。

实施周期:

2010.10 ~ 2011.3

升级后情况:

EBS升级到R12.1, 数据库升级到11gR2, 数据库单节点,应用也是单节点。

 

案例五:TCL R12升级

项目情况:

TCL的ERP系统使用了将近10年的时间,数据量将近0.5T的,应用是11.5.7。

实施周期:

2010.6 ~ 2010.10

升级后情况:

EBS升级到R12.1, 数据库升级到11gR2, 数据库单节点,应用也是单节点。

 

案例六:航天信息R12升级

项目情况:

航天信息股份公司ERP从2003年开始,经历了四个阶段的建设,截止至2011年年初,已在总部、金卡公司、系统工程部、系统工程公司以及涿州公司共5家分子公司实施,实现了财务、分销、制造和项目管理,主要包括ORACLE EBS 11.5.9版本的总账、应收、应付、资产、网上报销、采购、库存、销售、项目管理、项目会计、制造等模块。

实施周期:

2010.10 ~ 2011.2

升级后情况:

EBS升级到R12.1, 数据库从9203升级到11gR2, 数据库单节点,应用也是单节点。

 

案例七:华三技术有限公司(H3C)R12升级

项目目标

1、为ERP系统提供持续的支持能力,支撑未来5年的业务运作;

2、改善ERP应用性能;

3、提高应用可维护性和扩展性;

4、降低服务器和运维成本。

项目范围

1、ERP硬件平台由IBM P590迁移至HP DL980(数据库)2台+ HPDL585(应用)2台,操作系统由AIX5.3换成Oracle Enterprise Linux 5.7

2、ERP应用由11.5.10升级至12.1.3

3、ERP数据库由10.2.0.4升级至11.2.0.2

从最底层到最上层全部做转换升级

实施周期:

2012.6 ~ 2013.2

升级后情况:

完全达到项目目标

 

案例八:伊利R12升级POC

项目目标

  • 验证伊利EBS R12升级的可行性
  • 验证宕机时间是否达到业务部门要求

 

项目范围

  • 应用升级到x
  • 数据库由10gR2升级到11gR2,并配置RAC
  • 测试完成后主要的标准核心业务功能能够正常使用,不考虑客户化程序
  • 对收集的时间做分析评估,看是否能满足伊利升级停机时间的要求,如果可以,给出切实可行的实施方案

实施周期:

2012.10 ~ 2012.12

升级后情况:

完全达到客户期望,为日后正式立项升级提供了数据支撑。

 

其它案例情况:

  • 长安汽车EBS系统和EBS HR系统的数据库的数据库升级并配置RAC

数据从9207升级到11gR2,配置RAC,数据量8T

 

  • 潍柴动力EBS系统的数据库升级+RAC

数据库从9204升级到11gR2,并配置RAC,数据量4T

 

  • 华夏银行EBS系统的数据库升级+RAC

数据库从9206升级到11gR2,并配置RAC,数据量1T

 

  • 阿里巴巴EBS平台迁移+数据库升级+RAC

AIX迁移到Linux,并配置10gR2的RAC

 

  • 九阳豆浆EBS系统的数据库升级+RAC

应用从12.0.3升级懂啊12.0.4,数据库从10gR2升级到11gR2,配置RAC

 

 

【Oracle EBS】Cocurrent Manager HANG system hold fix manager before resetting counters

Oracle Applications Manager > Concurrent Managers OR Concurrent Requests > Site Map > Diagnostics and Repair > Concurrent Manager Recovery

介绍了 Concurrent Manager Recovery ,路径如上 尝试使用该功能

否则

locate adstpall.sh
locate adstrtal.sh

adstpall.sh ==》关闭所有EBS

adstrtal.sh ==> 启动所有EBS

shutdown immediate;
startup; ==> 重启数据库

cmclean.sql ==》 使用apps 用户执行

==》 如果还不行, 建议他开一个SR,就说可能是bug 。

  Concurrent Processing - CMCLEAN.SQL - Non Destructive Script to Clean Concurrent Manager Tables (Doc ID 134007.1)
      Manager Status Shows System Hold, Fix Manager before resetting counters (Doc ID 1507580.1)    To BottomTo Bottom    
Modified:22-Nov-2012Type:PROBLEM    
Rate this document    Email link to this document    Open document in new window    Printable Page
In this Document
    Symptoms
    Changes
    Cause
    Solution
    References
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.
Applies to:
Oracle Concurrent Processing - Version 12.1.3 and later
Information in this document applies to any platform.
Symptoms
The Administer Concurrent Managers screen shows the Scheduler/Prereleaser Manager with a status / state of "System Hold, Fix Manager before resetting counters"
Changes
 This issue started after bouncing all servers.
Cause
An orderly shutdown of the concurrent manager was not performed. The CP Diagnostic Request Analyzer" shows that a CP Shutdown was initiated at on 16-OCT-12 at 22:22:41 and then cancelled.
Yet, the database alert log file shows that the database was shutdown within four seconds of the concurrent managers being shutdown/cancelled, not providing enough time to perform an orderly shutdown of the concurrent processing server.
Solution
1. Shutdown the Concurrent Processing (CP) server in an orderly manner and verify that the shutdown is complete before invoking a shutdown of the database and/or the database listener. Check the last CP process to exit/terminate, the Internal Manager, with the Unix command: ps -ef | grep FNDLIBR
If a manual shutdown is being performed, use the same sequence found in the adstpall.sh – "Stop All Oracle E-Business Suite Enabled Services" script: first the CP Server--once down--shutdown the App Listener, the Forms Server, the Web (Apache) Server. Lastly, if necessary, shut down the database listener and/or database.
Note 1: The start up is the same, but in reverse order. In this case, a complete bounce of all servers (apps/db tier) restored a normal manager status/state.
2. In the event that the CP server was not shutdown properly, run cmclean.sql as per Doc ID Note 134007.1. In some cases, it may be necessary to bounce the database.
Note 2:  Shutting down the database or the listeners without an orderly shutdown of the Concurrent Processing server is the equivalent of pulling the power cord on a Unix box. 999 times out of 1000, the Unix system will recover without any incident; however, at some point file/disk corruption or an odd state will occur; similarly, the same applies to the CP server, manager queue and process state information may not be current or correct.
Note 3:  The cmclean.sql script is a safe script created by CP Development. It is a helpful script for re-initializing the managers, particularly when a manager's normal operation may have been compromised by manual intervention by a DBA or System Administrator (by manual killing of OS / RDBMS processes) or due to unplanned system outages (an accidental closing of the database without doing an orderly shutdown of the concurrent managers, power / network outages, etc).
References
NOTE:134007.1 - Concurrent Processing - CMCLEAN.SQL - Non Destructive Script to Clean Concurrent Manager Tables
Concurrent Processing - CMCLEAN.SQL - Non Destructive Script to Clean Concurrent Manager Tables (Doc ID 134007.1)    To BottomTo Bottom    
Modified:23-Oct-2013Type:SCRIPT    
Language:    
    Rate this document    Email link to this document    Open document in new window    Printable Page
Applies to:
Oracle Concurrent Processing - Version 11.5.10.0 to 12.2 [Release 11.5 to 12.2]
Information in this document applies to any platform.
Checked for relevance on 13-APR-2013
Applications Install 10.7 to 12.1.3
Purpose
This document provides a reference to self service Cleaning the Concurrent Manager tables
Non Destructive Script to Clean Concurrent Manager Tables
NOTE:
This script works with 10.7, 11.0, 11.5 & 12.1.3 Applications.
Information Center, Diagnostics, & Community
    E-Business Concurrent Processing Information Center Document 1304305.1
    Please reference this document regularly to review current offerings for Concurrent Processing needs.
    Diagnostics
    For additional help, please refer to one of the following documents on diagnostics to address current needs. Providing diagnostic output on an issue for support when logging a service request is very helpful.
    Document 179661.1 for 11i or Document 421245.1 for Rel 12.x
    Core Concurrent Processing Community
    Visit the Core Concurrent Processing community for help from industry experts or to share knowledge.
Requirements
SQLplus
Configuring
Copy from the first REM statement to the last REM statement of this document and save as: cmclean.sql.
NOTE:
Ensure that No FNDLIBR processes are running as detailed within the Troubleshooting Note 104541.1 and that the Concurrent Manager is down.
Issue a commit once the script is run for the changes to take effect.
Instructions
Please run the Concurrent Manager Recovery feature to address any Concurrent Manager / Concurrent Processing issues within the Oracle Application Manager.
Using the Concurrent Manager Recovery wizard is the method to clear the errors upon bringing the internal manager back up.
The cmclean script can still be used for Application instances provided the managers are down and no FNDLIBR processes are still running.
For Concurrent Internal Manager failures, it is recommended to run the Concurrent Manager Recovery feature using the Oracle Applications Manager. This feature should be used for recovering from when the Internal Manager won't start. This is accessed from the Troubleshooting wizards available within applications logged in as the sysadmin userid.
Navigate:
Oracle Applications Manager > Concurrent Managers OR Concurrent Requests > Site Map > Diagnostics and Repair > Concurrent Manager Recovery
For information on the Concurrent Manager Recovery feature, please reference the Oracle Applications System Administrator's Guide - Maintenance provides information for frequent tasks such as monitoring your system with Oracle Applications Manager, administering Oracle E-Business Suite Secure Enterprise.  Search, managing concurrent managers and reports, using diagnostic utilities including logging, managing profile options, and using alerts.
To run cmclean.sql:
Usage: sqlplus @cmclean
Caution
This sample code is provided for educational purposes only, and is not supported by Oracle Support. It has been tested internally, however, we do not guarantee that it will work for you. Ensure that you run it in your test environment before using.
Script
REM
REM FILENAME
REM cmclean.sql
REM DESCRIPTION
REM Clean out the concurrent manager tables
REM NOTES
REM Usage: sqlplus @cmclean
REM
REM
REM $Id: cmclean.sql,v 1.4 2001/04/07 15:55:07 pferguso Exp $
REM
REM
REM +======================================================================+
set verify off;
set head off;
set timing off
set pagesize 1000
column manager format a20 heading 'Manager short name'
column pid heading 'Process id'
column pscode format a12 heading 'Status code'
column ccode format a12 heading 'Control code'
column request heading 'Request ID'
column pcode format a6 heading 'Phase'
column scode format a6 heading 'Status'
WHENEVER SQLERROR EXIT ROLLBACK;
DOCUMENT
WARNING : Do not run this script without explicit instructions
from Oracle Support
*** Make sure that the managers are shut down ***
*** before running this script ***
*** If the concurrent managers are NOT shut down, ***
*** exit this script now !! ***
#
accept answer prompt 'If you wish to continue type the word ''dual'': '
set feed off
select null from &answer;
set feed on
REM Update process status codes to TERMINATED
prompt
prompt ------------------------------------------------------------------------
prompt -- Updating invalid process status codes in FND_CONCURRENT_PROCESSES
set feedback off
set head on
break on manager
SELECT concurrent_queue_name manager,
concurrent_process_id pid,
process_status_code pscode
FROM fnd_concurrent_queues fcq, fnd_concurrent_processes fcp
WHERE process_status_code not in ('K', 'S')
AND fcq.concurrent_queue_id = fcp.concurrent_queue_id
AND fcq.application_id = fcp.queue_application_id;
set head off
set feedback on
UPDATE fnd_concurrent_processes
SET process_status_code = 'K'
WHERE process_status_code not in ('K', 'S');
REM Set all managers to 0 processes
prompt
prompt ------------------------------------------------------------------------
prompt -- Updating running processes in FND_CONCURRENT_QUEUES
prompt -- Setting running_processes = 0 and max_processes = 0 for all managers
UPDATE fnd_concurrent_queues
SET running_processes = 0, max_processes = 0;
REM Reset control codes
prompt
prompt ------------------------------------------------------------------------
prompt -- Updating invalid control_codes in FND_CONCURRENT_QUEUES
set feedback off
set head on
SELECT concurrent_queue_name manager,
control_code ccode
FROM fnd_concurrent_queues
WHERE control_code not in ('E', 'R', 'X')
AND control_code IS NOT NULL;
set feedback on
set head off
UPDATE fnd_concurrent_queues
SET control_code = NULL
WHERE control_code not in ('E', 'R', 'X')
AND control_code IS NOT NULL;
REM Also null out target_node for all managers
UPDATE fnd_concurrent_queues
SET target_node = null;
REM Set all 'Terminating' requests to Completed/Error
REM Also set Running requests to completed, since the managers are down
prompt
prompt ------------------------------------------------------------------------
prompt -- Updating any Running or Terminating requests to Completed/Error canceled by CMCLEAN
set feedback off
set head on
SELECT request_id request,
phase_code pcode,
status_code scode
FROM fnd_concurrent_requests
WHERE status_code = 'T' OR phase_code = 'R'
ORDER BY request_id;
set feedback on
set head off
UPDATE fnd_concurrent_requests
SET phase_code = 'C', status_code = 'E'
WHERE status_code ='T' OR phase_code = 'R';
REM Set all Runalone flags to 'N'
REM This has to be done differently for Release 10
prompt
prompt ------------------------------------------------------------------------
prompt -- Updating any Runalone flags to 'N'
prompt
set serveroutput on
set feedback off
declare
c pls_integer := dbms_sql.open_cursor;
upd_rows pls_integer;
vers varchar2(50);
tbl varchar2(50);
col varchar2(50);
statement varchar2(255);
begin
select substr(release_name, 1, 2)
into vers
from fnd_product_groups;
if vers >= 11 then
tbl := 'fnd_conflicts_domain';
col := 'runalone_flag';
else
tbl := 'fnd_concurrent_conflict_sets';
col := 'run_alone_flag';
end if;
statement := 'update ' || tbl || ' set ' || col || '=''N'' where ' || col || ' = ''Y''';
dbms_sql.parse(c, statement, dbms_sql.native);
upd_rows := dbms_sql.execute(c);
dbms_sql.close_cursor(c);
dbms_output.put_line('Updated ' || upd_rows || ' rows of ' || col || ' in ' || tbl || ' to ''N''');
end;
/
prompt
prompt ------------------------------------------------------------------------
prompt Updates complete.
prompt Type commit now to commit these updates, or rollback to cancel.
prompt ------------------------------------------------------------------------
prompt
set feedback on
REM <= Last REM statment -----------------------------------------------------

SEC0000007-Unable to locate security server?

下午接了个活,销售给我出难题:客户的JD EDWARDS Oneworld fat client登录不上,报SEC0000007-Unable to locate security server错误;客户的这个JDE版本是7333(估计是仁科在被Oracle收购前出的版本),搜了下metalink结果只找到8.93版本相关的Note。我和销售说这玩样跟我不是一个系的出身,销售让我调动资源尝试下,那我就调动下。以下是目前找到的资料:

1.metalink与之相关的bug note介绍可能因为服务程序down掉造成该问题:
OW Version: B9
SP: SP_F
WEB: qaweb2:86
Problem:
If the enterprise server is down and the user tries to
login with his/her correct user id and password, the
following error is displayed.
............
Incorrect user id and password
............
For the fat client, the following error is displayed.
---------------------------
OneWorld Error
---------------------------
SEC0000007 - Unable to locate security server
---------------------------
Retry Cancel
---------------------------
If I select "Cancel", then
---------------------------
Error
---------------------------
SEC0000001 - Failure in communicating with Security Server
---------------------------
OK
---------------------------
If I click "OK", then
---------------------------
Error: User ID - Password
---------------------------
OneWorld could not sign you on. Make sure your User
ID
is
correct and retype your Password.
---------------------------
OK
---------------------------
............
Since this error message is not appropriate, please change
it to some appropriate phrase, for instance, "Security
server is down, please re-try later".
QE: sr4890282
============================================================
This SAR has been fixed, but changes was overwritten
by
Bhale, Bhushan on 4/30/02
Fix Information
System Code:	H93F-Enterprise Foundation
Object: 	B9 JDBJ
Code Change/ESU: 	None
Date Completed: 	03-Jul-2002
Target Delivery Information: 	30-Apr-2002
Product: 	4781 - JD Edwards EnterpriseOne Tools
Members Affected: 	
$PFinternetsrccomjdedwardsjas 			
JDESignon.java 			
Rights given 5/23/02 mkl 			
Data Dictionary:	
User Defined Code: 	
Final Disposition: 	Modify JDESignon.java, when the security server is down,
set the errorID to 5( security server cannot be reached)
instead of 331 (bad password and userID)                    
2.网上对该SEC0000007错误的评论认为引发该错误的有多种可能性:
You will get this message for a number of reasons. Check the user profile 
OneWorld and make sure it's enabled. Also check the user id that you have 
attached to users...
Also, you may need to bounce your services.
Another reason is that when logging on the ini usually uses PD7333 as your 
main pathcode for security. Make sure this pathcode is not damaged & is 
usable. Check the spec folder...
I have had all of the above problems at different times... Hope this helps,
3.就目前来看如果重启服务解决不了问题的话,就麻烦了。。

谁有JDE方面的经验能帮个忙,我请他吃饭!

沪ICP备14014813号

沪公网安备 31010802001379号