没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Migrating from iSeries to SQL Server
Platform for J.D. Edwards
White Paper
Authors: Paul C. Shearer, Affiliated Computer Services
Chee Keong Wong, Affiliated Computer Services
Loh Yik Wai, Affiliated Computer Services
Technical Review: Scott Rosenbloom, Microsoft
Published: June 2007
For the latest information, please see www.microsoft.com/midrange
Migrating from iSeries to SQL Server Platform for J.D. Edwards Migrating 1
Contents
Abstract ......................................................................................................................................................... 2
Approach ....................................................................................................................................................... 4
Clean installation of EnterpriseOne .......................................................................................................... 4
The platform migration .............................................................................................................................. 4
I. Migrating the development environment ................................................................................................... 5
I.A. Development path code .................................................................................................................... 5
I.A.1. Migrate the central objects libraries ............................................................................................ 5
I.A.2. Migrate the versions tables ....................................................................................................... 10
I.A.3. Copy the development path code.............................................................................................. 12
I.A.4. Update the object librarian library.............................................................................................. 12
I.A.5. Import the ESU change tables .................................................................................................. 14
I.B. Data dictionary ................................................................................................................................ 15
I.C. EnterpriseOne user accounts and security tables .......................................................................... 16
I.D. OMW configuration ......................................................................................................................... 17
I.E. Full EnterpriseOne package ............................................................................................................ 18
I.F. EnterpriseOne business data and control tables............................................................................. 18
I.F.1. Prepare the development business data database ................................................................... 18
I.F.2. Migrate the control tables .......................................................................................................... 18
I.F.2. Migrate the business data ......................................................................................................... 19
II. Migrating the prototype environment ..................................................................................................... 21
II.A. Prototype path code ....................................................................................................................... 21
II.A.1. Migrate the central objects libraries.......................................................................................... 21
II.A.2. Migrate the versions tables ...................................................................................................... 24
II.A.3. Copy the prototype path code .................................................................................................. 25
II.A.4. Complete the path code migration ........................................................................................... 25
II.B. EnterpriseOne business data and control tables ........................................................................... 25
II.B.1. Prepare the prototype business data database ....................................................................... 25
II.B.2. Migrate the control tables ......................................................................................................... 25
II.B.3. Migrate the business data ........................................................................................................ 27
III. Migrating the production environment ................................................................................................... 30
III.A. Production path code .................................................................................................................... 30
III.A.1. Migrate the central objects libraries ........................................................................................ 30
III.A.2. Migrate the versions table ....................................................................................................... 33
III.A.3. Copy the path code ................................................................................................................. 34
III.A.4. Complete the path code migration .......................................................................................... 34
III.B. EnterpriseOne business data and control tables .......................................................................... 34
III.B.1. Prepare the production business data database..................................................................... 34
III.B.2. Migrate the control tables ........................................................................................................ 34
III.B.3. Migrate the business data ....................................................................................................... 36
Appendix A: Big tables in iSeries library .................................................................................................... 39
Migrating from iSeries to SQL Server Platform for J.D. Edwards Migrating 2
Abstract
J.D. Edwards EnterpriseOne is one of the most widely deployed enterprise resource planning (ERP)
applications in the midrange market today. It can run on multiple platforms, including the IBM System i
and Windows Server® 2003. As companies run out of capacity on their current System i hosts, reach
renewal dates for their maintenance agreements, or consider upgrades to their EnterpriseOne application
suite, many are deciding that Windows Server 2003 can provide a strong alternative to the status quo.
There are many reasons for companies to make the switch to Windows Server 2003 and Microsoft® SQL
Server™. A significant driver is cost. There are many areas where cost comes into play:
Purchase of new hardware to run EnterpriseOne. One recent customer was quoted $375,000
for a System i hardware and operating system combination to support its growing enterprise. The
hardware and operating system cost for the Windows Server solution was less than $180,000,
with clustered servers at both the application and database tiers to provide high reliability.
Requirement for additional batch capacity. Growing companies will reach the point of needing
more capacity. For example, the batch window may become insufficient. In such situations, it is a
simple matter to add additional commodity-priced servers to process the additional load, as
opposed to spending $80,000 to turn on a new processor on the System i—or worse, having to
purchase an additional system.
Granular scalability of the online workload. If the number of concurrent online users grows
due to the success of the company or through a merger or acquisition, the EnterpriseOne
application may become exposed to other user communities, which would require the company to
add capacity to its system. With the Windows Server platform, the company can simply add low-
cost servers to the cluster. With the System i, the costs are significantly higher: adding either
additional processors or an entirely new System i where expansion is not possible.
Disaster recovery. With a lower hardware cost it is possible to have a disaster recovery solution
that is fully utilized in production. Alternatively, a solution that is owned and controlled by the
organization can be set up in a passive configuration. Many System i customers cannot afford to
purchase dedicated disaster recovery systems, and therefore must lease from outside resources,
which are becoming less available and more expensive, and are unavailable to the organization
for any other purpose.
Low cost of ownership. From an administration standpoint, SQL Server is a very cost-effective
solution. SQL Server is a popular database management platform, so there are many qualified
database administrators (DBAs) in the market. These DBAs are very competitively priced as
compared to their System i counterparts. Therefore the cost of ownership of SQL Server
compared to System i can be substantially lower. Refer to www.microsoft.com/sql/prodinfo
/compare/ibm/db2v8.mspx for a detailed comparison of these costs.
Of course, cost is not everything. The power of the SQL Server back end provides significant advantages
over those of the System i back end.
ERP systems. In recent years, as regulatory and business requirements have continued to
demand more stringent performance and availability requirements, SQL Server has become an
increasingly attractive platform to migrate to, for customers who run ERP systems. With SQL
Server on a Windows Server 2003 operating system cluster, a customer can often implement a
highly available ERP solution for less than the cost of a single System i box.
This is accomplished by setting up the hardware on both nodes of the Windows Server cluster
in an active/active configuration. The database can run on one node of the cluster and the
application logic can run on the other node. This allows the resources of the cluster to be
fully utilized and yet still be protected in the event of hardware failure on either node.
Point-in-time data recovery. Another distinct advantage of SQL Server is its ability to do point-
in-time recovery of data. On the System i, to recover after your last backup you must enable
Migrating from iSeries to SQL Server Platform for J.D. Edwards Migrating 3
journaling on each table. Because journaling has performance considerations, many DBAs
disable this option. With SQL Server, databases operate in full recovery mode: in the event of a
logical error, such as a user inadvertently deleting or updating data, the DBA can easily recover
that deleted data via a point-in-time recovery, or even directly from the transaction log using third-
party tools. More details on the full recovery model for SQL Server can be found at
www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlbackuprest.mspx.
Business intelligence. SQL Server Analysis Services and Reporting Services are included with
SQL Server. Not only is this a significant cost savings for companies who opt for SQL Server, but
more importantly the company then gains access to the leading business intelligence (BI) solution
in the industry. Users can get a better view of their business in its entirety or a very specific view
based on their responsibilities.
High performance. SQL Server on x64 hardware can easily outpace a System i server. In
addition, it does so at a significantly lower price point. This is beneficial for the online experience
as well as for supporting larger volumes, which further improves the price/performance ratio.
To summarize, there are many reasons to consider moving your EnterpriseOne suite to Windows Server
2003 from the System i, including lower cost, improved functionality, better performance, and cost-
effective disaster recovery—all while maintaining the highly reliable environment that users expect.
Now that you are intrigued at the possibility of running EnterpriseOne on Windows Server 2003, there is
one other factor to consider: risk—the risk of migrating your existing application workload to Windows
Server. This paper shows you just how straightforward this migration is for development, prototype (test),
and production environments by detailing a sample migration.
Migrating from iSeries to SQL Server Platform for J.D. Edwards Migrating 4
Approach
The cleanest approach to migrating your existing EnterpriseOne installation from a System i environment
to your new Windows Server 2003 platform with SQL Server is to begin by performing a clean installation
of EnterpriseOne on Windows Server. After that installation is completed, you will overlay portions of your
system libraries, central objects, business data, and control tables on top of your existing SQL Server
databases.
On your SQL Server installation, you should have three separate environments: development, prototype,
and production. The migration process described in this white paper shows how to migrate each of these
environments as distinct phases. Note that the steps for each environment will differ somewhat, because
there are some processes that are performed only once, such as migrating the data dictionary, and other
processes that are performed as needed to ensure that all data transitions properly.
Clean installation of EnterpriseOne
To perform the clean installation of EnterpriseOne on Windows Server 2003, follow the general steps
outlined here:
1. Set up your cluster on Windows Server.
a. Create a SQL Server cluster group.
b. Create an EnterpriseOne cluster group.
2. Install SQL Server to the SQL Server cluster.
3. Install EnterpriseOne to your production server.
4. Run the EnterpriseOne installation workbench as described in Oracle’s EnterpriseOne installation
guide.
5. Install EnterpriseOne host code to the EnterpriseOne cluster.
6. Apply the same tools release to the new installation that you are running on your current
installation.
7. Verify that you can successfully submit batches to the cluster from your presentation layer.
The platform migration
Switch to your new SQL Server installation by migrating one environment at a time. For the typical
migration, this process involves three distinct phases, in the following order:
I. Migration of the development environment
II. Migration of the prototype environment
III. Migration of the production environment
Note: It is very important to ensure that code freeze is in place on all development activities, on both
current and new systems, prior to beginning the path code migration process. The process outlined in this
paper assumes that the path codes remain static. Otherwise, if new development occurs during this
migration process, you will be left with orphaned objects that you must manually locate and clean up at a
later time.
剩余45页未读,继续阅读
资源评论
Jeff9374602
- 粉丝: 0
- 资源: 25
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功