Database teams are navigating noisy alerts, SAP HANA slowdowns, application performance issues, and a growing list of tools to evaluate. Our August live sessions focus on these challenges, with practical guidance for DBAs, SAP Basis teams, application owners, and observability teams. Explore the webinars below and register today. Please note: This blog provides a brief overview of the webinar and does not cover all of the content discussed in the session. Watch the live webcast or on-demand session for the complete presentation.
Webinar August 11 – Build Database Alerts You Can Trust
Too many alerts can make it harder for database teams to focus on the issues that matter. When notifications are noisy, generic, or disconnected from normal workload behavior, teams may spend more time sorting through alerts and less time investigating meaningful changes.
The challenge is not simply how to create more alerts. It is how to create alerts that provide useful information when a response is needed.
How To Customize Database Alerts explores practical ways for DBAs and SQL Server professionals to build more targeted and actionable alerting. The session focuses on moving beyond one-size-fits-all thresholds and using the behavior of real workloads to provide better context.
Why static thresholds can fall short
A threshold can identify that a metric has crossed a predefined value. On its own, however, it may not explain whether the change is unusual for that environment, which workload is affected, or what the team should investigate next.
The same threshold can also mean different things in different circumstances. A short-lived increase during a known reporting job may require a different response from a sustained change during normal business activity. Alerting that accounts for context can help teams distinguish between expected variation and behavior that deserves closer attention.
Use baselines to improve alert quality
Performance baselines provide a way to compare current behavior with an established view of what is normal. That can help teams identify meaningful deviations without relying only on arbitrary values.
A stronger alerting approach can include rules tied to specific databases, applications, workloads, or query patterns. It can also include clear information about what changed and where to continue the investigation. The objective is not to eliminate alerts. It is to make the remaining alerts more relevant and easier to act on.
The webinar also considers practical alert-management habits, such as reviewing rules regularly, consolidating overlapping notifications, and removing alerts that do not lead to a defined response. These steps help keep alerting aligned with the environment as workloads and priorities change.
Turn alerting into a more useful practice
Alerting works best when it supports a broader monitoring and observability process. A useful notification should help a team understand what happened, assess the potential impact, and decide where to look next.
That approach can give DBAs a clearer path from signal to investigation. It can also make conversations easier across database, operations, and application teams because the alert includes more of the context needed to discuss the issue.
Whether you are reviewing an existing alert strategy or building one for a changing SQL Server environment, this session provides practical guidance for reducing unnecessary noise while preserving visibility into important behavior.
Catch the live webcast or watch the on-demand session.
Beyond Detection: Troubleshooting SAP HANA Performance Issues – August 13
When SAP HANA performance changes, identifying that a slowdown exists is only the first step. The more important question is what is causing it and where a team should begin its investigation.
High-level health metrics can show that an environment is under pressure. They may not, on their own, explain which database activity, wait, query, or resource is contributing to the problem. That can make troubleshooting slower and increase the risk of focusing on symptoms rather than cause.
Beyond Detection: Troubleshooting SAP HANA Performance Issues Faster examines how teams can move from detection to diagnosis using SolarWinds® Database Performance Analyzer (DPA).
Start with where time is being spent
SolarWinds materials describe DPA as extending wait-based performance analysis to SAP HANA. A wait-focused view helps teams investigate database-layer behavior instead of relying only on broad health indicators.
This approach gives an investigation a more specific starting point. Teams can examine where time is being spent, identify activity associated with a slowdown, and use that information to decide which area needs attention first.
The session covers common areas that can contribute to SAP HANA performance issues, including expensive SQL, lock contention, CPU and memory pressure, disk and storage latency, and workload changes. Reviewing these factors together can help teams build a more complete view of the event under investigation.
Connect database activity with impact
SQL-level visibility is important because a system-level symptom does not necessarily identify the statement or workload behind it. Teams need evidence that helps them understand the relationship between database activity and the performance users or applications are experiencing.
DPA materials also describe visibility into waits, SQL activity, blocking, and resource trends. Used together, these views can support a more structured investigation and help teams prioritize the next corrective action rather than working through disconnected checks.
This is relevant for DBAs, SAP Basis teams, and IT professionals supporting SAP HANA environments. It is also relevant for teams working across on-premises, cloud, and hybrid deployments that want a consistent way to investigate performance behavior.
A repeatable troubleshooting process makes it easier to explain what happened, share evidence across teams, and improve future investigations. It does not remove the need for technical judgment. It helps teams apply that judgment to more specific evidence.
Catch the live webcast or watch the on-demand session
SolarWinds Database Portfolio Product Update – August 18
Database teams need a clear view of more than individual features. They also need to understand how product changes relate to the work they do every day, including monitoring performance, investigating issues, and improving visibility across database environments.
The Q3 2026 SolarWinds Database Portfolio Product Update brings recent enhancements, roadmap highlights, and portfolio news together in one session for database customers and users.
Put product changes in context
A product update is most useful when it explains what has changed and why the change matters. Rather than reviewing a list of features in isolation, the session is designed to connect product development with common database performance and observability priorities.
That context can help teams evaluate which updates are relevant to their environments. It can also help database leaders prepare for changes, identify areas to explore, and discuss how their current monitoring and troubleshooting practices may evolve.
The session covers recent enhancements across the database portfolio and provides an overview of roadmap direction. Roadmap information is not a substitute for product documentation or contractual commitments, but it can help customers understand the areas receiving attention and the problems the team is working to address.
Hear directly from the database team
The update also creates a direct opportunity to ask questions. Teams can raise issues related to their own environments, ask how recent changes may apply to their use cases, and hear more about the thinking behind product priorities.
That conversation is valuable for DBAs, database administrators, and technical leaders who are reviewing their performance and observability strategies. It can also help teams separate what is available now from what is planned, which is an important distinction when they are making operational or procurement decisions.
Whether you attended the live briefing or are catching up on the recording, this session provides a concise way to review what is new, what has changed, and what to watch across the SolarWinds database portfolio. It is a practical reference for teams planning their next steps.
Catch the live webcast or watch the on-demand session.
Register for the Database Portfolio Product Update
From Trace to Query: Finding the Database Calls Slowing Your App – August 25
When an application slows down, application performance monitoring can help show where time is being spent. The investigation becomes more difficult when the slow path reaches the database and teams cannot quickly identify the specific call or query involved.
Application owners may see latency in a trace. Database teams may see query activity and database behavior. Both views are useful, but the path to root cause can take longer when the teams are working from separate evidence.
From Trace to Query: How To Find Database Calls Slowing Your Applications focuses on connecting those views. The session explores how teams can move from application trace data to the database calls and query behavior affecting performance.
Move beyond symptom-level visibility
A trace can identify a slow request and show the parts of the transaction that took time. That information can help teams determine whether a database call deserves closer investigation.
The next step is query-level evidence. High-level response-time data may confirm that an issue exists, but it may not identify the database behavior driving the delay. Connecting a slow request with the database call behind it gives application and database teams a more direct route into root-cause analysis.
SolarWinds Observability documentation describes trace context as a way to associate application queries with database performance. When the relevant instrumentation and configuration are in place, trace context can help identify the source of a query and support links between trace details and query-performance details. The exact workflow depends on the product, deployment, instrumentation, and configuration in use.
Give teams a shared investigation path
Trace-to-query visibility can also reduce unnecessary handoffs. Instead of debating whether an issue belongs to the application, infrastructure, or database layer, teams can examine the same chain of evidence and decide which part of the request path needs attention.
The session is designed for DBAs and database teams, application owners, platform and service owners, observability teams, SREs, DevOps leads, and technical managers responsible for business-critical applications.
It covers how to connect slow requests to database calls, investigate the query behavior behind a performance problem, and relate user impact to evidence that supports root-cause analysis. The goal is not to replace application monitoring. It is to show where database visibility becomes important and how the two perspectives can work together during an investigation.
Catch the live webcast or watch the on-demand session
Register for From Trace to Query
Save Your Spot
Each session includes a live Q&A. Register to attend live or access the on-demand recording later. Choose the sessions that match your environment and reserve your seat today.
