Lab 6: Tuning & Optimization

1 Overview
Essbase BSO tuning can take two forms: tuning for batch processing (to prepare the database for access by clients) and tuning the database to support client retrieval requirements. The objective of tuning for batch processing is to minimize the time to calculate the database. Tuning to support client requirements acknowledges that multi-user environments can have different memory configuration requirements (cache and buffer settings) and may even have implications that necessitate altering database configuration (dense/sparse settings). BSO tuning should be in no significant way different than relational database tuning. In these environments tuning essentially requires an in-depth understanding of the database storage structures, user query requirements, and how both interface with hardware infrastructure. Essbase ASO tuning is more limited than in BSO, but can be just as critical for the proper performance of your database. ASO tuning takes on the form of outline, query and cache optimizations.

2 BSO Tuning and Optimization

1. In the Administration Services Console, right-click on the second TBC and select Edit | Properties.

2. Go to the Dimensions folder, notice the Members in Dimension column shows that this outline conforms to the hourglass shape.

1 Lab 6: Tuning & Optimization

3. Next, go to the Statistics folder. Notice that the Block size is well within the recommended limit of 100K.

4. To see how the dense/sparse settings affect Block size, change the setting for the SCENARIO dimension from sparse to dense. Open the TBC outline by double-clicking Outline below the second TBC.

2 Lab 6: Tuning & Optimization

5. In the Properties tab, under Data Storage Dimension storage types, click on the dropdown next to SCENARIO and select Dense.

Click Save.

3 Lab 6: Tuning & Optimization

Verify that All data is selected and click OK.

Return to TBC | Properties. The Block size tripled because there are three stored members in the SCENARIO dimension.

4 Lab 6: Tuning & Optimization

6. You probably did not notice that the TBC database performed a restructure when you saved it. There are two types of restructures in Essbase BSO: sparse and dense. Sparse restructures are the least expensive as they only require a restructuring of the ESS*.IND files. These occur when you make some changes to only the sparse dimensions such as editing the hierarchies or adding/deleting members. Dense restructures occur when changes are made to the dense dimensions because the fundamental structure of the blocks, and thus the cube itself, changes. When you changed one dimension from sparse to dense, it grew the size of the blocks. Restructuring of the cube is recommended for read/write applications on a periodic basis. This is due to fragmentation of the database as changes in the data occur over time. Before starting the restructure, split your screen so that the Linux VM is showing on one side and EAS on the other. Open up the File Browser in the VM and navigate to /software/hyperion/products/Essbase/ EssbaseServer/app/TBC/TBC. In EAS, right-click on the second TBC and select Restructure. Click OK to start the restructure.

5 Lab 6: Tuning & Optimization

During the restructure, notice that the ESS*.IND and ESS*.PAG files are replicated to temporary files with the extensions INN and PAN (because of the small size of the database, they will only appear briefly). The restructure creates these temporary files in the event of system crashes for rollback purposes as restructures can take a long time to complete depending on the size of the cube and what changes were made. This is important from a disk storage perspective as well, since free disk space is required to handle two sets of ESS*.IND and ESS*.PAG files or else the restructure will not complete.

6 Lab 6: Tuning & Optimization

7. Return to TBC | Properties and go to the Caches tab. Change the Index cache setting so that it takes the entire ESS*.IND file (about 8MB). Click Apply. Since the ESS*.PAG file is small, you can leave the Data cache as it is.

Click OK when you have successfully updated the caches.

7 Lab 6: Tuning & Optimization

3 ASO Tuning and Optimization

1. As aggregate storage outline files (.otl files) are changed, they may increase in size. By compacting such files, you can remove the records of deleted members and thus reduce file size. In the Administration Services Console, right-click on Outline after the second TBC_ASO and select Compact.

Click OK to start compaction of the outline.

Click OK when compaction completed successfully.

8 Lab 6: Tuning & Optimization

2. Next, we will see how Aggregate Views can help speed queries for an ASO database. Open the Lab_Queries.xls file from the In Class Files folder and select tab Lab 3.2. Connect to TBC_ASO/TBC_ASO using the Essbase add-in or Smartview and refresh the data. Disconnect from TBC_ASO (close the Excel file or select Essbase | Disconnect).

3. In the EAS console, right-click on the first TBC_ASO and select View | Log.

9 Lab 6: Tuning & Optimization

Select Display log and click OK.

Scroll to the bottom of the log and look for the last Spreadsheet Extractor Elapsed Time: [x.xx] seconds line. Note the time it took to complete your last Excel Add-in query.

4. In the EAS console, right-click on the second TBC_ASO and select Design aggregation to run the Aggregation Design Wizard.

Select Design, materialize and save aggregation and click Next.

10 Lab 6: Tuning & Optimization

5. Select Replace existing aggregate view selection and click Next.

6. Select Select all recommended aggregate views and click Next.

11 Lab 6: Tuning & Optimization

7. Click Start to run the analysis.

When the process completes, click OK.

8. A list of the suggested Aggregate Views appear. The chart shows how much disk space the Aggregate Views will take up and how much the query cost will improve by. Notice that there will be a huge drop in the query cost with the first Aggregate View, but much smaller incremental improvements with each successive one. Since the impact on disk space is minimal, keep all the Aggregate Views checked and click Next.

12 Lab 6: Tuning & Optimization

9. Select Materialize aggregation and click Next. Since this is the first time running the wizard, you do not have to check Replace existing aggregation.

10. Once the Aggregate Views are completed, click Finish.

11. You will now need to stop and restart the application in order to clear the cache and re-run the earlier query. Right-click on the first TBC_ASO and select Stop | Application.

Click Yes to stop the application.

13 Lab 6: Tuning & Optimization

Right-click on the first TBC_ASO and select Start | Application.

Click Yes to start the application.

12. Re-connect to TBC_ASO/TBC_ASO (open Lab_Queries.xls file and select the Lab 3.2 tab if the file was closed) and Retrieve the data. 13. Open the log file again. First, right-click on TBC_ASO and select View | Log.

Select Display log and click OK.

Scroll to the bottom of the log and look for the last Spreadsheet Extractor Elapsed Time: [x.xx] seconds line. Note the time it took to complete this query. Compare this with the earlier time that you had. Was there any improvement?

14 Lab 6: Tuning & Optimization