|
|
This chapter includes the following topics:
This section provides information and recommendations that should help you manage the size and growth of your Analytics database to, which should increase performance. It includes the following topics:
The majority of growth in the Analytics database occurs in the fact tables that are delivered with Analytics. The rest of the delivered Analytics tables -- including dimension tables -- generate negligible growth in the Analytics database. This section provides details on the growth of fact and dimension tables.
Fact tables capture event parameter data of types Date, Integer, and Float. Of the delivered Analytics fact tables, the ASFACT_PAGEVIEWS, ASFACT_PORTLETUSES, and ASFACT_PORTLETVIEWS tables grow at the fastest rate. For this reason, you should closely monitor these tables. For a complete list of delivered fact tables, see Working with Delivered Fact Tables.
Custom events that you create and register using the Event Registration section of Analytics Administration are also stored in fact tables. If you expect any of your custom events to generate large volumes of data (in the range of one million events per year), we recommend that you monitor their tables, and perhaps archive older partitions. For guidelines on archiving and restoring partitions, see Archiving and Restoring Partitions.
Both Oracle and SQL Server databases grow at approximately the same rate: every one million events that are stored in the database use approximately 150 megabytes of disk space. The following table lists numbers of events and their corresponding estimated database sizes.
Use these size estimates to calculate your own database growth requirements. As the number of events in your system continues to grow, query performance ultimately starts to decline. For this reason, in high-volume environments you should monitor the growth of your database and take appropriate measures to prevent performance degradation.
Analytics uses dimensions to capture event parameter data of type String. Dimension tables do not grow as quickly as delivered fact tables because dimension data does not change at nearly the same rate as events occur.
Note that if an object is removed from the application on which Analytics is reporting, the record for that object’s dimension data remains in the Analytics database. For this reason, Analytics continues to report the events that occurred on this object before it was removed from the application.
Portlet views are the most heavily-generated events in the system. For this reason, we recommend that you do not collect portlet view data continuously, which results in tripling the growth rate of your database. Instead, you should only “sample” portlet views periodically. To do this, enable the Capture portlet views/response times option for a limited period of time, such as one or two weeks. You enable this option in Analytics Administration’s Runtime Settings page. For details, see Configuring Runtime Settings.
If you decide to continuously collect portlet view data, you should aggressively archive older data partitions to prevent the database from reaching its capacity too quickly.
Portlet view data is reported on the Portlet Metrics - Views console page. Response time data is reported on the Portlet Metrics - Response Time console page.
To obtain the best performance with Oracle, we recommend that you:
| Note: | Note: The default values in the create_analytics_tablespaces.sql script are acceptable for a development or staging database. You should, however, change these values accordingly in a production environment. |
| Note: | Note: The recommendations in this table are for use with the Analytics database only. You might want to change these configurations slightly to more appropriately suit your environment. |
The following table lists the fact tables that are delivered with Analytics. Every fact table name begins with the prefix ASFACT_, which helps you identify fact tables when working with the Analytics database.
For more detailed descriptions of these tables -- and all tables that are delivered with Analytics -- see the Analytics Database Schema document.
This section provides guidelines for archiving and restoring the partitions within your Analytics database. For details on using Analytics Administration’s Partition Settings page, see Configuring Partition Settings.
To maintain a steady size of your Analytics database and keep your queries performing quickly, we recommend archiving partitioned data that is greater than six months old. You can identify partitioned tables by their date/year suffix. For example: _08_2006.
After archiving or restoring partitions, you must refresh the database views by clicking Finish on the Partition Settings page. If you do not refresh the database views, Analytics reports will fail.
| Caution: | Never remove the current fact table, which is not partitioned. Also, never remove database views. Instead, use the scrolling view window to set the number of partitions that are accessible to Analytics reports. |
|