Довольно старый документ , но не потерявший своей актуальности на сегодняшний день.
/* У меня есть одно желание – , всех кто осознано использует более одной БД в приложении Planning отправлять к “столбу позора” */
Hyperion Essbase Application Development Note
Design Best Practices
Number of Databases per Application
Hyperion Essbase allows one or more cubes (databases) to be grouped into applications. Due to the flexibility in defining databases to applications, there have been questions as to the optimal number of databases per application. This note is intended to document the recommendation, and reasons thereof.
Design Best Practices Recommendation:
The best practices recommendation is to define only one database per application. The exception is for those applications that take advantage of the Currency Conversion option, which needs to create the conversion rates database in the same application as the database to be converted. The reasons for this one-to-one recommendation are as follows:
1) Memory Utilization. All databases within an application run under that application’s ESSSVR process. A given ESSSVR process can only address from 2 – 3+ GB of memory, depending on the Operating System. Therefore, all databases within that application must ration this memory addressability across the caches that are used, the outlines that are loaded in memory, and other requirements (as documented in the Database Administrators Guide), must share this memory space. This can cause memory swapping, and the need to ration out the memory across the databases in a more deliberate manner. If these databases are within separate applications, you can better take advantage of your hardware resources.
2) Concurrent Dimension Builds. Dimension builds are resource intensive activities that may also require database restructures after they complete. When these databases are within an application, you do not get a full parallelization of these activities, and the additional memory needed for outline restructures (two copies of the outline reside in memory during the restructure) will exacerbate the situation highlighted in item 1 above. Therefore for highly volatile databases with similar batch processing schedules, you would receive better throughput on the system by placing these in separate applications.
3) Single Point of Failure. If many databases are in the same application, and the application is no longer able to be started, you would now have all the contained databases inaccessible until the issue is resolved. This can also happen if one of the databases within the application becomes corrupted. Databases within separate applications are isolated from this event, and therefore impacts are lessened to the users.
4) Load/Unload Databases. The load and unload application features are parallelized via the Essbase Agent. However, the load and unload database are not parallelized within the Essbase Server (ESSSVR) process. Therefore, environments that require loading and loading of databases in concurrence will achieve faster throughput if they are in separate applications, vs. within the same application.
5) Application Settings. The following application settings apply to all databases within the application. (Refer to the Database Administrators Guide for more information on these settings.
- Allow Commands
- Allow Connects
- Allow Updates
- Enable Security
Therefore, if the administrator wishes to switch these settings, they need to be cognizant of the effect it will have on all contained databases. If databases are maintained as a one-to-one with applications, this becomes less of an issue.
6) Database Exports. An Essbase Server (ESSSVR) process can only export one database at a time via the ASCII database export feature. Therefore, if you have multiple databases within an application, you cannot export them in concurrence. If the databases are in different applications (i.e., under different ESSSVR processes), they can be exported in concurrence. Additionally, when the export is being performed, the ESSSVR process rejects other commands until the export is completed. This means that the other databases within the application will not respond to requests until the export is completed.
7) Single Log for Application. Essbase writes information, warning, and error messages for databases into the application log. Each application has its own log. Having multiple databases writing to the same log can cause minimal contention lags, and also make monitoring of logs for specific databases more tedious, if many databases are writing their events to the same log.
8) Если нужно реструктуризировать все кубы , то это можно сделать в параллельном режиме.
Although you can create multiple databases in an application in Essbase, it is only recommended for databases requiring use of the Currency Conversion option, or for databases that do not need additional memory and have non-conflicting maintenance schedules. In all other instances, it is highly recommended that implementations follow a one-to-one mapping of databases and applications.