Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
Database Servers
DB2InformixIngresMS SQLOraclePervasive.SQLPostgreSQLProgressSybase
Desktop Databases
FileMakerFoxProMS AccessParadox
General
General DB TopicsDatabase Theory
Related Topics
Java Development.NET DevelopmentVB DevelopmentMore Topics ...

Database Forum / DB2 Topics / April 2008

Tip: Looking for answers? Try searching our database.

How to change schema of table in DB2 v.8.2 without coping data

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Dmitriy Lapko - 16 Apr 2008 13:49 GMT
Hallo all

Is it possible to change schema of table in DB2 v.8.2 without
recreating and coping a table into a new schema?

I need it for several purposes, one of them - refactoring of existing
old database with more then 250 tables. I would like to split it to
subsystems, but some of tables are quite large.

And the size of tables prevents me from getting copy of production
database for our test envi-ronment. Total backup is almost 500 Gbytes.
But 98% of these data are stored in 3 tables, which are just archive.
So I planned:
1) move them to another schema,
2) create views in old schema, which will point to a new,
3) create a new user, which will have read access only to old schema.

So I will be able to make a backup under this new user with almost all
tables but much less then 500GB.

Why don't I use IMPORT/EXPORT? Because a lot of tables have IDENTITY
GENERATED ALWAYS, so I have conflicts in IDs when I load exported
data. Also, db2move tool allows only 10 table names to be specified at
a time...

But may be there are another ways to make partial backup of the big
database? And another way to refactor it to group tables by systems
else then by schemas?

Thank you in advance!
Serge Rielau - 16 Apr 2008 16:31 GMT
> Why don't I use IMPORT/EXPORT? Because a lot of tables have IDENTITY
> GENERATED ALWAYS, so I have conflicts in IDs when I load exported
> data. Also, db2move tool allows only 10 table names to be specified at
> a time...
Why don't you use LOAD instead of IMPORT. It is faster and can handle
generated columns just fine.

Also IIRC you can drop (and add) the identity property in DB2 8.2.

Cheers
Serge
Signature

Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Lennart - 18 Apr 2008 10:21 GMT
> > Why don't I use IMPORT/EXPORT? Because a lot of tables have IDENTITY
> > GENERATED ALWAYS, so I have conflicts in IDs when I load exported
[quoted text clipped - 5 lines]
>
> Also IIRC you can drop (and add) the identity property in DB2 8.2.

Slightly offtopic, but ... I assume IDENTITY GENERATED ALWAYS is
implemented via a sequence, correct? If so, is it possible to
determine which sequence that is used for a table?

/Lennart
Serge Rielau - 18 Apr 2008 12:24 GMT
> Slightly offtopic, but ... I assume IDENTITY GENERATED ALWAYS is
> implemented via a sequence, correct? If so, is it possible to
> determine which sequence that is used for a table?
SYSCAT.COLIDENTATTRIBUTES.SEQID

Cheers
Serge
Signature

Serge Rielau
DB2 Solutions Development
IBM Toronto Lab

Lennart - 18 Apr 2008 18:10 GMT
> > Slightly offtopic, but ... I assume IDENTITY GENERATED ALWAYS is
> > implemented via a sequence, correct? If so, is it possible to
[quoted text clipped - 8 lines]
> DB2 Solutions Development
> IBM Toronto Lab

Thanx
/Lennart
Lennart - 18 Apr 2008 13:12 GMT
> > Why don't I use IMPORT/EXPORT? Because a lot of tables have IDENTITY
> > GENERATED ALWAYS, so I have conflicts in IDs when I load exported
[quoted text clipped - 3 lines]
> Why don't you use LOAD instead of IMPORT. It is faster and can handle
> generated columns just fine.

Don't know what happened to my post. Here it goes again. I assume
identity columns are implemented using a sequence (correct?). If so,
is it possible to determine which sequence that is connected to a
identity column?

/Lennart
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.