Split Database for EnterpriseOne 8.0

DavidHuang

DavidHuang

Active Member
Hi all,

Due to performance issue, we plan to split current database into 2 different
instances for 2 different company, further will live in two different
database server independently. We have GL, AR, AP, Job Cost, MRP, SFC,
PC&MA,, Sales Configurator, Procurement, Sales Order Management, etc.

I didn't heard any company do this before. Does anyone have such kind of
experience?

Especially any special experience / advice on:

*how to purge the data not related to the company after split. (now the data
of these 2 company reside in the same tables and we plan to copy data from
current database/environment to another new database/environment, and then
purge for each database)?
*any integrity issue?
*any thing will be easily omitted in the database split/purge process?
...
...

Any comment is welcome.

Thanks & Regards,
David Huang

OneWorld 8.0 SP23
SQL Server 2000
 
Just my thoughts, but it seems like you're trying to kill a "performance fly" with a 10 Megaton Hyrdogen bomb instead of a flyswatter. There are many things that come to mind that I'd look into prior to physically splitting a system into two...

1. SQL server optimization - Identify "performance issues" and see if they could be data, index, or SQL setup related. Were the SQL disk arrays configured properly, can you take certain tables and put them in their own space, how often are TL backups done. Things like that.
2. E1 security. Are you using a lot of row and/or column level security. Can it be changed to improve performance.
3. Batch processing. Are the queues well designed and workload spread accordingly, are the servers properly up to speed.

In answer to your question, though, sure, it can be done. But I bet if effort was put into identifying the performance issues, money and time would be better spent to fix the performance, rather than to separate the system.

But, what do I know? Until yesterday, I would have never thought a company would ever consider going from E1 to World, THEN to SAP the following year.
 
Back
Top