Results 1 to 4 of 4
  1. #1
    Join Date
    May 2015

    Unanswered: Is storage level cloning supported for DB2?

    Basically, there are 4 logical partition created to store the database container files of the automatically managed tablespaces. As the storage capacity has reached 89% and the usual solution taken was to increase the storage by 20%, not long after that the storage capacity reaches 89% yet again.

    Hence, a decision to go for table row compression has been made and a temporary storage of 3.2 TB (800 GB x 4) was assigned to the server and added to the volume group to extend the existing 4 logical volumes.

    Now, after the table compression has done and the tablespace high water mark has been reduced, the available space has been free tremendously that leads to the plan in releasing back the temporary 3.2 TB storage to the storage server and some.

    The concern here is, the chfs was used to shrink the storage but not much was shrunk – due to a possibility of fragmentations.
    Hence, the option to add new storage and create four 1.7 TB logical volumes and perform a rsync between the respective mount points as described.

    We need your feedback on this matter and do share your concerns on any risks that you would expect from these activities. And, provide us your suggestions if there is any.

  2. #2
    Join Date
    May 2015
    We need to reclaim the space on below file system.

    /dev/lvPCPdata1 2576.00 1345.60 48% 198 1% /db2/PCP/sapdata1
    /dev/lvPCPdata2 3236.00 2005.50 39% 193 1% /db2/PCP/sapdata2
    /dev/lvPCPdata3 3231.00 2000.50 39% 194 1% /db2/PCP/sapdata3
    /dev/lvPCPdata4 2931.00 1700.53 42% 191 1% /db2/PCP/sapdata4

    All this FS having a database data file. The plan is to reclaim the size to something like this:

    /dev/lvPCPdata1 1700.00
    /dev/lvPCPdata2 1700.00
    /dev/lvPCPdata3 1700.00
    /dev/lvPCPdata4 1700.00

    In order to do this the plan is to create a new FS as below and clone the data from original FS.


    After the cloning is completed, Unix will proceed to resync the new FS with the original FS.
    Then renaming the original FS to new name and renaming new FS as original one.
    There is no changes in database path name or directory. Everything will be exactly the same.
    This will be an offline activity while database is stopped.

    Can you guys please comment on below :

    1) Would there be any impact to DB2 if we’re doing this activity.
    2) Will we able to bring up DB2 after the activity completed.
    3) Would DB2 aware about the changes which will cause any issue.
    4) Do we need to change anything in DB2 config or running a uncatalog/catalog.
    5) If the plan is approachable, kindly share the details on DB2 side to avoid any issue.


  3. #3
    Join Date
    Jul 2013
    Moscow, Russia
    Provided Answers: 55
    If you leave all the files intact eventually (including the same permissions on each file and directory), then it should work.
    But I'd recommend you to do a database backup first. Just to be safe.

  4. #4
    Join Date
    May 2012
    Canberra, Australia
    Provided Answers: 6
    We just did something similar to move to a new SAN without any dramas.

    "All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can’t get them together again, there must be a reason. By all means, do not use hammer.” — IBM maintenance manual, 1975 "

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts