hi all,

We are planing for converstion from SMS to DMS
few questions related to physical layout

1) Transactions tables and lookup tablespaces should be separate tablespaces
2) Data and Index should have separate tablespaces

where can i include frequently accessed tables
and tables which is huge in size : for huge tables i can create separate tablespaces

containers should be spread across number of LUN in the server
Any suggest would be great help
regds
Paul

I am doing a similar task but my new TSs are still SMS as well, we are just moving extra-large and heavy accessed tables to their own TSs and see if performance would improve. We create separate BP for each TS as well with the same page size.

How are you planing to move the tables? The way I am going to do it is:

- export table
- 'create table like' in new TS
- load new table from export file
- drop old table
- rename new table to old name
- create indexes
- runstats table and indexes
- rebind package(s) (after all tables moved)

Pls let me know if there any better way of doing it. Thanks

How hard would it be to create a tablespace per table?

Markham,

When moving data from A to B, I would highly advise using load from CURSOR. This way you are NOT touching the data. When ever you export data out of the table to a file, you are risking on contaminating this data. By using Cursor you do not need file system large enough to hold your data, nor you are taking a chance with screwing up with data.

Don't forget to check if you can utilize compression, and if yes. USE it.

Not hard, but why?

Some tables you want to put in its own tbs, but not one to one match.

I guess it depends on the platform

What happens When you do a LOAD REPLACE

???

That's a new one.....

You suggest a CURSOR? And INSERTS I guess?

As compared to an unload and a load?

Almost the same as if you did LOAD INSERT. But this time it will drop all the data prior to the load

I guess you never stepped on the broom twice!

There could be a special char in the data that you have to account for. I have been burned by it once, never again.

I generally do Cursor followed by the LOAD. Kind of like I just did

declare c1 cursor for select * from AAA.BBBB
DB20000I The SQL command completed successfully.

load from c1 of cursor modified by identityoverride INSERT into AAA.BBBB nonrecoverable

Started ==> Wed Sep 30 12:25:31 CDT 2009
Finished ==> Wed Sep 30 12:33:21 CDT 2009

Number of rows loaded = 41395502

LUW or z/OS - who is the winner

yes, load from cursor is better for one more reason as well - saving time not doing table export.

Create indexes took longer than loading a table. And it is better to create indexes after the table is loaded than the other way around - create indexes and than load table.

Did reorg check after table was moved to new TS and it is needed. So need to add reorg (and runstats) time for an outage.

A piece of advice - I used 'not logged initially' before loading the table and load was 20-25% faster.

Whom ever has a bigger lom

why would you need a reorg after moving it?

If you are running load and using nonrecoverable, you are not logging. So, no need to use 'not logged initially'.

i did reorgchk and it said i would need to do table reorg on primary key index.

you probably right about nonrecoverable. how abt using 'not logged initially' for create indexes?

I also changed dbm cfg UTIL_IMPACT_LIM to 100 to speed up all utilities.

lom as in "protiv loma.." or different meaning?