1. 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

2. 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

3. 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

4. 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

5. 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

6. 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. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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