A couple of questions regarding the maintenance of companies in a test package combination.

1/ What is the "best practice" for maintaining these companies? e.g making an exact copy of the "live" companies; just copying parameters and shared links etc.

2/ Assuming the answer to question 1 involves the copying of large amounts of data, what is the most efficient method?

Using BaanIVc4, Oracle8, HP-UX 11.00

Hi ,

1.Normal practice is keep the data as similar to live as possible. This can be done by sharing the master data with live companies.If many users access test environment and play with master data then it's preferable not to share master data with live.

You need to decide the periodicity of updating the test environment based on yr requirement. It can be a fortnight / month.

You may have extra VRC for your test companies (to test your new developments and also troubleshoot user issues) for each used package on top of live VRC.

2. There are lot of standard utilities/programs which help this task like repair company (tfgld9001-4m0000) , ttaad4226m000,ttaad4227m000 , bdbpre6.1,bdppost6.1 . There is one program in tccom also (I forgot the code. Currently I am not having baan with me)

There may be some utility even at oracle level.

I make a full copy of my live company apart from a couple of extremely large tables (tfgld106 and tfgld410) which I do not copy. I tend to set up a number of jobs running session ttaad4226m000 over a weekend.

It can obviously be difficult to get the data out as you need exclusive access but once you have the dumps you can build the test company at any time, although again I will always try to do this over a weekend.

We run informix and there are no doubt ways of speeding up this process but I tend to stick to the Baan sessions.

The only correction program I run during this process is tfgld9004m000 for correcting the company number.

Regards
Neal Matthews
Intier Automotive - IT Support Analyst

PS. There are other threads on the board related to this subject which you may wish to review.

Hi evertsen,

mostly depends on your test requirements. We are running exactly the same environment as you do. We are lucky that our test system is installed on separate Hardware and can easily be updated with a recovery from the normal backup tapes.
Separate hardware for a testsystem allows you to test all kind of software updates and patches (Unix, Oracle and Baan) without touching the live environment.

Regards,

Martin

Thanks for everyone's input. I was hoping there would be a shortcut out there but so far all I found is to not copy some of the larger finance tables and to pipe bdbpre to bdbpost. My next step is to set up jobs to do the work for me...

Ev

Originally posted by Martin Jung
Hi evertsen,

can easily be updated with a recovery from the normal backup tapes.



Hi Martin,
Could you please elaborate little bit more on this?
Do you have identical live & test systems with same exact configuration?
We have a similar setup like yours but according to our Unix/Oracle Admin. it is very difficult to do a recovery (in to the test system) from the normal backup tape (created in the live system), since the hardware configurations (No. of processors, Disk capacity, Table spaces in Oracle, etc.) are different. I am sure there is a way out for this.

Appreciate your feedback.

Recovery is something different. If you're expected to be able to do production recovery on the test, then the HW should be the same!

What's ongoing here is just replication of DB data and Baan for testing purposes, not a full system. Most of the time, the test system even has a few layers more for developping or other tests, meaning that it's never exactly like the production and, for sure, company 000 is different.

The test systems we manage have the most possible PMC similar level (not always easy!) and a copy of the data of the live companies. It's not updated frequently but only when it's really needed a test with the latest data from live, and even then, it's only done for the companies that need so.

Note: think of building a good export script: skip empty tables and in multi-financial setups (where some tables are located in other companies), avoid dumping the tables on other companies.
We managed to go down from 14 hours (normal export) to 5 with new dumping script for a 2 company setup!

Because although refreshing a test company may be pretty straight forward, I had to learn the hard way that the rules of the game change somewhat if your live company is large enough.

In my current situation I am dealing with a live company that is growing at a rate of about 2-4G/week. Although we are slowly reaching the point of satiation (where we can start archiving and further growth will be reduced to a more controlable level), refreshing test data has become a project of its own.

Here are some of the tricks that our team is using to keep refreshes doable:
- Refresh directly from your back-end. It will cut your time in half.
- If your test company runs on a different box, name your test company the same as your production company (test100 - prod100). This simplifies the process of doing direct database transactions.
- If you have multiple processors in your box(es), make sure to use them and multithread your exports and imports. Depending on the number of CPU's that you have available, this will decimate your runtime.
- If you have more than one "test" company (training, development, patch-testing, etc. ), scrutinize the requirements for these environments carefully. If you can get away with using a subset, then create a fitting one and save this copy for future refreshes. As a matter of fact, if you are not depending on current data (and it will be pretty hard to defend that you are, no matter what your users tell you), I would suggest refreshing from a 'snapshot-copy' anyway.

Which brings me to an interesting subject (I think), of what the ideal Baan subset should look like.
I would start a new thread on this one if it hadn't been so version dependant.

A real challenge is creating a subset that will actually diminish the number of records in your tables (say you want all of your static data, but only transactions from the past six months), while doing an import. After all, there is always room in the budget for more space on production, but when it comes to a test environment that is often a different story.

I agree with Francesco,

- Refresh directly from your back-end. It will cut your time in half.

Our DBA's got some Oracle SQL scripts which run so fast that we get daily night refresh from production companies to our DEV and QA. This is near accurate data for our developers to test our their software/programs/reproduce bugs etc. I do have to mention that our data is not yet growing to the level as Francesco mentioned.

Further, the disadvantages to the ttaad4226m000, ttaad4227m000, bdbpre6.1, bdppost6.1 is these programs might set a lock on the tables.

NPRao... any chances of getting a look at the scripts your DBA is using?

Ev

Ev,

I got a sneak preview of it now... but I dont think I can post anything out for copy right issues.

I can only explain the logic and its almost 10,000 lines of Oracle SQL code.

You need to make one *.ksh shell program which invokes login into the relevant database.

Then you need to make another *.sql program which contains the logic, the table list and company number info.

This script should be invoked on the source system as Dev/QA. We have same company numbers on DEV/QA and Production. So you basically empty out the Dev/qa table contents then connect to the production database and copy those table contents to the current database. Then fix some of the tables which have share/common tables.

So they put that shell script *.ksh in the crons, and it runs every night.

I guess thats the best I can tell you for now. I hope it helps you out and you can startup with something.

Hi Victor, hi ramchand50,

of course it's not usual to recover the whole system for testing a certain functionality in Baan and I agree that recovery is a complete different issue.
What I reported is the experience we made. In the past we faced some problems which could only reproduced with the whole range of all tables. The reuse of an order series for example. Or think of the Euro conversion. Not very useful to skip the larger tf-tables for that issue ;) .
Depending on the company size a recovery can (must not) be faster than a the normal way of dumping tables, importing, repair company number.. and it keep's your staff trained for the case of emergency :) .
We do not run exactly the same hardware but the general setup (number of servers, disk space) is the same.

Regards

Martin

Originally posted by NPRao
Ev,

I got a sneak preview of it now... but I dont think I can post anything out for copy right issues.

I can only explain the logic and its almost 10,000 lines of Oracle SQL code.

Wow, that's some code! It doesn't have to be that complex though. All you really need is a SQL-script that pulls the list of tables belonging to one company, then feeds this list and the correct parameters into the Oracle 'exp' command. Make sure you export indices and grants. After that you can transfer the 'exp' dump files to your test box and run the appropriate Oracle 'imp' command.

Pat,

The logic didnt seem complex but it seems many lines, to handle all the baan tables and our customized tables. I think its easy for them to open the existing script and just modify some company info in it and re-use to sync the data between another production company to dev/qa.

But there is no Oracle-import/export there... In short, I can only say, Inter-Database Table Data Transfers.

I am not a Oracle-Expert/Guru. I guess there is where I should keep quiet as my safe option... :o

NPrao,

That would be different alright. In my case I was talking about copying data between different database instances.

I looked through all these posts and I did not see where anyone said do a backup of company 000 on the test box before refreshing your data. I know you probably assumed that this was done, but reminders never hurt. :) You really do not want to lose company 000.

We are still trying to rebuild our test and development companies since our company 000 crash.:(

Mark