The level of difficulty of doing this depends on the block layout of those two partitions: which one comes first on the disk in terms of start block and end block, whether there is any other partition of any empty space between them, etc...
It will also be necessary that the filesystem used on
/db2/ade/sapdata1 supports shrinking. xfs, for example, does not.
I present an example for your information. It's quite a dangerous operation and I don't recommend that you do it. But it will give you an idea of what's involved. The example is the easiest case. Other cases are much more difficult because you might have to move data backwards (counting from the last block toward the first) from one location to another in a partition.
Let's say p15 is stored first on the disk followed by p2, they together occupy the whole disk, there are no other partitions, and no free blocks. This is what you would have to do:
- Shrink the filesystem on p15
- Shrink the p15 partition to the new size of the filesystem. This will create free space between the two partitions.
- Unmount p2 (/db2)
- Change the start block of the p2 partition to the first free block made available in step 2 (i.e. back up the start of the partition to be earlier on the disk)
Move the data backwards on the disk with a command like this:
dd if=/dev/cciss/c0d0p2 of=/dev/cciss/c0d0p2 bs=xxx skip=yyy
xxx should be a large block size which divides without remainder the amount by which you are growing the partition and
yyy should be the number of bytes by which you are growing the partition divided by
Grow the /db2 filesystem.
As you can imagine, step 5 is an extremely dangerous operation. It will take a long time to execute and it may be very difficult to recover if it fails or is interrupted. You must understand what you are doing if you undertake this.
Another option if you are running under Linux would be to leave all of the existing data where it is and use the device mapper to stitch together an existing partition plus some non-adjacent empty space together into one larger virtual partition. This is basically something LVM would do, but without the nice LVM user interface and metadata that stitches block ranges together automatically and transparently.