Adding, Dropping Storage Path(s) and Rebalancing Tablespaces

Transcription

1 Adding, Dropping Storage Path(s) and Rebalancing Tablespaces Applies to: All SAP releases on DB2 9.7 for Linux, UNIX, and Windows. For more information, visit the Landscape Design and Architecture homepage. Summary One of the DB2 9.7 manageability enhancements with automatic storage supports removing storage paths from a database and rebalancing the tablespaces online. In this document, we provide step by step instructions on how to rebalance an automatic storage tablespace after storage paths have been added to or removed from a database. Some of the performance data is also provided based on the test done at our lab. Author: Cong Lin Company: IBM Canada Created on: 01 November 2009 Author Bio Cong Lin is a member of the IBM SAP Integration and Support Center at the IBM Toronto Lab. Her current activities include testing of SAP applications with DB2 for LUW and helping customers with problem analysis and troubleshooting. She is also a customer advocate, providing support for large customer accounts running SAP and DB2 LUW SAP AG 1

2 Table of Contents 1 Overview Preparation Step by Step Instructions Adding Storage Paths Procedures Performance Data Removing Storage Paths Procedure Performance Data Adding and Removing Storage Paths at the Same Time Procedure Performance Data Rebalancing Tablespaces Rebalance the Tablespaces Monitor the Status of the Rebalancing Process Throttling the Rebalancing Process (Optional) Other Considerations Related Content Disclaimer and Liability Notice SAP AG 2

3 1 Overview Automatic storage is a DB2 feature intended to make storage management easier. Databases that are enabled for automatic storage have a set of one or more storage paths associated with it. You can modify this set of storage paths using the ALTER DATABASE statement. In DB2 releases prior to DB2 9.7, you were only able to add storage paths to a database that was enabled for automatic storage. Once added, there was no possibility to remove them without bringing the database down and causing an outage. Newly added storage paths were also not immediately used by existing automatic storage tablespaces. Only if the disk space on the existing storage paths was full and existing tablespace containers could not be extended to accommodate the growth, the newly added storage paths was used. As a result, adding new storage paths alone could only address the issue of capacity. To improve the I/O parallelism as well, redirected restore is needed. As of DB2 9.7, you can immediately use any storage that you add to an automatic storage database by rebalancing the automatic storage tablespaces. Rebalancing initiates the creation of containers on recently added storage paths, reallocates the data across the new, expanded set of containers and stripe sets. Therefore, rebalancing after new storage paths have been added to the database improves I/O parallelism for the tablespaces. Also starting from DB2 9.7, you no longer need to perform a redirect restore to remove some existing storage paths. You can now online remove existing storage paths from database enabled for automatic storage. Following are the three user scenarios that take advantage of these new features in DB2 9.7: Adding storage paths and rebalancing automatic storage tablespaces Removing storage paths and rebalancing automatic storage tablespaces Adding and removing storage paths and rebalancing automatic storage tablespaces In this document, we provide a step by step guide on how to perform above storage management tasks and to illustrate the impact of adding and removing storage paths on automatic storage tablespaces SAP AG 3

4 2 Preparation Before you start working on any of the three scenarios described in this document, make sure you read the following checklist: 1. Check if you instance is at the correct level: DB2 9.7 GA and higher This document is meant for DB2 9.7 and higher. To check, run the db2level command. 2. Check if your current database is already enabled for automatic storage. The following example shows a database that has not yet been enabled for automatic storage: saplp4: db2ax4> db2pd db AX4 -storagepaths Database Partition 0 -- Database AX4 -- Active -- Up 0 days 00:49:18 saplp4: db2ax4> Database db2pd Storage db AX4 Paths: -storagepath Database Partition Number 0 -- of Database Storage Paths AX4 -- Active 0 -- Up 0 days 00:49:18 Database Storage Paths: Any value that does not equal 0 in the Number of Storage Paths indicates that the database is enabled for automatic storage. Take a note on how many storage paths your database has and continue with the next step. If your database has not yet enabled for automatic storage, see document Enable Automatic Storage for Your SAP Database and Table Spaces for details. 3. Check if your tablespaces are already enabled for automatic storage. In this document, we also assume that all your permanent tablespaces are managed by automatic storage. If this is not the case, see document Enable Automatic Storage for Your SAP Database and Table Spaces for details. You can use following SQL command to check if table spaces are managed by automatic storage, A value 1 in the field TBSP_USING_AUTO_STORAGE indicates this table space is managed by automatic storage. SELECT SUBSTR(TBSP_NAME, 1,30) as TBSP_NAME, TBSP_USING_AUTO_STORAGE from TABLE(SNAP_GET_TBSP_V91('')) AS T TBSP_NAME TBSP_USING_AUTO_STORAGE PSAPTEMP16 1 D97#ODSD 1 D97#ODSI 1 D97#DIMD 1 D97#DIMI 1 D97#FACTD 1 D97#FACTI SAP AG 4

5 4. Get the new storage paths ready. If you plan to add new storage paths or move data from existing storage paths to new paths, make sure these new storage paths have been created. If you have a multi partition database, make sure these new storage paths exist on all partitions. 5. Make sure that there is enough disk space available. This step is critical for a successful rebalance as described in the following: For adding new storage path case, since the new containers on the new storage paths must be created before the data could be moved, the tablespaces will have a much bigger total size during and after the rebalancing. Make sure the new storage paths have enough disk space to host the new containers for the data. For more information about the layout of a tablespace before and after it was rebalanced, see the Figure 1below. For example, if your tablespace currently has 4 containers over 2 existing storage paths (2 containers per path), you just add one more storage path to the database. Rebalancing this tablespace creates 2 new containers of the same size like those existing ones on the new storage path. If your tablespace has a size of approx. 100 GB, then 50 GB free space on the new storage path is needed for a successful rebalancing process. After the rebalancing is done, the size of the tablespace will be 150 GB. However, the high-water mark of the tablespace should stay the same as before the rebalancing process. You can reduce the total size of the tablespace using ALTER TABLESPACE REDUCE statement. To drop a storage path, make sure that the rest of the existing storage paths have enough space to host the containers for existing data plus data from the dropped path. For more information about the layout of a rebalanced tablespace before and after the storage path was dropped, see Figure 2. Figure 1. Adding a storage path and rebalancing an automatic storage table space 2009 SAP AG 5

6 Figure 2. Dropping a storage path and rebalancing an automatic storage table space 3 Step by Step Instructions 3.1 Adding Storage Paths Procedures In this example, the original database was created on two storage paths (sapdata5 and sapdata6). Two more storage paths (sapdata7 and sapdata8) are added. 1. Take a tablespace snapshot and run db2pd to keep a record of the starting status. In the following example, there are two storage paths in this database: saplp4: db2ax4>db2pd d AX4 -storagepaths Database Partition 0 -- Database AX4 -- Active -- Up 5 days 02:25:28 Database Storage Paths: Number of Storage Paths 2 Address PathID PathState PathName 0x CB20 0 InUse /db2/ax4/sapdata5 0x C840 1 InUse /db2/ax4/sapdata SAP AG 6

7 The following is an example of a tablespace snapshot for AX4#DDICD. Take note of the number and location of the containers. The tablespace map shows one stripe set. saplp4: db2ax4>db2 get snapshot for tablespaces on AX4 Tablespace name = AX4#DDICD Total number of pages = Number of used pages = High water mark (pages) = Number of containers = 2 Container Name Container Name = /db2/ax4/sapdata5/db2ax4/node0000/ax4/t /c lrg = /db2/ax4/sapdata6/db2ax4/node0000/ax4/t /c lrg Table space map: Range Stripe Stripe Max Max Start End Adj. Containers Number Set Offset Extent Page Stripe Stripe [ 0] [ 0] (0,1) 2. Add the storage paths using the following ALTER DATABASE statement: ALTER DATABASE <DBName> ADD STORAGE ON <Path1> [,<Path2>,...,<Pathn>] Example: alter database AX4 add storage on '/db2/ax4/sapdata7', '/db2/ax4/sapdata8'; Note: After the new storage paths are added, they are not immediately used by the tablespaces. Run db2pd to check the status of all 4 database storage paths and note down the data in PathState column. saplp4: db2ax4> db2pd db AX4 -storagepaths Database Partition 0 -- Database AX4 -- Active -- Up 5 days 02:47:09 Database Storage Paths: Number of Storage Paths 4 Address PathID PathState PathName 0x CB20 0 InUse /db2/ax4/sapdata5 0x C840 1 InUse /db2/ax4/sapdata6 0x D8EE5C0 4 NotInUse /db2/ax4/sapdata7 0x D81F560 5 NotInUse /db2/ax4/sapdata SAP AG 7

8 3. Identify all the tablespaces that should be striped across both existing and new paths. Assume that you want all your permanent tablespaces take advantage of the new storage paths right away. To determine all of the affected permanent tablespaces, you can manually scan the tablespace snapshot or using a SQL statement. The following SQL statement generates a list of all the regular and large automatic storage tablespaces in the database: SELECT TBSP_NAME FROM SYSIBMADM.SNAPTBSP WHERE TBSP_USING_AUTO_STORAGE=1 AND TBSP_CONTENT_TYPE IN ('ANY','LARGE') ORDER BY TBSP_ID; 4. Rebalance all the tablespaces provided in the previous step. To rebalance a table space, issue the following statement: ALTER TABLESPACE <TablespaceName> REBALANCE; Note: The rebalancing process might significantly impact your system performance. For more information, see section 3.4 Rebalance the tablespaces before kicking off any table spaces rebalance activity. Careful planning on when, how and which tablespace should be rebalanced at a certain time is important. 5. Confirm that the rebalancing process for all affected tablespaces has finished. To check the number of containers and their locations for all affected tablespaces, take a tablespace snapshot. In the following example, the number of containers was increased from 2 to 4. There should be only one stripe set in the tablespace map. Tablespace name = AX4#DDICD Total number of pages = Number of used pages = High water mark (pages) = Number of containers = 4 Container Name = /db2/ax4/sapdata5/db2ax4/node0000/ax4/t /c lrg Container Name = /db2/ax4/sapdata6/db2ax4/node0000/ax4/t /c lrg Container Name = /db2/ax4/sapdata7/db2ax4/node0000/ax4/t /c lrg Container Name = /db2/ax4/sapdata8/db2ax4/node0000/ax4/t /c lrg Table space map: Range Stripe Stripe Max Max Start End Adj. Containers Number Set Offset Extent Page Stripe Stripe [ 0] [ 0] (0,1,2,3) 2009 SAP AG 8

9 6. Optionally, reduce the tablespace size if needed. In the above example, note down the Total number of pages and High-water mark fields of the tablespace AX4#DDICD and compare the values with those in step 1. You will notice that the highwater mark stays the same but that Total number of pages has been doubled. This is due to the fact that the size of two new containers (one on each new path) created at the start of the rebalance process is the same as those of the two existing containers. Once the tablespace has been rebalanced, you could optionally reduce the size of this tablespace by running following SQL statement: ALTER TABLESPACE <tablespace_name> REDUCE; Here is an example: alter tablespace AX4#DDICD reduce; Performance Data The following describes how performance data is collected for our test scenario. While the rebalancing process was running, there were not many other concurrent activities on the database system. The time needed to rebalance a tablespace with a similar size on your system might vary in your particular environment. This will be affected by the file system layout, the ratio of new paths to existing storage paths, other concurrent system activities and hardware, and so on. Start with only one small and one medium size tablespace, which is followed by a large tablespace. Use your own results as a reference to estimate how long it takes to rebalance each of the remaining tablespaces and schedule the rebalancing process for each tablespace accordingly. TableSpace Size Time Used for Rebalance 41.7GB 4 hour 26 min 4.0 GB 24 min 2009 SAP AG 9

10 3.2 Removing Storage Paths Procedure In following example, the current database has four storage paths: sapdata5, sapdata6, sapdata7, and sapdata8. Storage path sapdata5 and sapdata6 are going to be removed from the database as follows: 1. Take a tablespace snapshot and run db2pd to keep a record of the starting status. db2pd d AX4 -storagepaths Database Partition 0 -- Database AX4 -- Active -- Up 5 days 18:35:51 Database Storage Paths: Number of Storage Paths 4 Address PathID PathState PathName 0x CB20 0 InUse /db2/ax4/sapdata5 0x C840 1 InUse /db2/ax4/sapdata6 0x D8EE5C0 4 InUse /db2/ax4/sapdata7 0x D81F560 5 InUse /db2/ax4/sapdata8 2. Drop the storage paths with following ALTER DATABASE statement: ALTER DATABASE DROP STORAGE ON <Path1>,<Path2>,...,<Pathn>] Here is an example: alter database drop storage on '/db2/ax4/sapdata5', '/db2/ax4/sapdata6' Note: This action puts the mentioned storage paths in a drop pending state. Path(s) are not removed until all data on these storage paths are moved to other paths. To check the Pathstate column of all 4 storage paths, run db2pd SAP AG 10

11 db2pd d AX4 storagepaths Database Partition 0 -- Database AX4 -- Active -- Up 5 days 18:58:10 Database Storage Paths: Number of Storage Paths 4 Address PathID PathState PathName 0x CB20 0 DropPending /db2/ax4/sapdata5 0x C840 1 DropPending /db2/ax4/sapdata6 0x D8EE5C0 4 InUse /db2/ax4/sapdata7 0x D81F560 5 InUse /db2/ax4/sapdata8 3. Identify all of the affected non temporary tablespaces that might have containers on the drop pending storage paths. You can either do this manually by scanning the output of the tablespace snapshot or by using an SQL statement. The following SQL statement generates a list of all the regular and large automatic storage tablespaces that have containers residing on a "Drop Pending" path: SELECT DISTINCT A.TBSP_NAME FROM SYSIBMADM.SNAPTBSP A, SYSIBMADM.SNAPTBSP_PART B WHERE A.TBSP_ID = B.TBSP_ID AND A.TBSP_CONTENT_TYPE IN ('ANY','LARGE') AND B.TBSP_PATHS_DROPPED = 1 4. Rebalance all the tablespaces identified in step 3. To rebalance a table space, issue the following statement: ALTER TABLESPACE <TablespaceName> REBALANCE; Rebalancing these tablespaces moves the permanent data off the containers on the drop pending paths onto the remaining storage paths and then the empty containers are dropped. Note: The rebalancing process might have significant performance impact on your system. Before starting the rebalancing process for any tablespace, see section 3.4 Rebalance the table spaces for more information. It is important that you carefully plan when, how and which tablespace should be rebalanced at a certain point in time. 5. Identify all affected temporary tablespaces. To determine the list of affected temporary table spaces, you can manually scan a tablespace snapshot output or you can execute a SQL statement. The following SQL statement generates a list of all the system temporary and user temporary automatic storage tablespaces in a database that have containers residing on a "Drop Pending" path: SELECT DISTINCT A.TBSP_NAME FROM SYSIBMADM.SNAPTBSP A, SYSIBMADM.SNAPTBSP_PART B WHERE A.TBSP_ID = B.TBSP_ID AND A.TBSP_CONTENT_TYPE IN ('USRTEMP','SYSTEMP') AND B.TBSP_PATHS_DROPPED= SAP AG 11

12 6. Move temporary tablespace off all Drop Pending paths if any exists In a standard SAP system database, there are two SMS temporary tablespaces: PSAPTEMP16 and SYSTOOLSTMPSPACE. If one of them has containers on the drop pending paths, you can either stop (deactivate) and start (activate) the database, which results in the containers being redefined. Alternatively, you can rename the existing temporary tablespace, re-create it on the correct paths and then drop the old temporary tablespace. The following is an example script that you can use to rename and re-create the tablespace. First, run the script recreate_tmptbs.sql and then runt the script drop_oldtmp.sql. Content of recreate_tmptbs.sql: rename tablespace PSAPTEMP16 to oldtemp16; rename tablespace SYSTOOLSTMPSPACE to oldtoolstmpspace; create temporary tablespace PSAPTEMP16 in nodegroup IBMTEMPGROUP pagesize 16k extentsize 2 prefetchsize automatic no file system caching dropped table recovery off; create user temporary tablespace SYSTOOLSTMPSPACE in nodegroup IBMCATGROUP pagesize 16k extentsize 2 prefetchsize automatic Content of drop_oldtmp.sql drop tablespace oldtemp16; drop tablespace oldtoolstmpspace ; Note: If you were not able to drop one of your old temporary tablespaces, it might still be used. Try to drop it at a later time SAP AG 12

13 7. Confirm that the dropped storage paths are no longer listed. Once there are no tablespaces actively using the storage path that were dropped, the paths are immediately removed from the database. To check, run db2pd again. saplp4: db2ax4>db2pd d AX4 -storagepaths Database Partition 0 -- Database AX4 -- Active -- Up 6 days 10:10:33 Database Storage Paths: Number of Storage Paths 2 Address PathID PathState PathName 0x D8EE5C0 4 InUse /db2/ax4/sapdata7 0x D81F560 5 InUse /db2/ax4/sapdata8 Note: If at this step, the paths to be dropped are still listed as Drop pending, then one or more tablespaces are still using it. In this case, repeat step 3 to step 6 to remove all the data from drop pending paths Performance Data The following describes how performance data is collected for our scenario. While the rebalancing process was running, there were not many other concurrent activities on the database system. The time needed to rebalance a tablespace with a similar size on your system might vary in your particular environment. This will be affected by the file system layout, ratio of new paths to existing storage paths, other concurrent system activities and hardware, and so on. Start with only one small and one medium size tablespace, which is then followed by a large tablespace. Use your own results as a reference to estimate how long it takes to rebalance each of the remaining tablespaces and schedule the rebalancing process for each tablespace accordingly. Tablespace Size Time Used for Rebalance 41.7 GB 7 hour 5 min 4.0 GB 41 min 2009 SAP AG 13

14 3.3 Adding and Removing Storage Paths at the Same Time Procedure You can add and drop storage path from the database using a single ALTER DATABASE statement or using multiple ALTER DATABASE statements that you issue at different points in time. To use a single SQL statement, enter the following: ALTER DATABASE ADD STORAGE ON <newpath1> [<newpath2> ] DROP STORAGE ON <existingpath1> [,<existingpath2>, ] Here is an example: alter database add storage on '/db2/ax4/sapdata3' drop '/db2/ax4/sapdata8'; The rest of the procedure is the same as described in section 3.2 Removing Storage Paths. However, there is one difference that you have to be aware of: when you identify all the tablespaces for rebalancing, you need to include all regular and large automatic storage tablespaces instead of only the tablespaces residing on the Drop pending paths. The following SQL statement generates a list of all regular and large automatic storage tablespaces in the database: SELECT DISTINCT TBSP_ID, TBSP_NAME FROM SYSIBMADM.SNAPTBSP WHERE TBSP_USING_AUTO_STORAGE = 1 AND TBSP_CONTENT_TYPE IN ('ANY','LARGE') ORDER BY TBSP_ID Performance Data The following describes how performance data is collected for our test scenario. The database started with two storage paths, a new path was added and an existing one was dropped. While the rebalancing process was running, there were not many other concurrent activities on the system. The time needed to rebalance a tablespace with a similar size on your system might vary in your particular environment. This will be affected by the file system layout, ratio of new paths to existing storage paths, other concurrent system activities and hardware, and so on. Start with only one small and one medium size tablespace, which is then followed by a large tablespace. Use your own results as a reference to estimate how long it takes to rebalance each of the remaining tablespaces and schedule the rebalancing process for each tablespace accordingly. Tablespace Size Time Used for Rebalance 41.7 GB 4 hour 27 min 4.0 GB 43 min 2009 SAP AG 14

15 3.4 Rebalancing Tablespaces Rebalance the Tablespaces Once you have identified the tablespaces, the next step is to run the following statement for each of the listed tablespaces. Provided that there is sufficient space on the storage paths, it should not matter in what sequence the rebalances are performed. You can rebalance one tablespace at a time or a group of tablespaces in parallel. However, rebalancing has an impact of the performance of your system. Avoid rebalancing during system peak times and consider rebalancing really large tablespaces in smaller groups or individually. Alternatively, you could also use the throttling utility to limit the performance impact of rebalancing on your system. For more information, see section Throttling the Rebalance Process. To rebalance a tablespace, issue the following SQL statement: ALTER TABLESPACE <TablespaceName> REBALANCE; Here is an example: Alter tablespace AX4#ES700D rebalance; It can be seen in the output of this command that the rebalancing job runs asynchronous in the background and does not affect the availability of the data SAP AG 15

16 3.4.2 Monitor the Status of the Rebalancing Process To monitor the status, you could either run the db2list utilities show detail or take a tablespace snapshot. Db2 list utilities show detail Here is an example output: ID = 6219 Type Database Name = REBALANCE = AX4 Partition Number = 0 Description = Tablespace ID: 37 Start Time = 04/27/ :37: State Invocation Type = Executing = User Throttling: Priority = Unthrottled Progress Monitoring: Estimated Percentage Complete = 15 Total Work Completed Work = extents = 3318 extents Start Time = 04/27/ :37: ID = 6216 Type Database Name = REBALANCE = AX4 Partition Number = 0 Description = Tablespace ID: 36 Start Time = 04/27/ :37: State Invocation Type = Executing = User Throttling: Priority = Unthrottled Progress Monitoring: Estimated Percentage Complete = 4 Total Work Completed Work = extents = 4404 extents Start Time = 04/27/ :37: In example above, the tablespaces with ID 37 and 36 are still being rebalanced SAP AG 16

17 As soon as the tablespace has been rebalanced, the Rebalancer Mode in the tablespace snapshot for this tablespace shows No Rebalancing. Otherwise, you see DMS rebalancer is active for that tablespace in the tablespace snapshot. In the following example, tablespace < SYSCATSPACE > has only one stripe set in the table space map after having been rebalanced: Tablespace name Rebalancer Mode = SYSCATSPACE = No Rebalancing Number of containers = 2 Container Name = /db2/ax4/sapdata7/db2ax4/node0000/ax4/t /c cat Container Name = /db2/ax4/sapdata8/db2ax4/node0000/ax4/t /c cat Table space map: Range Stripe Stripe Max Max Start End Adj. Containers Number Set Offset Extent Page Stripe Stripe [ 0] [ 0] (0,1) The rebalancing process is logged in the db2diag.log. You can calculate the time used to rebalance a tablespace based on these log entries: E1342A392 LEVEL: Info PID : TID : 4379 PROC : db2sysc 0 INSTANCE : db2ax4 NODE : 000 EDUID : 4379 EDUNAME: db2rebal (AX4) 0 FUNCTION MESSAGE : DB2 UDB, buffer pool services, sqlb_rev_rebalance, probe:10 : ADM6058I Rebalancer for table space "AX4#ES700I" (ID "21") was started E6339A396 LEVEL: Info PID : TID : 4379 PROC : db2sysc 0 INSTANCE : db2ax4 NODE : 000 EDUID : 4379 EDUNAME : db2rebal (AX4) 0 FUNCTION MESSAGE : DB2 UDB, buffer pool services, sqlb_rebalance, probe:2876 : ADM6062I Rebalance for table space "AX4#ES700I" (ID "21") has been completed SAP AG 17

18 3.4.3 Throttling the Rebalancing Process (Optional) The database manager configuration parameter util_impact_lim sets the limit on the impact that throttled utilities can have on the overall workload of the machine. By default, parameter util_impact_lim is set to 10, which means all utilities combined can have no more than an impact of 10% average on the total workload as judged by the throttling algorithm. Value 100 indicates no throttling. To run in throttled mode, a utility must also be invoked with a non zero priority. You could use the SET UTIL_IMPACT_PRIORITY command to throttle a tablespace rebalancing process. To do so, you need to obtain the utility ID with the LIST UTILITIES command and to set the priority to a value. Here is the command: SET UTIL_IMPACT_PRIORITY FOR <utility_id> TO <priority>; 2009 SAP AG 18

19 Here is an example: augsburg2:db2ax4 68> db2 list utilities show detail ID = 4 Type Database Name = REBALANCE = AX4 Partition Number = 0 Description = Tablespace ID: 0 Start Time = 05/28/ :43: State Invocation Type = Executing = User Throttling: Priority = Unthrottled Progress Monitoring: Estimated Percentage Complete = 8 Total Work Completed Work = extents = 3884 extents Start Time = 05/28/ :43: augsburg2:db2ax4 69> db2 set UTIL_IMPACT_PRIORITY FOR 4 to 50 DB20000I The SET UTIL_IMPACT_PRIORITY command completed successfully. augsburg2:db2ax4 70> db2 list utilities show detail ID = 4 Type Database Name = REBALANCE = AX4 Partition Number = 0 Description = Tablespace ID: 0 Start Time = 05/28/ :43: State Invocation Type = Executing = User Throttling: Priority = 50 Progress Monitoring: Estimated Percentage Complete = 17 Total Work Completed Work = extents = 8150 extents Start Time = 05/28/ :43: SAP AG 19

20 4 Other Considerations In a partitioned database environment, consider the following: If you add more storage paths to the database, the same set of storage paths must be used on each database partition (unless database partition expression is used). If the specified path does not exist on every database partition, the statement is rolled back. If you remove a storage path from the database, the path is maintained independently on each partition. Once a Drop Pending path is no longer in use on a given database partition, it is removed physically from that partition. On other partitions, it might still show the path as being in "Drop Pending" state. You have to issue the rebalancing command on every partition. If a storage path is added to a database multiple times, you also to be aware of the following: You can add a given storage path to a database multiple times. This will result in multiple containers on that path. If you are using the DROP STORAGE ON clause, specifying that particular path once drops all instances of the path from the database SAP AG 20

21 5 Related Content For more information, see the SAP on DB2 for Linux, UNIX, and Windows Web page in the SAP Community Network. For more information, visit the Landscape Design and Architecture homepage SAP AG 21

22 Disclaimer and Liability Notice This document may discuss sample coding or other information that does not include SAP official interfaces and therefore is not supported by SAP. Changes made based on this information are not supported and can be overwritten during an upgrade. SAP will not be held liable for any damages caused by using or misusing the information, code or methods suggested in this document, and anyone using these methods does so at his/her own risk. SAP offers no guarantees and assumes no responsibility or liability of any type with respect to the content of this technical article or code sample, including any liability resulting from incompatibility between the content within this document and the materials and services offered by SAP. You agree that you will not hold, or seek to hold, SAP responsible or liable with respect to the content of this document SAP AG 22