Moving home directory on DB2 instance?

[Hemant Shah]

Folks,

I need to move HOME directory of an instance to another directory.
What is the best way of doing it?
Is changing password file enough? or dies DB2 store this info in it's own
config?

I am running UDB 8.2 on Linux and AIX.

Thanks.
--
Hemant Shah /"\ ASCII ribbon campaign
E-mail: No************@xnet.com \ / ---------------------
X against HTML mail
TO REPLY, REMOVE NoJunkMail / \ and postings
FROM MY E-MAIL ADDRESS.
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.

[Norbert Munkel]

Hemant Shah schrieb:

Folks,

I need to move HOME directory of an instance to another directory.
What is the best way of doing it?
Is changing password file enough? or dies DB2 store this info in it's own
config?

It does, so changing the password-file is not enough.
Search the Infocenter at

http://publib.boulder.ibm.com/infoce...help/index.jsp

for "db2relocatedb".

Think this is what you are looking for.

regards,

Norbert

[Phil Sherman]

You didn't state that you need to change the instance name so I suspect
that you discovered that the /home filesystem isn't large enough to hold
your database, forcing you to "move the HOME directory".

A simple approach is to offline backup the database(s) and do a
redirected restore to another location. Don't forget to change the
location of the log files. This will, however keep the existing home
directory and all of its references to the DB2 ececutables.
If you really need to move the entire home directory then you could try
the following:
1. Make an offline backup of the database(s).
2. Shut down the instance.
3. Double check that the instance is down.
4. Mount your new disk drive/partition on a temporary directory
5. Copy the home directory and all subdirectories to the temporary
directory. This must be done keeping existing ownership and permissions
for all files. All hidden files (starting with a ".") must also be
copied. Two piped copies of the tar utility should do this.
6. Unmount the temporary directory.
7. Mount the new disk drive/partition at the home directory of the
instance. browse through it and make sure that all links and files
appear present. Use the "df" command to verify the mount worked.
8. Start the instance in maintenance mode. verify that your tables are
accessable using only select statements. Shutdown the instance.
9. Unmount the disk/partition mounted on the home directory. Verify that
the unmount worked properly.
10. Delete all of the files and subdirectories of the home directory.
11. Remount the new disk drive/partition at the home directory.
12. Modify fstab to automount this at boot time.

The final step is to reboot the system and verify that the new
drive/partition is correctly mounted, allowing instance startup.

Phil Sherman


Hemant Shah wrote:

Folks,

I need to move HOME directory of an instance to another directory.
What is the best way of doing it?
Is changing password file enough? or dies DB2 store this info in it's own
config?

I am running UDB 8.2 on Linux and AIX.

Thanks.

[Hemant Shah]

While stranded on information super highway Norbert Munkel wrote:

Hemant Shah schrieb:

Folks,

I need to move HOME directory of an instance to another directory.
What is the best way of doing it?
Is changing password file enough? or dies DB2 store this info in it's own
config?
It does, so changing the password-file is not enough.
Search the Infocenter at

http://publib.boulder.ibm.com/infoce...help/index.jsp

for "db2relocatedb".

Think this is what you are looking for.

Thanks, that is exactly what I am looking for.
regards,

Norbert

--
Hemant Shah /"\ ASCII ribbon campaign
E-mail: No************@xnet.com \ / ---------------------
X against HTML mail
TO REPLY, REMOVE NoJunkMail / \ and postings
FROM MY E-MAIL ADDRESS.
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.

[Hemant Shah]

Thanks for the info, but that is not what I was trying to to.

I am adding a new file system and want to move the db2instance to the new
file system. There are other users on the current filesystem and I want to
keep them there.

Norbert suggested db2relocatedb command in his post, that is exactly what I
was looking for.
While stranded on information super highway Phil Sherman wrote:

You didn't state that you need to change the instance name so I suspect
that you discovered that the /home filesystem isn't large enough to hold
your database, forcing you to "move the HOME directory".

A simple approach is to offline backup the database(s) and do a
redirected restore to another location. Don't forget to change the
location of the log files. This will, however keep the existing home
directory and all of its references to the DB2 ececutables.
If you really need to move the entire home directory then you could try
the following:
1. Make an offline backup of the database(s).
2. Shut down the instance.
3. Double check that the instance is down.
4. Mount your new disk drive/partition on a temporary directory
5. Copy the home directory and all subdirectories to the temporary
directory. This must be done keeping existing ownership and permissions
for all files. All hidden files (starting with a ".") must also be
copied. Two piped copies of the tar utility should do this.
6. Unmount the temporary directory.
7. Mount the new disk drive/partition at the home directory of the
instance. browse through it and make sure that all links and files
appear present. Use the "df" command to verify the mount worked.
8. Start the instance in maintenance mode. verify that your tables are
accessable using only select statements. Shutdown the instance.
9. Unmount the disk/partition mounted on the home directory. Verify that
the unmount worked properly.
10. Delete all of the files and subdirectories of the home directory.
11. Remount the new disk drive/partition at the home directory.
12. Modify fstab to automount this at boot time.

The final step is to reboot the system and verify that the new
drive/partition is correctly mounted, allowing instance startup.

Phil Sherman


Hemant Shah wrote:

Folks,

I need to move HOME directory of an instance to another directory.
What is the best way of doing it?
Is changing password file enough? or dies DB2 store this info in it's own
config?

I am running UDB 8.2 on Linux and AIX.

Thanks.

--
Hemant Shah /"\ ASCII ribbon campaign
E-mail: No************@xnet.com \ / ---------------------
X against HTML mail
TO REPLY, REMOVE NoJunkMail / \ and postings
FROM MY E-MAIL ADDRESS.
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.

[Phil Sherman]

db2relocatedb will NOT move the instance. It allows you to move a
database to a different instance or move it to a new location within the
same instance. The instance "location" is determined by the operating
system when the userid is established. For both Linux and AIX, userids
are, by default, defined in the /home directory. To move a single userid
to another filesystem; you would usually define a different home
directory, ie. /home1/db2inst1 where the new file system is mounted at
/home1.

If you are moving a single userid (instance), the technique I documented
will move everything; the database(s) instance configuration files,
references to the installation libraries (do an ls -l on
/home/db2inst1.sqllib) and anything else you've put in the instance
owner's home directory or subdirectories. It has the advantage of
avoiding changes to any references to the instance, such as a user
executing the instance's db2profile before connecting. Mounting the new
filesystem on the instance owner directory avoids impacting any other
userids and guarantees that all files associated with the instance end
up on the new filesystem. It can also be done with the system up and
running without impact to other users.

If all you need to do is to relocate a database; then db2relocatedb will
do that. My experience tells me that one should always take an offline
backup (if possible) before attempting a change this significant. It
should give you an excellent recovery mechanism if anything goes wrong
when moving the database. Once you have the backup; then a redirected
restore will also move the database.

There's always more than one way to accomplish most tasks. Choose the
one you like best.

Phil Sherman

Hemant Shah wrote:

Thanks for the info, but that is not what I was trying to to.

I am adding a new file system and want to move the db2instance to the new
file system. There are other users on the current filesystem and I want to
keep them there.

Norbert suggested db2relocatedb command in his post, that is exactly what I
was looking for.
While stranded on information super highway Phil Sherman wrote:

You didn't state that you need to change the instance name so I suspect
that you discovered that the /home filesystem isn't large enough to hold
your database, forcing you to "move the HOME directory".

A simple approach is to offline backup the database(s) and do a
redirected restore to another location. Don't forget to change the
location of the log files. This will, however keep the existing home
directory and all of its references to the DB2 ececutables.
If you really need to move the entire home directory then you could try
the following:
1. Make an offline backup of the database(s).
2. Shut down the instance.
3. Double check that the instance is down.
4. Mount your new disk drive/partition on a temporary directory
5. Copy the home directory and all subdirectories to the temporary
directory. This must be done keeping existing ownership and permissions
for all files. All hidden files (starting with a ".") must also be
copied. Two piped copies of the tar utility should do this.
6. Unmount the temporary directory.
7. Mount the new disk drive/partition at the home directory of the
instance. browse through it and make sure that all links and files
appear present. Use the "df" command to verify the mount worked.
8. Start the instance in maintenance mode. verify that your tables are
accessable using only select statements. Shutdown the instance.
9. Unmount the disk/partition mounted on the home directory. Verify that
the unmount worked properly.
10. Delete all of the files and subdirectories of the home directory.
11. Remount the new disk drive/partition at the home directory.
12. Modify fstab to automount this at boot time.

The final step is to reboot the system and verify that the new
drive/partition is correctly mounted, allowing instance startup.

Phil Sherman

[Hemant Shah]

Let me see if I understand your method correctly.

Let's say I have a /home filesystem containing db2 instance which does not
have enough diskspace.

I move everything to a new filesystem and re-mount it as /home.
It that is correct, then it is not what I am trying to do.

In my case, I have other users in /home (including another database instance),
and I want to move one instance from /home to /home1.

While stranded on information super highway Phil Sherman wrote:

db2relocatedb will NOT move the instance. It allows you to move a
database to a different instance or move it to a new location within the
same instance. The instance "location" is determined by the operating
system when the userid is established. For both Linux and AIX, userids
are, by default, defined in the /home directory. To move a single userid
to another filesystem; you would usually define a different home
directory, ie. /home1/db2inst1 where the new file system is mounted at
/home1.

If you are moving a single userid (instance), the technique I documented
will move everything; the database(s) instance configuration files,
references to the installation libraries (do an ls -l on
/home/db2inst1.sqllib) and anything else you've put in the instance
owner's home directory or subdirectories. It has the advantage of
avoiding changes to any references to the instance, such as a user
executing the instance's db2profile before connecting. Mounting the new
filesystem on the instance owner directory avoids impacting any other
userids and guarantees that all files associated with the instance end
up on the new filesystem. It can also be done with the system up and
running without impact to other users.

If all you need to do is to relocate a database; then db2relocatedb will
do that. My experience tells me that one should always take an offline
backup (if possible) before attempting a change this significant. It
should give you an excellent recovery mechanism if anything goes wrong
when moving the database. Once you have the backup; then a redirected
restore will also move the database.

There's always more than one way to accomplish most tasks. Choose the
one you like best.

Phil Sherman

Hemant Shah wrote:

Thanks for the info, but that is not what I was trying to to.

I am adding a new file system and want to move the db2instance to the new
file system. There are other users on the current filesystem and I want to
keep them there.

Norbert suggested db2relocatedb command in his post, that is exactly what I
was looking for.
While stranded on information super highway Phil Sherman wrote:

You didn't state that you need to change the instance name so I suspect
that you discovered that the /home filesystem isn't large enough to hold
your database, forcing you to "move the HOME directory".

A simple approach is to offline backup the database(s) and do a
redirected restore to another location. Don't forget to change the
location of the log files. This will, however keep the existing home
directory and all of its references to the DB2 ececutables.
If you really need to move the entire home directory then you could try
the following:
1. Make an offline backup of the database(s).
2. Shut down the instance.
3. Double check that the instance is down.
4. Mount your new disk drive/partition on a temporary directory
5. Copy the home directory and all subdirectories to the temporary
directory. This must be done keeping existing ownership and permissions
for all files. All hidden files (starting with a ".") must also be
copied. Two piped copies of the tar utility should do this.
6. Unmount the temporary directory.
7. Mount the new disk drive/partition at the home directory of the
instance. browse through it and make sure that all links and files
appear present. Use the "df" command to verify the mount worked.
8. Start the instance in maintenance mode. verify that your tables are
accessable using only select statements. Shutdown the instance.
9. Unmount the disk/partition mounted on the home directory. Verify that
the unmount worked properly.
10. Delete all of the files and subdirectories of the home directory.
11. Remount the new disk drive/partition at the home directory.
12. Modify fstab to automount this at boot time.

The final step is to reboot the system and verify that the new
drive/partition is correctly mounted, allowing instance startup.

Phil Sherman

--
Hemant Shah /"\ ASCII ribbon campaign
E-mail: No************@xnet.com \ / ---------------------
X against HTML mail
TO REPLY, REMOVE NoJunkMail / \ and postings
FROM MY E-MAIL ADDRESS.
-----------------[DO NOT SEND UNSOLICITED BULK E-MAIL]------------------
I haven't lost my mind, Above opinions are mine only.
it's backed up on tape somewhere. Others can have their own.