Hello,

I have a scenario that I would like advice on :

We intend to take a full UNIX backup of our Production Baan environment and copy it to a development server which has exactly the same disk layout. This 'duplicate' will then ( once we get it up and running, rebranded, relicenced etc) be used to test a porting set upgrade ( 6.1c.03.02 to 6.1c.06.07 ) and an upgrade to Oracle ( 7.3.4 to 8.1.7 ).

Once we are happy that the upgrade has been a success we then intend to completely wipe the Oracle 8 data on the new build,take an Oracle backup of the production database, replace the Production disks with the new build disks. Then import the previously taken Oracle export of production.

What I would like to know is ...
what problems can anyone envisage with this approach, particularly at the point where we place the build disks back in to the Producton server ?

Now.. I can see some work that needs to be done/issues with this method :

1. Need to rebrand.
2. Possible inconsistencies between UNIX updates and data held in Oracle tables ( i.e. Users ).

Has anyone done a similar activity OR provide me with any food for thought ?

Any comments will be greatly appreciated.

Thanks.

Once we are happy that the upgrade has been a success we then intend to completely wipe the Oracle 8 data on the new build,take an Oracle backup of the production database, replace the Production disks with the new build disks. Then import the previously taken Oracle export of production.


Unfortunately (well, not really), the Baan component library is kept in Oracle. Therefore, your tools etc, that are on your disks are connected to the data in Oracle.
Updating only one will result in loss of the other.

Unfortunately (well, not really), the Baan component library is kept in Oracle. Therefore, your tools etc, that are on your disks are connected to the data in Oracle.

Francesco, is right you need both the tools company-000 info as well and tools OS objects to have a replica. The way to do this is to have a different database instances for the tools company and other production companies. Then you can replicate the tools production database to the development tools database and also sync the OS files, then you would have a mirror/clone system.

BUT, for this kind of clones to work, the tools administration activities like creating/deleting/modifying users, or change of system settings etc have to be frozen/halted during the replication/cloning process. Also, additional care for tabledef6.2, Oracle SID info, remote user data, user defaults, sessions runtime info, user filter etc have to be considered during the implementation.

But I didnt get the clear picture on the purpose of this activity-
We intend to take a full UNIX backup of our Production Baan environment and copy it to a development server which has exactly the same disk layout. This 'duplicate' will then ( once we get it up and running, rebranded, relicenced etc) be used to test a porting set upgrade ( 6.1c.03.02 to 6.1c.06.07 ) and an upgrade to Oracle ( 7.3.4 to 8.1.7 ).
You can install the patches/porting sets from Dev to QA and QA to Production and use a week or 2 for evaluation if it breaks things or you can revert back. Why do you like to loose your development environment? :confused:

Thanks for the replies.

Just to explain a little further.

Nprao/Francesco....

Regarding your question relating to environments... you may find this hard to believe but in this instance the only Baan environment is the Production environment. The additional server,
( lets call it the ) QA server, that we intend to use is a short term loan server. This server will only be available for approx. 6 weeks.

The purpose of the exercise is to upgrade the Production environment from HP-UX10.20 to HP-UX11, Oracle 7.3.4 to Oracle 8.1.7, Porting set ( 6.1c.03.02 to 6.1c.06.07 ). One of the driving factors in this is that we want to do this Production upgrade in one weekend, and it wasn't looking feasible to do this, unless we tried another method.

When we initially build the QA server is will be from a full UNIX backup taken from the Production environment ( Oracle data and Baan binaries). This I can't see there being any problems with and is something we have done before...

However.. the area that I am really a little confused/worried about is once we have finished our testing on the QA we intend to upgrade the Production environment in the following manner :

1. take a full Oracle export of the Production data ( including company zero ).
2. remove the Production box disks.
3. clear down the data in the QA Oracle instance.
4. remove the QA environment disks.
5. place the QA disks in the the Production server.
6. import the Oracle export taken in step 1 into the newly built Production server.

Points to note :
- during the period that the QA server is in use, there will be a Production freeze to user change, patching etc.

I appreciate the point made about not being able to seperate the Tools company zero and the UNIX objects, but in the scenario mentioned. We will freeze changes to the Production environment. We will then be seperating the Baan binaries from the Production data for approx. 4 weeks ( although the company data that is with these QA binaries is a copy of Production ). Then bringing the current Production data and QA Baan binaries back
together again.

We would be installing Tools patches on the QA environment as a part of the upgrade process, which would lead to a discrepancy between Company zero and the UNIX binaries when we bring them back together. However I would assume that I could simply reapplly these patches when we have brought the binaries and data back together in the Production environment.

Again I would appreciate your comments.

Few thoughts, but I guess experts like Pat, Victor, Hans, OmeLuuk can contribute more here.
1. take a full Oracle export of the Production data ( including company zero ).
2. remove the Production box disks.
3. clear down the data in the QA Oracle instance.
4. remove the QA environment disks.
5. place the QA disks in the the Production server.
6. import the Oracle export taken in step 1 into the newly built Production server.

I am not quite aware of what kind of server setups you have.
If you are on multiple servers (different- app server and data servers) you will have good options to do it quickly to rebuild a clone of the production to a real working production.

1. you can change the mount points to go from one system to another. Then no need to clone the OS.
2. else you can clone the OS shouldnt be a big deal.
3. You can just change the DNS entry or the Oracle SIDs of the tools or production database and this can be added to the new baan environments setup. This will avoid the import/export process.

This wouldnt work if you modify, change table/domains on QA environment as part of evalution and cause changes to the production database. BUT, you can create new companies in production databases, freeze the table/domains changes in QA and then evaluation, when happy delete the test companies.

We do have dual environments, sharing databases on the same system, when one goes down for code migrations (non table/domain) the clone is still active and operating with different set of tools-objects/database info and same production companies. When the code/software migration is done, the master server is activated and the clone goes inactive. This helps us to reach to nearly 24x7 operations without major impacts. Ofcourse there needs to be a real big process evolution with dependencies of job schedulers, socket monitor process, webserver applications etc. :p

If I quite understand the upgrade path on QA is:
- create replicate of production in QA: same hp-ux version(?) + baan + oracle binaries + data
- then upgrade QA hp-ux (?) + oracle binaries + data and baan portingset + tools patches

Then when all validated in QA:
- export data from production: full DB export (?, includes co. 000)
- clean-up data from QA and move disks to production: this includes hp-ux (?) + oracle binaries + baan

Some points here are:
- hp-ux upgrade path on production is not clear, but i assume that an upgrade will be made on production also, don't expect that you also bring the disks of vg00 from QA (?).
- why cleaning all your data, if tools is supposed to be kept? why not do an export of 000 from QA and re-import into production to keep it up-to-date since no changes were made (just relicense it after)
- has the export/import of data part been checked to clear all possible problems, after all, you will export from 7 and import into 8...
- the full import (including 000) should work with the re-installation of the tools patches (since Baan does not know them "yet" on production even if it's using them) but you have to make sure that the new tools functionality does not depend on data changes, so double+double check all tools patches that go into QA for the upgrade...
(this is mostly critical and don't know if can be done, if those tools patches will lalso include the PMCv2 on them...)

Hi Torwin

Since this kind of migrations is one of my favourite jobs, I will give you my general approach to this kind of situation. It has been tried and tested, and I'm proud to say that I've managed to do these conversions very often in half the time compared to the estimates of other Baan gurus. ;)

Ok, here goes:

Install HP-UX 11 on the QA machine to start with.
Install Oracle 8.1.7, and create the Baan database, with the necessary tablespaces.
Create the group bsp, and the users bsp and tbase, and any other needed for the QA.
Copy the Baan environment ($BSE and lower) from the production machine. Easiest would be:

tar cvf - *|rsh <qahost> "cd <path to parent of $BSE>; tar xvf -"

Remember to also copy the dict, since this is generally at the same directory level as $BSE. While you're doing this, consider copying it to become a subdirectory of the $BSE. This will make life easier later on. If you do this, remember to edit and fix the paths in all the $BSE/lib/fd6.1.XXXX files. Easiest is to change all absolute paths in these files to $BSE/dict/..., whereby it becomes easier to move the $BSE if necessary.
Edit the $BSE/lib/tabledef6.1 file, and change the database from oracle7 to oracle8.
Make sure the oracle8 is setup correctly in $BSE/lib/ipc_info, with a line like:
oracle8 s 302 320 p ${BSE}/bin/ora8_srv6.1
Run shmvalues6.1 > shm_param in the $BSE/lib directory, and start the shared memory manager with shmmanager6.1 -i.
Do not alter the $BSE/lib/licence6.1 file! During the QA, you can use the licences from the Production machine!
Run the ora8_install6.1 script to set up the connection between Baan and Oracle8.
If needed, create the necessary Oracle users with ora8_admin6.1 script.
On the production machine, create a Baan-dump of one or two tables, and use these dumps to test (with bdbpost6.1) whether the database connection on the QA machine is working. If not, fix the database connection before proceeding to the next steps.
Check, and if necessary, create the setbse script on the QA machine.
For pumping the data across, you will need a list of the tables in the production database, in the format like tccom000. (For company 000 you will need a separate list, with the tools tables.) For increased peformance, create a list per company, with only those tables containing data. Empty tables can always be created, and this is faster than dumping and posting them.
Now for the actual pumping (started in parallel, per company, from the Production machine):

bdbpre6.1 -I<list of tables> -E<name of error file> -C<company number> | compress | \c
rsh <qahost> ". <absolute BSE path>/setbse; uncompress | bdbpost6.1 -E<error file on QA machine> \c
-f -k -m -n -c<Company number>"

After that, you can start Baan on the QA machine, and create the empty tables.
Now the only thing left to do is reference counter repair. For better performance, first do a "compute statistics" on all tables in Oracle, and then run the repair session, with options 2, 4 and 5 set to Yes.
Now you are at the point where you can start upgrading the porting set, do the testing, etc...

And then for the actual conversion back to Production. Basically the ideas are correct, but do not make an Oracle dump. Create Baan table dumps! For company 000, be careful. The best is to compare the $BSE/tools/dd contents between the Production and the QA side. If they are the same, no problem. If not, and they are changed by the patches of the new porting set, it is better to keep the $BSE/tools directory of Production, and reapply the patches after the conversion. So, create the dumps, and before pulling the plug on the machines, copy the dump files to the QA machine. Then, after switching the disks, they're ready to be posted!

Even better would be to update the QA machine completely with the newest Production data before swapping the disks. You could then use the same data pumping technique, using the scripts (that you will hopefully make for the first crossing.)

After swapping the disks, a couple of actions are needed before starting. Those that I can think of, are:

Change the IP address to the correct Production IP.
Change the hostname.
Re-run shmvalues6.1
Revalidate the Baan licence


Ok, that's it! Cost me almost an hour to create this reply! :D

Regards,
Nico

Victor,

Thank you for you comments, and you have grasped exactly what we are trying to do. This is not an ideal situation for us but necessary due to time, money, resource etc.

The actual HP-UX and Oracle upgrade will not be handled by myself but I am happy to place my trust in people more competent than myself :-). So your comments on the HP-UX aspect I hope are already in hand.

The intention is to check the Oracle7 exp. and Oracle 8 import on the QA server.

There are two points in your comments that I would like to address ( although all your comments were relevant ) :

1. the export of the company 000 data from the QA environment, and import this into the Production envrionment. This is definetly something that I will look at. Possibly as a fallback position if the full Oracle Production restore doesn't prove successful.

2. the installation of tools patches. The 'data changes' that may take place.. are you referring to actual table changes, etc contained within the patch OR something else ?

I look forward to any more comments you may have..

Nico,

I feel I have to reply to your posting after all the hard work you put into it..
its either that or I would have to pay for your time

It has taken me two hours to read it !

Your reply was excellent.. and has certainly set me thinking..

I have the following comments on your proposed upgrade strategy in relation to our situation...

- Our QA environment will not be on the same network as the production server. This rules out using the Production licence server, although this means we need to acquire a temporary licence. It also means that I won't accidentally close down the Production licence server and we can keep the hostname on the QA server the same as that on the Production server. It also kind of rules out the data-pumping technique, although it looks like something I will definetly try out at some point !

- the QA server will have exactly the same disk layout as that of the Production server. Therefore we will be copying over the Baan/Oracle directories in exactly the same format as the Production server. As soon as we have copied it to the QA server, we will perform a brief baselining exercise before proceeding with the upgrades. This way of copying means that there is an absolute minimum of configuration to do ( directory paths,users etc ).

- in our experience Oracle Imports/Exports are far quicker than using Baan functionality. You seem to be fairly adamant about using bdbpost/bdbpre. Is there a reason why we should
not use Oracle Import/export ? Is this a specific issue with company 000 export/imports ?

- your comments on the move from QA to Production were extremely useful again you don't seem too happy on using Oracle Import/Export. Generally before using bdpost, we truncate the target company tables to speed up the process ( although we rarely use bdbpost preferring to use Oracle). Obviously we wouldn't be able to truncate company zero. I would be concerned about using bdpre/bdpost for the Production upgrade due to the amount of time that it would potentially take.

Again I would like to say that your response was very much appreciated and has certainly assisted me on this particular issue. It has also given me some good ideas for future ugrades !

I would be very happy to hear any more comments on this.

Regards
Tim

Hi again Tim!

The main reason for selecting bdbpre/post is the ability to stream the data across the network. In your case unfortunately not possible! Another reason is the ability to cross-grade between databases this way, like your move from one Oracle version to the next. And no, it has nothing to do with company 000. I'm not entirely sure about reading Oracle7 dumps into Oracle8, doesn't this create the danger of incompatibility errors? I'm thinking here of the way BaanIV "misuses" date fields. I remember that we had a lot of trouble with this at another customer, where we did the same Oracle upgrade that you are doing. We had to write awk/sed scripts to change the data between the import and the export steps! So, be careful!

As for the performance of bdbpre/post vs import/export, we have developed some tricks (sorry, those I'm not giving away!) that greatly improves the performance. At a previous cross-over between Sun (temporary machine) and IBM (production), we tried both variants during the testing phase, and after some juggling, the bdb option allowed us to do the complete conversion in 16 hours flat, while the cross-over when we set up the Sun took 40 hours!

One thing in your proposed setup is actually bothering me, namely that you do not want to hook the temp machine to the network. Aren't you losing a lot of possibilities this way? Also, the licensing issue becomes so much easier! And, from the QA machine, you won't be able to kill the license daemon on the production side that easily!

Regards,
Nico

Nico,

I am fairly confident that the Export from Oracle 7.3.4 and import into Oracle 8.1.7 will be OK. Our DBAs have successfully done this in the past.

The QA server will be on a seperate network while we perform our 'techie' upgrade and testing and then reconnected to the same network as the Production system for final business acceptance testing.

There is a good reason to, initially, keep the the QA and Production environment on seperate networks. The nodename of the QA server will be the same as the Production envrionment. We are looking to minimise any issues around users connecting to the wrong server and other network issues which may be caused by duplicate nodenames.

I am not too sure about you comment on your own conversion timings. The 'bdb' method took 16 hours and the 'Oracle' method took 40 hours ? Is this correct ? If it is then I will certainly be looking more closely at improving the performance of our 'bdb' functionality. I don't suppose the speeding up of 'bdb' had anything to do with db_resource modifications ?

I do have another enquiry about licencing.. we will be putting a temporary licence onto the QA server, then after upgrading we will be clearing down the host ( keeping the local host name in ! ) and DNS entries on the QA server before moving it to the same network as the Production server. This is to avoid possible problems again with users connecting to the wrong environment. I am wondering if this may cause problems with Baans licencing, with two machines with the same nodename on the network ?

Thanks.

When you say nodename, do you mean hostname? If so, there might be some problems. In the licence6.1 file, normally you specify the hostname. Obviously this can be changed to an IP address, and poof! Problem gone. Other (in my opinion better) solution: different host names.

As for the separate networks, I'm still not convinced. (Not that I need to be, it's your environment, isn't it? ;) ) But users won't have problems connecting, depending on the DNS, and, for that matter, hostnames as stated earlier. You plan to hook the QA machine to the "real" network for business acceptance anyway. Are the hostnames to be the same during this time as well? Then (again my opinion) you are asking for trouble. If not, then there is no point in keeping the machines separated at all! Giving you the benefits of networking between Production and QA!

As for the conversion timings, you caught me. The first cross-over was done by Sun guru's. I actually don't know what technique they used. Only that (almost) everybody else predicted the same kind of conversion time would be needed to go back to the IBM, and we proved them wrong...

Hopefully this answers your questions. If not, this thread will obviously keep getting longer... :p

Regards,
Nico