Question Migration v9.1E to OpenEdge 11.2 (32bit)

[PMiddleton]

Old Server/Client: Windows 2003 - 32bit - 9.1d - Windows XP(yes...XP) Client Server 9.1e
New Server(s)/Client:Virtual Server running 64bit Windows Server 2008 and 32 bit Windows Client/Server (Windows Clients)

I have started putting stuff together to perform the migration - unfortunately, my client has not found it necessary until now to pay for an upgrade/maintenance to OpenEdge/Progress for almost 10 years. Their application works/runs fine on the current hardware however, they've experienced a lot of growth lately and really want to move to the next level.

I see white papers for converting 9 to 10 out there on the kbase but I don't know that I have everything I need to make the moves I need.

Do I need to install OpenEdge on the old server to perform the conv910/conv1011 dbutils because they are not available in the current version on the old server?

If I did a dump and load to a new empty OpenEdge 11.2 db - do I still need the conv910/conv1011?

I found a document that says the following to perform a migration but I do not want to mess anything up.

Shutdown db
Truncate bi
Move to new server? Not sure if this step answers my question about the install of OpenEdge - also, what is the best way to move a db to the new server?
/usr/dlc/bin/102dbutils/102b05_dbutil dbname -C conv910
proutil dbname -C conv1011
proutil dbname -C truncate bi
start db on new server
Mv /usr/dlc/tty/adeedit /usr/dlc/tty/adeedit.sav
Prep binary D/L scripts
Dump .df
Dump sequence defs
Dump sequence vals
Dump _user table
Shutdown db on new server
Dump data
Mv db files to dbname2 dir


Procopy /usr/dlc/empty8 /u/dbname/dbname (This looks like linux or unix?)
Proutil dbname –c truncate bi
Proutil dbname –C EnableLargeFiles
Startdbname
Load data

I know that this is a short list of action items - I just want to know if this seems accurate? Perhaps someone out there has a better document to help me make the right decisions the first time. I think this was created for a unix/linux scenario - perhaps there is a Windows version?

Thanks for looking/helping,

Patrick Middleton

 

[TomBascom]

That stuff is for UNIX. But most of the basic steps apply just as well to Windows.

Here it is for Windows and reflecting your desire to go from v9 to OE11:

1. Install OE11 on the target system. Make sure that you ordered 64 bit Progress binaries for the DB components.
2. Dump the .df file from the v9 system, copy it to the new system.
3. Build an empty target database. Take a look at http://dbappraise.com/ppt/sos.pptx for ideas on the structure file and assignments of objects to storage areas. Whatever you do, do NOT allow everything to go into the schema area! Modify the .df file or load it and then use "proutil tablemove" to reassign things. If the database has LOBs (unlikely with a v9 schema) you must manually edit the .df file to get them out of the schema area and into a dedicated LOB area.
4. Enable large files on the target database. Set the bi cluster size to something reasonable (if this is an "Enterprise" license that means 16384 or larger) and do any other configuration tuning that makes sense.
5. Kick all users off the v9 system and make sure nobody is updating anything.
6. Backup the v9 system -- use the online backup to avoid shutting down (you want to stay up so that the cache stays "hot".
7. Start binary dumping your tables. If the db is small and doesn't have too many tables this is simple enough to do manually. If there are lots of tables you may want to script it.
8. Transfer the .bd files to the new server and load them. You can do this as each one completes. No need to wait for all of them.
9. Rebuild the indexes -- see Rich Banville's PUG Challenge talk: http://pugchallenge.org/2012PPT/NEPUG_Performance.pptx
10. Recompile and perform any application specific steps.

 

[cj_brandt]

I like to run a table analysis on the old server and then again on the new server to make sure my table counts match.
If you use a binary dump and load, remember to grab the sequence values and the _user table.
If you use SQL items, there are a few more steps to move that data.
Pay special attention to #9 on Tom's list. Big performance boost.
Practice a few times.

 

[PMiddleton]

Tom - I've gone round and round with Progress Support / Sales on making sure I get the right bits to install. I currently have 32bit OpenEdge, 4GL, RDBMS & Client networking. Originally, I wanted to use 64bit for everything but Progress does not support 64bit OpenEdge and when I went to put it on the same machine, I received a nice error message about "Hardware not capable of supporting this version". As it turns out, you have to put the OpenEdge 64bit RDBMS on a different server from the OpenEdge development license. This is how I ended up back at 32 bit. Regardless of that, I want to understand more about what you mean..."Make sure that you ordered 64 bit Progress binaries for the DB components." I do not have anything that is 64bit besides my servers.

I have a workgroup database and extents to work with - my last binary dump and load took me forever to resolve due to these extents. I know binary is the fastest however, I have a single table that pushes the 2gb limit. Client is unwilling to go to Enterprise (even with their last round of discounting).

Thanks CJ - I got burnt by the sequence values and defs last time I did a binary.

 

[PMiddleton]

I meant "OpenEdge Studio"...I inadvertently left off the "Studio" part - of course OpenEdge has 64bit...Furthermore, Progress' solution for this was to run 11.2 64bit RDBMS and run 11.1 32bit OpenEdge Studio (downgraded) in order to allow them to be installed on the same machine.

 

[Cringer]

When Tom says 64bit for DB components I'm almost certain he means a 64bit install for the server.

 

[TomBascom]

That is correct. The server should be 64 bits all around.

Only the OpenEdge client bits should (must) be 32 bit.

You cannot install both on a single machine if the bitness does not match -- but you shouldn't be installing the client stuff on a server so it ought not to be a problem.

Rumor has it that some release in the not too distant future will resolve that last issue.

 

[Rob Fitzpatrick]

I meant "OpenEdge Studio"...I inadvertently left off the "Studio" part - of course OpenEdge has 64bit...Furthermore, Progress' solution for this was to run 11.2 64bit RDBMS and run 11.1 32bit OpenEdge Studio (downgraded) in order to allow them to be installed on the same machine.

Just be aware that with Progress' "solution" of two different versions for client and server, all your client connections must be TCP, not shared-memory, i.e. using the -S parameter on DB clients and brokers.

You have an 11.2 DB and 11.1 clients. I've always been told that when there's a version mismatch the client should be higher than the server, but perhaps that has changed in v11.