What are types of data compression?
Essbase provides several options for data compression:
1. Bitmap compression, the default. Essbase stores only non-missing values and
uses a bitmapping scheme. A bitmap uses one bit for each cell in the data block, whether the cell value is missing or non-missing. When a data block is not compressed, Essbase uses 8 bytes to store every non-missing cell. In most cases, bitmap compression conserves disk space more efficiently. However, much depends on the configuration of the data.
2. Run-length encoding (RLE). Essbase compresses repetitive, consecutive values --any value that repeats three or more times consecutively, including zeros and #MISSING values. Each data value that is repeated three or more times uses 8 bytes plus a 16 byte repetition factor.
3. zlib compression. Essbase builds a data dictionary based on the actual data being compressed. This method is used in packages like PNG, Zip, and gzip. Generally, the more dense or heterogeneous the data is, the better zlib will compress it in comparison to bitmap or RLE compression.
4. Index Value Pair compression. Essbase applies this compression if the block density is less than 3%.Index Value Pair addresses compression on databases with larger block sizes, where the blocks are highly sparse. zlib does not use this.
5. No compression. Essbase does not compress data blocks when they are written to disk
When do you use RLE over Bitmap Compression?
Use RLE over Bitmap When,
Average block density very low (< 3%).
Database has many consecutive repeating Values.
When do you disable compression?
You may want to disable data compression if blocks have very high density (90% or greater) and have few consecutive, repeating data values. Under these conditions, enabling compression consumes resources unnecessarily. Don't use compression if disc space/memory is not an issue compared to your application. It can become a drain on the processor.
What are data locks?
Essbase issues write (exclusive) locks for blocks that are created, updated, or deleted, and issues read (shared) locks for blocks that should be accessed but not modified. By issuing the appropriate locks, Essbase ensures that data changed by one operation cannot be corrupted by a concurrent update.
What are the memory caches used by Essbase to coordinate memory usage? Essbase uses five memory caches to coordinate memory usage 1. Index Cache 2. Data File Cache 3. Data Cache 4. Calculator Cache 5. Dynamic Calculator Cache
What is Index cache?
The index cache is a buffer in memory that holds index pages. How many index pages are in memory at one time depends upon the amount of memory allocated to the cache.
What is Data file cache?
The data file cache is a buffer in memory that holds compressed data files (.pag files). Essbase allocates memory to the data file cache during data load, calculation, and retrieval operations, as needed. The data file cache is used only when direct I/O is in effect.
What is Data cache?
The data cache is a buffer in memory that holds uncompressed data blocks. Essbase allocates memory to the data cache during data load, calculation, and retrieval operations, as needed.
What is Calculator cache?
The calculator cache is a buffer in memory that Essbase uses to create and track data blocks during calculation operations.
What is Dynamic calculator cache?
The dynamic calculator cache is a buffer in memory that Essbase uses to store all of the blocks needed for a calculation of a Dynamic Calc member in a dense dimension (for example, for a query).
What are the memory caches used by Essbase to coordinate memory usage?
Essbase uses five memory caches to coordinate memory usage
Index Cache: Min -1024 KB (1048576 bytes) Default - Buffered I/O : 1024 KB (1048576 bytes);Direct I/O : 10240 KB (10485760 bytes) Opt -Combined size of all essn.ind files, if possible; as large as possible otherwise.Do not set this cache size higher than the total index size, as no performance improvement results.
Data File Cache: Min - Direct I/O: 10240 KB(10485760 bytes) Default -Direct I/O: 32768 KB(33554432 bytes) Opt -Combined size of allessn.pag files, if possible; otherwise as large as possible.This cache setting not used if Essbase is set to use buffered I/O.
Data Cache:Min - 3072 KB (3145728 bytes) Default - 3072 KB (3145728 bytes) Opt -0.125 * the value of data file cache size.
Calculator Cache:Min - 4 bytes Max: 200,000,000 bytes Default - 200,000 bytes Opt -The best size for the calculator cache depends on the number and density of the sparse dimensions in your outline. The optimum size of the calculator cache depends on the amount of memory the system has available.
What is the structure of currency applications?
In a business application requiring currency conversion, the main database is divided into at least two slices. One slice handles input of the local data, and another slice holds a copy of the input data converted to a common currency.
Essbase holds the exchange rates required for currency conversion in a separate currency database. The currency database outline, which is automatically generated by Essbase from the main database after you assign the necessary tags, typically maps a given conversion ratio onto a section of the main database. After the currency database is generated, it can be edited just like any other Essbase database.
What are the three dimension that should be present in main database of currency application?
The main database outline can contain from 3 to n dimensions. At a minimum, the main database must contain the following dimensions:
· A dimension tagged as time.
· A dimension tagged as accounts.
· A market-related dimension tagged as country.
A currency database always consists of the following three dimensions, with an optional fourth dimension:
· A dimension tagged as time, which is typically the same as the dimension tagged as time in the main database.
· A dimension tagged as country, which contains the names of currencies relevant to the markets (or countries) defined in the main database.
· A dimension tagged as accounts, which enables the application of various rates to members of the dimension tagged as accounts in the main database.
· A currency database, which typically includes an optional currency type dimension, which enables different scenarios for currency conversion.
What are the conversion methods supported by Essbase for currency applications?
Different currency applications have different conversion requirements. Essbase supports two conversion methods:
· Overwriting local values with converted values.
· Keeping local and converted values.
Either of these two methods may require a currency conversion to be applied at report time. Report time conversion enables analysis of various exchange rate scenarios without actually storing data in the database.What is the process to build a currency conversion application and perform conversions?
To build a currency conversion application and perform conversions, use the following process:
1. Create or open the main database outline. 2. Prepare the main database outline for currency conversion. 3. Generate the currency database outline. 4. Link the main and currency databases. 5. Convert currency values. 6. Track currency conversions. 7. If necessary, troubleshoot currency conversion.
What is CCONV? After you create a currency conversion application, you convert data values from a local currency to a common, converted currency by using the CCONV command in calculation scripts Ex: CCONV USD;CALC ALL;
Can we convert the converted currency back into its local currency? You can convert the data values back to the original, local currencies by using the CCONV TOLOCALRATE command.
When you convert currencies using the CCONV command, are the resulting data blocks are marked as dirty or clean? When you convert currencies using the CCONV command, the resulting data blocks are marked as dirty for the purposes of Intelligent Calculation. Thus, Essbase recalculates all converted blocks when you recalculate the database.
What is CCTRACK? You can use the CCTRACK setting in the essbase.cfg file to control whether Essbase tracks the currency partitions that have been converted and the exchange rates that have been used for the conversions. By default CCTRACK is turned on.
What are the reasons to turn off CCTRACK? For increased efficiency when converting currency data between currency partitions, you may want to turn off CCTRACK. For example, you load data for the current month into the local partition, use the DATACOPY command to copy the entire currency partition that contains the updated data, and then run the conversion on the currency partition.
How can you turn off CCTRACK? You can turn off CCTRACK in three ways: · Use the SET CCTRACKCALC ONOFF command in a calculation script to turn off CCTRACK temporarily · Use the CLEARCCTRACK calculation command to clear the internal exchange rate tables created by CCTRACK.
Set CCTRACK to FALSE in the essbase.cfg file.
What is LRO (Linked reporting objects)? An LRO is an artifact associated with a specific data cell in an Essbase database. LROs can enhance data analysis capabilities by providing additional information on a cell.
An LRO can be any of the following:
· A paragraph of descriptive text (a "cell note")
· A separate file that contains text, audio, video, or graphics
· A URL for a Web site
· A link to data in another Essbase database
How do you create LRO's?
Users create linked objects through Essbase Spreadsheet Add-in for Excel by selecting a data cell and choosing a menu item. There is no limit to the number of objects you can link to a cell. The objects are stored on the Essbase Server where they are available to any user with the appropriate access permissions. Users retrieve and edit the objects through the Essbase Spreadsheet Add-in for Excel Linked Objects Browser feature, enabling them to view objects linked to the selected cell.
Does adding or removing links to a cell does not affect the cell contents?
No.LROs are linked to data cells --not to the data contained in the cells. The link is based on a specific member combination in the database.
Give a few examples of LRO's?
Ex1: A sales manager may attach cell notes to recently updated budget items. Ex2: A finance manager might link a spreadsheet containing supporting data for this quarter's results. Ex3: A product manager might link bitmap images of new products. Ex4: A sales manager may link the URL of a company's Web site to quickly access the info on the Web
How does Essbase locate and retrieve linked objects?
Essbase uses the database index to locate and retrieve linked objects. If you clear all data values from a database, the index is deleted and so are the links to linked objects. If you restructure a database, the index is preserved and so are the links to linked objects.
Do shared members share LRO's?
Shared members share data values but do not share LROs. This is because LROs are linked to specific member combinations and shared members do not have identical member combinations. To link a given object to shared members, link it to each shared member individually.
Can you change the member combination associated with any linked object?
You cannot change the member combination associated with any linked object. To move an object to another member combination, first delete it, then use Essbase Spreadsheet Addin for Excel to re-link the object to the desired member combination.
Why do we need to limit the LRO file sizes for storage conversion?
Because Essbase stores linked files in a repository on the server and, by default, the size is unlimited. Limiting the file size prevents users from taking up too much of the server resources by storing extremely large objects. You can set the maximum linked file size for each application. If a user attempts to link a file that is larger than the limit, an error message displays.
The maximum file size setting applies only to linked files and does not affect cell notes or URLs. The lengths of the cell note, URL string, and LRO descriptions are fixed.
What is partitioning?
A partition is the piece of a database that is shared with another database. An Essbase partitioned application can span multiple servers, processors, or computers.
What is Essbase Partitioning?
Essbase Partitioning is a collection of features that makes it easy to design and administer databases that span Essbase applications or servers. Partitioning is licensed separately from Essbase.
What are the types of Partitions available in Essbase?
Three types of partitions are there.
1. Transparent partition:
A form of shared partition that provides the ability to access and manipulate remote data transparently as though it is part of your local database. The remote data is retrieved from the data source each time you request it. Any updates made to the data are written back to the data source and become immediately accessible to both local data target users and transparent data source users
2. Replicated Partition:
A portion of a database, defined through Partition Manager, used to propagate an update to data mastered at one site to a copy of data stored at another site. Users can access the data as though it were part of their local database.
3. Linked Partition:
A shared partition that enables you to use a data cell to link two databases. When a user clicks a linked cell in a worksheet, Essbase opens a new sheet displaying the dimensions in the linked database. The user can then drill down those dimensions.
What is the process for designing a partitioned database?
Here is the suggested process for designing a partitioned database.
1. Learn about partitions.
2. Determine whether the database can benefit from partitioning.
3. Identify the data to partition.
4. Decide on the type of partition.
5. Understand the security issues related to partitions.
What are the parts of partition?
Partitions contain the following parts,
· Type of partition: A flag indicating whether the partition is replicated, transparent, or linke
· Data source information: The server, application, and database name of the data source.
· Data target information: The server, application, and database name of the
data target.
· Login and password: The login and password information for the data source and the data target.
· Shared areas: A definition of one or more areas, or sub cubes, shared between the data source and the data target.
· Member mapping information: A description of how the members in the data source map to members in the data target.
· State of the partition: Information about whether the partition is up-to-date and when the partition was last updated.
What are benefits of partitioning?
Partitioning applications can provide the following benefits:
· Improved scalability, reliability, availability, and performance of databases
· Reduced database sizes
· More efficient use of resources
· Data synchronization across multiple databases.
· Outline synchronization across multiple databases.
· Ability for user navigation between databases with differing dimensionality.
No comments:
Post a Comment