Requesting Rproduct improvement for Db2 Linux, Unix and Windows.
Problem description:
This RFE solves a problem or deficiency within an IBM database product, Db2 Linux, Unix and Windows.
The problem is that users (with authority) mistakenly change ownership and or permissions on Db2 files, directories and/or links causing Db2 to fail. This is a common problem that occurs far too often. Typically a system administrator will recursively change ownership and permissions on Db2 directories and files. Recursive means that this is a mass change, where all file system objects (ie files, directories and links) in the path are changed. The system administrator usually is trying to solve a problem and ends up creating a much bigger problem.
Db2 has specific requirements for:
o File and directory permissions. File and directory permissions controls what users can access, read, write or execute the files.
o Ownership of files and directories. Ownership of files and directories control what users can access, read, write or execute the files.
o Permissions and ownership on links
Incorrect permissions or ownership settings on files, directories or links (also known as file system objects) that are used by Db2 can cause Db2 to become inoperative.
Db2 file system objects are used to support: Db2 Code, Db2 Instances and Db2 Databases
Db2 file system objects do not all have the same ownership and permissions. File system objects all have a mix of different ownership's and permissions. Changing ownership or permissions on any of these files can cause Db2 to become non-operational.
If the system administrator issues a recursive change command you cannot just back out the change with another recursive command. A recursive command will incorrectly set all the Db2 files and directories to the same owners and permission, where some Db2 file system objects need different ownership and permissions.
When Db2 is installed with multiple instances and databases under one directory tree stucture (ie mount point) and a recursive change is made all instances and databases built under that mount point will be impacted. This will make Db2 inoperable across multiple instances and databases. Resetting the permissions and ownership to fix them is time consuming and is not a trivial task. This becomes a persuasive problem when this mistake is made on a Db2 production server where multiple instances and databases are impacted. Resolving this situation is time consuming and requires extended database outage time to fix.
Proposed solution:
My solution is to create a Db2 utility (tool) to back up and restore the Db2 permissions and ownership values of Db2 files/directories/links to the correct settings via a backup and restore process. This will allow a very quick resolution to the problem so any Db2 outage would be minimized. The tool would be similar to the "db2cfexp / db2cfimp - Connectivity configuration export/import tool".
The tool would provide support for three separate areas: Db2 Code, Db2 Instances and Db2 Databases
The below description breaks down how the tool could be designed:
Db2 Code - Backup the file system objects settings
Db2 Code - Restore the file system objects settings
Db2 Instance - Backup the file system objects settings
Db2 Instance - Restore the file system objects settings
Db2 Database - Backup the file system objects settings
Db2 Database - Restore the file system objects settings
Creating this simple tool is very easy to do. The benefits of providing this tool would be significant to our customers.
IBM Can't fix stupid. KISS, have as few mount points as possible. When this has happened before to me Db2iupdt will fix most of this. Also don't put anything db2 related on root mount (/). binaries on /opt and those should hopefully be separate mounts. Most shops are using way too many partitions with little benifit these day on I/O. For anything under 1TB would say one db2 mount point on SSD disks with 3-4 automatic storage directories is fine. This should be pretty easy to deal with perms on. If you have an admin dumb enough to mess that up they should be fired. If you have multiple instances would go with common group .. don't care what IBM says it's just a sanity thing. Anything with common group perms shouldn't be touched by any other group... If this is happening to you consistently would find another place to work.. that is unacceptable.