Managing database performance is rarely straightforward, and the demands only keep multiplying. In response, DBPLUS Performance Monitor 2024.4 introduces new features that help you see exactly how queries behave across different platforms, track CPU usage at a glance, refine how and when alerts reach you, and unify session data.
If you prefer a monitoring tool that shows critical insights with less hassle, the latest version deserves your attention.
OS Stat Reports for CPU and Memory
The latest release of DBPLUS PERFORMANCE MONITOR enables a consolidated view of CPU and memory usage at the server level. You select a date range, choose which servers you want to observe, and specify how you’d like the results grouped (snap, hour, or day). The interface calculates average usage, maximum usage, and “working hours” usage, defaulting to 8:00 a.m.–5:00 p.m.
- Oracle: Administrators can easily track CPU usage across RAC or standalone instances without needing separate system monitors or custom scripts. Seeing each node’s resource consumption helps identify whether poor query performance stems from node-level CPU constraints.
- MSSQL: Users can view CPU or memory data at the instance level or the host level. This approach helps if multiple SQL instances share a single server, letting you pinpoint which instance is consuming the most resources.
- PostgreSQL: The system_stat extension allows DBPLUS to collect CPU usage and memory details for PostgreSQL servers. The tool displays these metrics alongside other performance data, so you no longer rely solely on external OS-level logs to see if the server is overloaded.
Temporary Disabling of Alerts
In environments where routine testing or planned maintenance can trigger misleading notifications, the ability to suspend alerts selectively is a significant relief. A new feature under Configuration → Alert Settings → Alerts Outages lets you disable specific alerts or entire alert types. You can set time windows (including days of the week and hours in the day) during which notifications remain quiet.
Just to visualize this with an example: you might silence “high CPU” warnings during a known load-test window or skip database-free-space alerts while reorganizing data files. The aim is to focus your attention on real anomalies, not false alarms or artificially induced stress tests.
Query Performance and Execution Plans
DBPLUS now provides deeper insights into the way queries run, showing execution-plan details, real-time or near-real-time statistics, and better ways to compare performance across different conditions.
- Oracle (RAC): If your Oracle database is part of a RAC cluster, the SQL Details screen identifies each node’s metrics. You can see how the same query behaves on node A, node B, or multiple nodes simultaneously. A history view provides a new “Inst id” column so you can track each node’s statistics over time, while an “online” checkbox allows you to check real-time query performance. This setup clarifies whether one node is taking a detour through an inefficient plan or if the entire cluster shares a common bottleneck.
- MSSQL: Though MSSQL doesn’t use RAC, administrators get other improvements, such as the ability to compare IO Stats for multiple databases in a single chart. This helps isolate whether a query slowdown is tied to a specific database or if the issue is more widespread across the instance.
- PostgreSQL: A Show plan objects screen now displays index-level metrics (index scans, tuple reads/fetches, and disk blocks read) for tables referenced in the query. This real-time index data shows whether the engine is hitting expected indexes frequently enough—or if it’s accidentally performing more table scans than planned.
These changes reduce the trial-and-error process of diagnosing poor query performance. They also limit the need for external scripts or manual plan comparisons, keeping everything accessible in the DBPLUS interface.
Session Data, the “Kill Session” Command, and Audit Logs
DBPLUS has updated how it stores session history and now logs every user-initiated “Kill Session” action to preserve a transparent record of changes.
- Oracle: Session data for active sessions, TEMP usage, and UNDO usage is merged into a single table. After upgrading, an automatic migration process merges older session records into the new format. This cuts down on repository size and speeds up queries against historical data.
For “Kill Session” actions, DBPLUS appends an entry to the Audit Log, noting which user ended the session, when, and (if available) why. This audit-friendly approach clarifies who made changes to the environment.
- MSSQL and PostgreSQL
The Audit Log also captures “Kill Session” actions for those. This ensures all administrators stay accountable if they terminate a blocking or runaway session. Fewer separate session tables means simpler data management, although MSSQL and PostgreSQL do not require a unification process exactly like Oracle’s.
MSSQL-Specific Job Monitoring and Alerts
For MSSQL users, DBPLUS can now trigger alerts for Jobs based on multiple factors: name, status, owner, or duration. You specify conditions such as “Job runs longer than X minutes” or “Job fails if it goes beyond normal runtime,” and DBPLUS flags the event accordingly. The alerts appear on the Dashboard, Anomaly Monitor, or Instance Load screens, and you can optionally receive an email notification if you set up an Events mail subscription.
This development relieves administrators from manually sifting through SQL Agent logs or discovering job failures too late. If backups suddenly start taking five times longer than usual, DBPLUS warns you right away. You can refine the filters to stay informed about only the most relevant issues—rather than every single job event.
Space Monitor Updates
DBPLUS now expands how it tracks and displays space usage, giving you a clearer understanding of database occupancy.
- Oracle: The Performance report can include a new Space Monitor section, showing how big various tablespaces are over time. You configure a date range and select units of measurement (MB, GB, or TB) to highlight growth trends or outlier usage events.
- MSSQL: A separate Space Monitor screen tracks file-group occupancy. You can group results by server, instance, database, or file group, then check both current and historical usage levels. This helps see whether data is spread in a balanced way or if one file group is swelling faster than anticipated.
- PostgreSQL: No new file-group-related feature was introduced, but you can still track memory usage at the OS level. Many administrators also rely on general PostgreSQL data checks to monitor how quickly individual tables or indexes grow.
Seeing these space metrics in the same place as performance data makes it easier to predict potential size constraints. You can spot a ballooning file group or tablespace and act before the system complains or runs out of space mid-operation.
The post Performance Monitor 2024.4: What’s New appeared first on DBPLUS Better Performance.
