For a complete view of CPU usage across all Operations Insights enabled databases, click CPU under Resources in the left navigation menu. This page has a master-detail design with three primary components:

• Insights: Table of databases flagged for CPU utilization insights
• Aggregate: Treemap of CPU utilization over all databases in the compartment
• Trend & Forecast: Time series charts of CPU usage trends and forecasts for individual or groups of databases

By default, you view comprehensive CPU usage for each database. Viewing the resource utilization for each database, lets you compare resource utilization between databases and identify servers with underused or overused resources.

Insights Table

The Insights table and Aggregate treemap are either-or choices for the top half of the page, which is used to drive the Trend & Forecast drill-down chart in the bottom half.

Figure 3-1 Operations Insights Table

The table facilitates a number of tasks in support of Capacity Planning use cases:

• Isolates databases with current or forecasted high (or low) utilization
• Quickly compare these databases to each other by size or usage to prioritize analysis
• Identify databases with fastest growth (shrinkage) in CPU demand over the time period

Selecting a database row in the Insights Table will display historical trends and future forecasts for CPU usage for that database in the lower half of the page, described next.

Trend and Forecast Chart

The Trend and Forecast chart displays several historical time series plots related to CPU allocation and usage for the selected database or group, as well as linear regression, seasonality aware and AutoML forecasting (machine learning) trends and forecasts over these data. Trends are computed over the time period selected in the global context area.

The chart facilitates numerous tasks in support of Capacity Planning use cases:

• Forecast future maximum and average demand for CPU resources
• Compare current usage to allocation to detect over-provisioning
• Compare maximum to average usage and trends to assess demand volatility
• Forecast difference between maximum and average daily CPU usage to estimate potential savings from workload smoothing
• Detect and forecast daily or weekly seasonality in CPU demand
• See confidence channels around forecasts to contextualize variability

The following CPU data series can be selected or deselected for display from the legend at right end of the chart:

• Capacity - Maximum number of CPUs (cores x threads/core) available on the underlying infrastructure. This is only shown when looking at a single non-autonomous database, or when grouping by Host or CDB
• Allocation - Total number of CPUs allocated to the current database or databases
• Max Allocation - Maximum number of CPUs allocated to the current database or databases. This is relevant when an autonomous database has auto-scaling enabled
• Max Usage - Maximum value of daily (hourly) CPU usage data for database (or group)
• Max Usage Forecast - Forecast of Max Usage data using selected forecast model
• Avg Usage - Average value of daily (hourly) CPU usage data
• Avg Usage Forecast - Forecast of Avg Usage data using selected forecast model
• Max Confidence Channel - Confidence channel for Max Usage Forecast
• Avg Confidence Channel - Confidence channel for Avg Usage Forecast
• Over-Allocation Range - Over-Allocation Range appears (shaded region) when the total number of allocated CPUs across the databases is greater than the CPUs of the underlying infrastructure (host).

Linear regression

Averages and maximums are over either daily raw data or hourly raw data depending on the global time context as follows: hourly aggregates are used when time period is within the last seven days, otherwise daily aggregates are used.

Forecasts periods are set to ½ the length of the trending time period, e.g. 30-day trends are projected 15 days forward, and 90-day trends 45 days forward.

Figure 3-2 Trend Forecast Chart

The above chart shows daily average and maximum CPU usage over 30-days for the HR-Dev database. We see a consistent and considerable gap between the Avg Usage and Max Usage data series, indicating a high level of variability in CPU demand during the day.

The Max Usage trend and forecast are both very close or touching the Max Allocation for the database, indicating a risk of capacity exhaustion should demand increase or if new workload is introduced.

The difference here between forecast Max Usage (~29 Avg Active CPU) and forecast Avg Usage (~15 Avg Active CPU) is the difference between how much CPU is required to run all work safely and how much CPU is actually required to do all work. When CPU resources are “hard allocated” to databases, this difference represents the amount of resource being paid for minus the amount of resource being used, and is thus an “opportunity cost” induced by having highly variable CPU demand.

One potential way to mitigate this imputed cost of variability is by sharing CPU resources among several databases and allowing dynamic resource allocation among them in response to changing demand.

Oracle Autonomous Database with Auto-scale enabled offers precisely such a solution.

Seasonality Aware

The following chart shows 90-day trend and forecast for the ATP-D database using the seasonality aware model:

Figure 3-3 Seasonality Detection

We see that the seasonality aware model has detected strong weekly seasonality in both the Avg Usage and Max Usage time series, resulting in the wavy forecast lines. There is also a high level of variability in the data, as evidenced by the very wide confidence channels around the forecast lines.

By incorporating the undulating weekly seasonality of the data in the forecast, users are better able to anticipate peak demand requirements that can be smoothed away using linear forecasts.

Forecast Backtesting

Figure 3-4 Forecast Backtesting UI

You perform Forecast Backtesting via Capacity Planning (CPU, Storage, Memory, I/O) for database and host resources. Immediately below the Trend & Forecast chart is Forecast Settings. Here, you set the Forecast Period (how far in the future you want to predict a trend) as well as the Training Period (the time period for which historical data is used to forecast a trend). Changes made to Forecast Settings are immediately reflected in the Trend & Forecast chart.

You can move, expand, or contract the Training Period selector to isolate the exact historical data you determine to be the most predictive for accurate forecasting. For example, you may want to exclude time periods that contain anomalous data spikes, which would throw off predictive analysis and result in higher percentage deviations between actual and predicted trends.

The forecast period begins immediately after the training period ends. More than just allowing you to set when the forecast should begin, the selector lets you begin the forecast period at a point in the past (backtesting), thus allowing you test how accurate the forecast will be based on how accurately it predicts a known historical trend. By default, Operations Insights creates a forecast period of 1/2 of the training period. You can set this to a specific number of days (45, 90, 180, and 365).

To get a quantitative look at how accurate the forecast is, hover your cursor over Average Deviation Values in the Forecast Settings pane to view the average percentage deviation between forecast and actual data.

To clear all forecast settings and start over, click Reset.

AutoML forecasting

AutoML (Machine Learning) forecasting leverages Oracle Data Science, employing metalearning to quickly identify the most relevant features, model and hyperparameters for a given training dataset. Forecast and model are precomputed and the forecasts are periodically retrained. AutoML's forecasting selects the best fit from multiple machine learning models trained on fixed data windows. The forecast uses up to 13 months of data, or the highest amount of data available for a resource if the resource has less than 13 months since onboarding. AutoML utilizes daily data and is only available within a single resource scope (single host or database).

AutoML forecasting is located within the Trend & Forecast chart, click on the AutoML forecasting button. A new pop up will appear with the AutoML forecasting charts loaded. It will state the training period and the selected forecast algorithms for maximum usage and average usage. The maximum and average confidence channels are also displayed within the chart. The confidence interval for these are 95%, meaning that 95% of future points are expected to fall within this radius from the forecast.

Figure 3-5 AutoML forecasting Chart

Note

The slider is a viewport selector.

To learn more about AutoML see: AutoMLx.

CPU Treemap Sizing

Two sizing metrics are offered for the Treemap:

• Usage (Avg Active CPUs) – Larger database cells are bigger consumers of CPU. This sizing is especially useful in CPU-metered cloud settings as it is effectively the relative “burn rate” of those databases.
• Allocation – The allocated CPUs available to the database by OCI. Database cells are sized by CPU allocation. For “hard allocation” scenarios this is the relative fixed CPU cost of databases.

These two options permit users of both Autonomous as well as on-premises and dedicated databases to assess the relative costs vs. utilization levels of their database fleet, as the differing cost models are both covered.

CPU Treemap Coloring

The CPU treemap can be colored using the following two options:

• Utilization (%) - Avg Usage as a percentage of Max Allocation over the time interval
• Usage Change (%) - Percentage change in linear trend of Avg Usage over the time interval

The colors for Utilization (%) are shades of green (CPU branding) from light to dark in increasing quartiles: 0-25%, 25-50%, 50-75%, >75%. These can be seen in the graphic above.

The colors for Usage Change (%) use two color palettes as seen below. Positive changes in usage are colored in shades of green (CPU), light to dark with increasing positive values. Negative changes in usage are colored in shades of amber, light to dark with increasing negative values. This scheme is a bit more complex but captures the crucial distinction of positive from negative as well as the degree of change in either direction.

Figure 3-6 Treemap Coloring

In the CPU Details Aggregate page pictured above, Treemap sizing is by Max Allocation and coloring is by Usage Change (%). The database cells are grouped by Database Type, and the ADW-D group (Autonomous Data Warehouse - Dedicated) is selected.

We see that the trend and forecasts for ADW-D database Max and Avg CPU usage are pretty flat, and with relatively low variance. However, within the group there are four databases, and two are growing in usage (green shades) and two are shrinking in usage (amber shades.) In addition, we can easily see that ADW-D databases account for approximately ¼ of the total database CPU allocation across the compartment. We can also drill down individually on the growing and shrinking databases within the group to analyze their specific trends and forecasts.

CPU Treemap Grouping

By default the CPU treemap shows All Databases as the group, meaning there is only a single group composed of all databases in the compartment, and each database cell area sized proportionally to the sizing metric.

The treemap can be organized as a two-level hierarchy by selecting a Grouping property. Here, the treemap is divided first into groups and then into individual cells within the groups. This allows group size comparisons in addition to cell size.

The following options are available for the Grouping property:

• Database Type
• Utilization Level
• CDB
• Host
• VM Cluster
• Exadata
• Freeform tags
• Defined tags

Grouping by database type allows usage and allocation footprints to be compared by database type, while grouping by utilization level allows rapid evaluation of over-and-under-utilized allocation footprints. For more information on grouping tags see: Group by Tags.

Alternatively, click Storage from the Resources list in the navigation pane to gain insight into individual databases or click Aggregate to view storage utilization across multiple databases. When selecting a single database, you can also break down the storage by tablespaces (applies to External Databases only, this option not available for Autonomous Databases).

Figure 3-8 Aggregate Storage Usage

The volume of storage resources used and the percentage change are represented visually, through the size and color of the cells, respectively. Cells that are larger in size use more storage resources than smaller cells. The largest cell would be that of the databases using the most storage resources. The color of the cells is determined by the percentage change in the storage resources used by the databases.

To analyze storage utilization across a specific subset use the Group menu to group databases according to Database Type or Utilization Level. Click on a specific group to view the trend and forecast for space utilization for all databases within the group.

For Operations Insights to forecast your resource utilization for a year, there must be at least 13 months of stored data. The forecast value is more accurate when there’s more data. You can use the current and forecast storage utilization to plan your database capacity.

The amount of I/O activity and the percentage change in that activity are represented visually, through the size and color of the cells, respectively. The cells that are larger in size indicate more I/O activity than the smaller cells. The largest cell would be that of the database that presents the greatest amount of I/O activity. The color of the cells is determined by the percentage change in the I/O resources used by the databases.

To analyze I/O activity across a subset of databases, use the Group menu to group databases according to Database Type. Click on a specific group to view the trend and forecast for memory utilization for all databases within the group.

The volume and percentage changes in the I/O activity are represented visually through the size and color of the cells, respectively. Cells that are larger have greater I/O activity than smaller cells. The largest cell would be that of the database with the highest I/O activity. The color of the cells is determined by the percentage change in the I/O activity during the specified time period.