Do anyone know how to improve the speed for sequential dump? my OS is Unix and oracle. My session take 5 hours to dump 4.5GB, it is normal or can be improve? By the way, the dump file can be place in other media like tape?

You can set the system variabele RDS_FULL:

export RDS_FULL=200

When you can redirect your output of bdbpost (when running from command line) I think it's possible to send it via cpio to a tape device, but for better performance I think its better to export it first to disk.

Bennie Kriekaard
Profuse B.V.

Sorry, I am newbie and where can I set the system variable RDS_FULL, on OS or DB?

5 hours for 4.5 GB is pretty bad. I don't think it's going to be fixed by RDS_FULL, SSTS_SET_ROWS, etc.. although they're always good to set!

Sounds more like an I/O problem is the filesystem your writing
to NFS mounted? because that would do it.

Dave

Dave, can you tell me how to set the value, at least let me try it out first. Never try never know...

thank

If you're using the session, and you're using the BW then it's (in your bw configuration screen under "Command")

-- -set SSTS_SET_ROWS=1000 -set RDS_FULL=1000 -set ORA_MAX_ARRAY_FETCH=1000 -set ORA_MAX_ARRAY_INSERT=1000

Dave

Dear kokchuan,

u have to change db_resource file paramater to improve the speed for sequential dump. we have seq dump size around 11 GB. it normaly completed in 1 hour only, but my OS is win2k3 & database is oracle 9.2.

I assume you are doing a full company export. There are ways to improve the speed if there's no disk IO contention (no network drives/mounts) like:
1. use better db_resource related parameters to increase the nr. of rows fetched
2. dump on a per table basis (and not per company)
3. dumping only the tables that have >0 rows (a lot of the tables in a acompany are empty, you can avoid the Baan overhead of them by gathering a list from the database of the tables with rows > 0 to be used in 2)
4. split the list of tables (from 3) in 4 files and run 4 bdbpre, one for each list (dump in parallell, this can even be improved by spliting the dumps based on table size, so that the dump is really well balanced)

Building such a thing needs some [good] knowledge of the bdbpre parameters, db_resource parameters, SQL (database) and unix shell scripting (for unix, on windows probably is a bit more dificult). Search the threads on these topics.

To speed up dumps, you can temporarily remove logical table links by saving of compnr file and then creating an empty one. This way you won't get multiple copies of the same data (i.e., Item Master in company 100 is shared by both 300 and 400 so when doing bdbpre 100-400 with links in place you would get 3 copies--without links, just the 1 copy). Just remember to put them back.

Can you specify which area you are mentioned? It is database or in Baan? How to remove the logical table link? If not using the logical table then what should I do?

Thank

Can you specify which area you are mentioned? It is database or in Baan? How to remove the logical table link? If not using the logical table then what should I do?

Carefull when playing with the logical links, and if you do not know what they are and on which table they are it's because you do not use them.
Go for the approach of getting the list of the tables from the database (with count(*) > 0) and use multiple bdbpre's on them - this works well for companies with or without logical links since you will be picking the real physical tables of the company, not linked ones.

Runtime for logical tables is $BSE/lib/compnr6.2.

Regarding the above posting, it all depends on what you want to do. In regards to taking dumps of all tables with count > 0, it depends on when you take the snapshot and how (i.e., is everyone locked out or not) as sometimes tables--especially work tables--can have no data and then have some. Also, dumping zero row tables I don't believe takes much time.

If you have a multiple logistic with a single financial then you could get several copies of your integration table (for ex. tfgld410) which you only need the 1 real copy. This can be a HUGE space savings.

If no one is in the system--which is obviously the case if you have UNlinked the logical tables--then dumping them poses no big problems. The only thing I can think of right off hand is that you have an old orphaned table that exists (i.e., table started off stand-alone and was created, then logically linked in Baan and original stand-alone table in Oracle/DB wasn't deleted before linking). However, if the links are put back in before you bdbpost the data back in, you'll get a message that the table already exists or is linked.

Hope this makes sense--if not, please post if more clarification is needed.