SAP Sybase Adaptive Server Enterprise Shrinking a Database for Storage Optimization 2013

SAP Sybase Adaptive Server Enterprise Shrinking a Database for Storage Optimization 2013

TABLE OF CONTENTS Introduction... 3 SAP Sybase ASE s techniques to shrink unused space... 3 Shrinking the Transaction Log... 4 Shrinking the database... 4 Special Considerations... 5 Summary... 7

Introduction In today s fast-paced and knowledge-based economy organizations are striving to provide customers with better products and services, optimize their operations while trying to efficiently and intelligently manage the ever-growing data. Traditional database growth has been attributed to various factors which include indexes that are built in the database, backups that are taken as well as new compliance requirements such as Sarbanes Oxley and HIPAA that warrant the need for retaining historical data. All these as well as specific activities like select into, alter table, parallel create index and other commands may require extra log space which may have to be added as and when necessary. Once these triggering events are done, the extra allocated space may well become a wasted resource as well as a source of IO bottlenecks causing performance problems which present an operational challenge to ensure business critical information is made available continuously and efficiently. Although the burden of providing sufficient storage to keep up with the growing data lies in the hands of the IT personnel, DBAs have equal responsibility in making sure the queries run fast and the database is well designed and tuned by ensuring data is spread across different disk devices efficiently and there are less storage related bottlenecks and issues. SAP Sybase Adaptive Server Enterprise SP100 (SAP Sybase ASE SP100) offers a distinct advantage for handling this disk space usage efficiently. Shrink database functionality from SAP Sybase ASE helps in optimizing disk storage use by the database while providing improved cost of operations and efficient data handling for better query performance. SAP Sybase ASE s techniques to shrink unused space SAP Sybase ASE provides several methods of optimizing disk space, of which this paper will discuss the database shrinking techniques that lead to cost savings. The shrinking techniques that ASE uses are: - Shrinking the transaction log - Shrinking the database

Shrinking the Transaction Log ASE 15.7 and later releases provide the ability to shrink the transaction log allowing customers to shrink the log space without having to recreate the database. ASE extends the alter database command to let system administrators and database owners remove unwanted portions of a database log freeing that storage space. During the execution, the command will be able to detect if there is sufficient space to permit removing a log fragment. Internally, ASE remaps the storage within the database as necessary to accommodate the request to shrink the log and the database s logical storage map in the system table sysusages will be updated to reflect the changes. ASE has introduced a new parameter to the alter database command called log off to remove the unwanted portions of the database log allowing shrinking of the log space to free storage. This feature can be used by anyone who needs to reduce the size of the log segment because it was accidentally created too large or following a deliberate but temporary increase in the size of the log in order to accommodate a particular operation. Shrinking the database ASE 15.7 SP100 and later releases allows shrinking of a database which frees up unused space for reuse and / or deletion. Shrinking a database refers to removing physical storage from the database. This is accomplished by disassociating logical storage from physical storage in identified areas of the database. Any existing data will be moved to a new location as needed so that the space to be released is free of data. ASE then uses the alter database command to perform the shrink database operation. This work can be done while the database is online and is in use. There is no need for any special access restrictions although there will be short periods of time when the operation requires exclusive access to a table. Any user with sa_role privilege or the database owner (DBO) will be able to execute this shrink database operation. An example of a shrink database operation is given below: alter database demodb OFF dbdev2 Here, OFF is the keyword which does the shrink operation and dbdev2 is the device which will be removed off of the database demodb. ASE 15.7 SP100 provides a very convenient and flexible way of executing the shrink database operation. The operation can be executed for a specific period of time and continued at a later point in time. DBAs will appreciate the fact that there is no limit to the number of times the shrink database operation can be restarted. The ability to restart a shrink operation does not survive a reboot. The state information needed for restart of the operation is not written to permanent storage but is kept in memory. If ASE shuts down before a shrink operation completes, with resume_shrink will not work and the user will have to issue a new alter database command to do the remaining shrink database operation. An example of the shrink database operation with the resume_shrink option is given below: alter database demodb OFF dbdev2 with resume_shrink

Where with resume_shrink indicates that the shrink database operation is being resumed from where it stopped previously. Shrink database works in small increments. It works on one source allocation unit at a time, and begins a new transaction for each object it finds on that allocation unit. To perform this move, ASE exchanges blocks of pages read from disk, then exchanges those blocks virtual page numbers in the disk map. While it is working on one object s pages, it takes an exclusive table lock on that object. Thus, it begins and ends a lot of small transactions, and takes and drops a lot of short-duration blocking locks. At most, each transaction and each lock will persist for processing 255 pages. Although it is impossible to say definitively how any one such operation will impact performance, internal tests have shown that these transactions and locks last far less than 1 second each. It is fair to say that the performance impact of shrink operations on other processing will normally not be noticeable. If the shrink command has not completed after the specified time has elapsed, it abandons the work in progress. Any completed work remains done, but the command exits with a suitable message. In case of a server crash while page exchange is under way, ASE will attempt to restart the exchange upon reboot. Special Considerations Temporary databases present a special class of problem for shrinking. They are used as a cache for tables having no permanent identity, which persist only for the duration of a single query and have no entries in the catalogs describing database objects. For this reason, shrinking a temporary database can only be done when ASE is booted in single-user mode. Duplicate keys in indexes can potentially cause a new set of issues for the shrink operation. In an index, each row s location in the database is stored as a row ID. When the index is not unique, one key may represent more than one row ID and each of these row ID s are sorted and these entire row ID s are maintained as a list so that lookups through the index are faster. When there is a table that has one or many non-unique indexes defined with many duplicate key values, any update to the data row ID will end up with ASE needing to ensure that the entire row ID s are re-sorted and placed in the correct order before that index can be made available to the users. The drawback to this step of re-sorting is that it is a slow operation and as a result the table is locked until the process is completed thus affecting performance. Also, since shrink database works in smaller chunks of 255 pages, if the table is a significantly large table, performing the shrink database operation in smaller chunks of time may cause the table to be locked multiple times depending on how many smaller chunks the operation has been divided. Although this is not guaranteed to happen during all shrink database operations, there is a possibility that sometimes access to parts of the database can be unexpectedly blocked while the resorting of the index entries are happening resulting in unwanted performance delays. SAP is looking at providing a new tool in a future release which will help the user understand their environment better and make educated decisions before starting the shrink database operation. This

tool which should act like an advisor will have the capability to evaluate the table schema and determine if there are any indexes which might cause performance degradation while doing the shrink database operation. If there are such indexes, the advisor will suggest that the indexes are dropped before the shrink database operation and recreated after the completion of shrink database.

Summary Traditionally, it has been observed that the database size is increasing not only due to the new compliance requirements such as Sarbanes Oxley and HIPAA that warrant historical data but also due to the other requirements such as backups as well as indexes that are built on the database. And with the fluctuating economy, storage systems especially the disk-based ones are becoming the most expensive set of components in a database environment. The storage optimization techniques used by SAP Sybase to shrink unused space offers the enterprise a very clear and distinct advantage for handling this increasing volume of data. These techniques help in reducing the overall cost of operations while at the same time catering to improved total cost of ownership which is one of the challenges when managing large data sets.

www.sap.com 2013 SAP AG. All rights reserved. SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and Adaptive Server, ianywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company. Crossgate, m@gic EDDY, B2B 360, and B2B 360 Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary. These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty..