Hi all,

Can someone tell me if there is another way to get a sequentiel dump of table of our live company. Because ttaad4226m000 takes around 5 hours and we execute it daily.

Thank you for your help

Hi there,

was this session basically does is to call bdbpre6.1 (or bdbpre6.2 in case of Baan V).
bdbpre6.1 -U shows usage, what really helps is the -f parameter, this suppresses usage of the index and reads data only. (hope it really is '-f', no system at hand atm to check)
What also might be very handy is to paralize execution (as a thumbrule: start 1 bdbpre6.1 less than you have CPUs).
So: create a file with the tablenames to be dumped.
Divide this file into several files (taking care that each file contains more or less the same number of names of large tables)
Start several bdbpre6.1 processes with one file each.

bdbpre6.1 -f -Ifilename1 -pPACKAGE_COMB -CCOMPNO > part1
bdbpre6.1 -f -Ifilename2 -pPACKAGE_COMB -CCOMPNO > part2 .. etc

(From memory ... check syntax with bdbpre6.1 -u/U)

That should cut down the time drastically.

hth

Norbert

Norbert's idea works if you can setup multiple jobs/shell-scripts to work on different companies in parallel.

You can also change the db_resource settings to change the values of - ssts_set_rows, ora_max_array_fetch, ora_max_array_insert to increase the speed.

Also be aware that this dump process locks the table, make sure there are no users/active jobs in the system at that time.

Why dont you consider taking the Oracle hot/cold-backups ?

agreed NPRao,

I think that ora_max_array_fetch is the parameter that speeds up dumps if increased, but why do you say 'different companies'?
The main idea is to gain speed by having more than one dump running at the same time.
I was in fact thinking of one company.
Of course this assumes that noone is working in this company from the start of the first dump until the completion of the last ... but to create a consistent dump this would have to have been the case anyway for the 5 hours that one dump took without parallelizing.
Only that (depending on the number of bdbpre-jobs running parallelly) the downtime would be significantly shorter.

regards

Norbert

P.S.: What is the correct english diction for 'having jobs run in parallel' btw? 'paralize' sounds very wrong now that I read my former post :-(

but why do you say 'different companies'?
Sorry I wasn't clear. I meant he can divide the dump process, each script for a particular company. For a single company, one can generate dumps by the table lists or by package list to make it faster. Either way we cannot guarantee the data consistency.

I would suggest to use the Oracle cold-backups.

If we're talking oracle there is no faster way than "exp direct=y ..."
we're talking lightning fast.

In SQL Server you could sp_detatch, copy file, done.

i'm sure there's a way to do something similar with informix and db2 as
well.

Dave

You should do backups from the database itself, I do not see any reasons to do daily exports unless strictly needed (except to create a daily copy on a test server running with a different database).
If there is no other way except thru exports, then use the paralell bdbpre as mentioned before by splitting the table list.

If your scripting capabilities are up to it (windows?), then I would generate those list(s) of tables from the database itself by selecting only the company tables that have a number of rows > 0 to avoid Baan to dump empty tables. This saves time since a lot of tables are not used and thus are empty.

You may also save time by temporarily removing logical tables links (i.e., save off current $BSE/lib/compnr6.x file & creating an empty one, doing bdbpre, putting links back).

You may also save time by temporarily removing logical tables links (i.e., save off current $BSE/lib/compnr6.x file & creating an empty one, doing bdbpre, putting links back).
In fact this is not needed if you generate the list of tables (with rows > 0) from the database to be used in the export, since the database does not know that there are tables linked to another company.

Just be be aware that if you plan to build a standalone company from a multy-fincancial setup, these exports will not allow you to do so since the "linked" tables were not dumped at all.