We are migrating from B2 to C4 and part of the migration
is to run Change package combination by company. This in
turn calls bdbreconfig6.1. This is called as follows
bdbreconfig6.1 -Ntfacp200 -i -pB40B2WDI -n -m -f -R -C150
Note the (-f). I find that if the new package combination has
a new index or a changed index the reconfig work as follows:
1) dumps the data to flat file
2) drops the table
3) creates a new table def
4) creates new index defs
5) loads the data from flat file.

Now as the indexes are created before the data is loaded,
the data is loaded very slowly. Is there any way that I
can force the index to be created after the data load.

I have noticed that if there is no new index or index change
then the reconfig uses the fast load and creates the index
after the data load.

Porting set: 6.1c.06.06

Help please

That's a limitation from using that session, since you cannot control what's going the parameters Baan sets in the background processes.
What about doing all those steps manually? Like that, you can control everything...

Victor thanx for the reply.

My problem is that I have tested the bdbreconfig manually.
In fact the following is the command I used:
bdbreconfig6.1 -Ntfacp200 -i -pB40B2WDI -n -m -f -R -C150
and the results are exactly the same.
If you use the (-f) the bdbreconfig6.1 should only
create the indexes after the data load - But it does not.

What is more, is that I have tested this against 4 different
bdbreconfig6.1's from different proting sets. From B porting sets
to C porting sets and I get the same results.

Maybe you could point the indexes to an invalid tablespace via the ora/inf_storage file while the table is being created so that the index creation will fail and then create the indexes manually after it is done. Not sure if this will work or not - let me know if you try it.

maybe just to speed things up set the RDS_FULL to a higher value, this param has been discussed on the board so do a search.

-- -set RDS_FULL=value to define max. nr. rows transfered between client and server as one block (good for imports/exports)

I can't test this behaviour (creating the indexes before the data is loaded even with the -f option) in 6.1c.06.06 but it doesn't happen in 6.1c.06.07 which will be out soon.

Dave

Thanx all for reply.

I have already set the ora_storage to an undefined
tablespace and run the bdbreconfig, problem when
the index create fails the bdbreconfig try's to undo
the reconfig and the dbdreconfig fails.

I have also been playing with the db_resource values
this makes it faster, but I still need it alot faster.

I have requested a bdbreconfig for Port: 6.1c.06.07 on
Sun / Solaris - Hope this works. Does anyone know were
I can get this.

My only other option at this stage would be to create new
indexes directly in Oracle and manually modify the dd files
in dict. Then run the bdbreconfig. This way when new fields
are also added to the table def, the dbdreconfig will create the
indexes after the load. If no fields are added then the bdbreconfig
will not run. Will this work??

Hi there!

I guess that your main problem is the runtime needed to do the conversion rather than the behaviour of bdbreconfig.

What I did in a similar situation was:
a) identify the largest tables
b) look at the changes that are required between bdbpre and bdbpost (which is exactly what the bdbreconfigure does - read data with one DD and write according to another DD)
c) write awk-scripts to do these changes (swap columns, create new columns etc.)
d) do a bdbpre for these files, then delete them in Baan
e) do the reconfig for the rest
f) modify the seq. files with the awk-scripts
g) read these files with bdbpost (Here the -f option works for sure)
This saved us around 36 hours.

hth

Norbert

That's cool and all... but if you're good enough for Awk scripts
why not just modify the tables in the DB? Level 2 driver of course =).

Just make the change in the table, edit the d<table> file for all Package combinations that need it. And remove the Conversion indicator via GTM. *Bamph* instantly reconfigured...

I will try the new porting set. If that does not
work I will update the Oracle tables directly
and mod the dd's

Where can I get the bdbreconfig6.1 for porting set
6.1c.06.07 and Sun/Solaris?

Thanx

Dave_23

I was talking about the really huge files (tfgld106, tdsls051 etc.)
I'd bet large amounts that the time needed to do the work in the DB directly is about 10 times as long as doing it on a seq. files with awk (or perl or sed or ....)

regards

Norbert

6.1c.06.07 isn't out yet. its still in testing, should be out next month.


I think that, at least for Oracle, alter table <table name> add column .... or similar would be super quick!! Or am i missing something??

Thanks!

Dave

Thanx Dave and Norwim

Will let you know the way I go.

On the debate between which is faster - Oracle or awk, remember that if you use awk, you also have to factor in the time to dump and load the table - which does not apply to updating via Oracle.

I agree the oracle way would be super fast.
alter table <table name> add column is very fast.
And adding a index, would take the time to
create one index and not all the indexes on the
table + dump time + load time.
(If you set the oracle sort_area_size param to be
larger than the index size then all sorting is done in memory.)

I just think the oracle way may be a bit
more risky. And client want's to use standard
baan tools (i.e. bdbreconfig).

Thanx once again for the response....