Comments
-
You can do that by using a custom alert referenced in this Thwack article: Job Failure In the SQL statement, you can add something like this to the WHERE clause to limit the alert to specific jobs: AND t2.name IN ('Backups - PROD', 'Backups - DEV') Note: The #FREQUENCY# is placeholder that DPA substitutes the alert…
-
Yes, definitely. I will try that and get back to you.
-
The DPA GUI shows blocking on a session level, i.e. which session is blocking/being blocked. If you are counting things by SQL statement, you could have different results. If you want to make sure things with the query are correct, I would suggest counting by sessions which is stored in the VDSI column within the CONSW…
-
Unfortunately DPA does not have custom report capabilities, so you will have to execute from SSMS or other query tool.
-
That really is your best approach. It sounds like you looked through error logs and did not find anything, so the support group can help go through them in detail. I suggest that when you create the support ticket that you add your DPA logs as an attachment.
-
Under the Reports link, it is an option for reporting:
-
The script I am seeing had a few missing columns in the WHERE clause. After looking at sys.database_permissions here is the script I ran on a newly created DPA repository database. I did not get any rows returned. I then ran the same query on several other repository databases and did not get anything either. SELECT…
-
We are currently updating this KB article, and found that an extra step may be required for some of the new DPA 12 features. Within the GUI, when you drill into Table Tuning (new Tuning tab), the page queries information about the table and can fail after the sysadmin priv is removed. If you experience that issue here is…
-
Yes, that is an option to actually free up the space, but often not a great one because it can cause fragmentation. The best option is to configure DPA as you want, i.e. alter the CLEAN_DAYS_OF_DETAIL setting above and let it run for a couple days so it purges to where you want. A very clean option to then shrink the space…
-
Is this what you are looking for: SQL Server metrics that DPA collects by default - SolarWinds Worldwide, LLC. Help and Support
-
This question is for Orion and I will move it to the correct forum for better response.
-
BTW, here is a link to this custom report: Custom Report - Metric Values
-
Oh, and by the way, vote up this feature on Thwack:
-
The SQL text for both hashes visually looks the same. Let's run a query against the DPA repository to see if SQL Server thinks the text is different somewhere. -- pick the id value for the monitored instance SELECT id, name FROM ignite.cond ORDER BY name; -- replace <DBID> below with id from above query -- use SQL Server…
-
Here is a custom alert that should work for you: Custom Alert - SQL with specific text executed . Let me know how it works or if you have questions.
-
Here is another option that is more generic and does not use XP_servicecontrol: Monitor SQL Server Agent - No XP Proc
-
DPA has been monitoring DB2 10.5 for quite some time, so I am confident they should be able to find the issue. If they cannot find it, they can escalate to dev to get more help.
-
Thanks for the link Fabian. There is a setting named com.confio.iwc.emailLinks.urlOverride that you can set to use SSL.
-
Is this a SQL Server instance where you see this? If so, have you tried any of the suggestions above to capture the sql_handle?
-
There is another option you can use if this query executes more often. You can have DPA log the sql_handle value for this SQL and then query the SQL Server DMVs to see if the sql text or statistics are available. To do this, follow these steps: * Click on Options and Advanced Options * Click on the DB Instance Options tab…
-
This can be done via custom reports, which are available on thwack.com under the Database Performance Analyzer. Here is the link that should do this if you have a SQL Server repo: Custom Report - Top SQL for Database User. If you have an Oracle repo here is the link: Custom Report - Top SQL by Database User. HTH. Note that…
-
The database info is stored in the CONSW_XX.IXOY column, and it joins to the CONO_XX table. Adding that join gives us something like this where you can replace 'master' with whatever you need: SELECT COALESCE(AVG(timesecs), 0) avg_blocking_timesecs FROM ( SELECT sw.VDSI, ISNULL(SUM(sw.QP)/100,0) timesecs FROM…
-
To modify the query, you would change the line below to use the name of the custom metric: where mn.NAME = 'CustomMetric-2'
-
This custom alert requires a custom metric to be setup as well. If you did not setup the custom metric, there would be no data for deadlocks and hence a null result set would be returned. If you did set that up, make note of the name for it in the Ignite GUI and modify the query accordingly.
-
Yes, we typically reach out to those who voted for a feature to become beta testers early in the process. We also mark the feature request as implemented. As far as the alert goes, you can execute as frequently as once a minute, if you want to be notified within 1 minute of a failure if that helps.
-
Setting the time when an alert executes is definitely on our radar, and already included in a future release. However, we cannot guarantee when a specific feature ends up in a release. Sorry about that. You mentioned monitoring database jobs. Is that an alert you would only run once a day where scheduling becomes…
-
That table should have been present in DPA 11.0 unless something happened during upgrade. The current version of DPA is 12.0 and we'll soon be releasing 12.1 (DPA 12.1 RC2 is currently in your portal). You might try the following query which will give you the data for each database/replica: SELECT 'DB: '+DB_NAME+',…
-
The new features within DPA 12 use a different technology than previous versions. We are moving the whole GUI to the new screens eventually, but I will send your note to our engineering team to get their thoughts.
-
There is not a lot of documentation about operations, but it appears that a "read" is associated with retrieving the data from tables while the "select" is more about sending the data back to the client. If you drill into each of those operations within DPA, use the Wait Instruments tab to tell you more about where the…
-
Your query looks at the top SQL statements for the one day you entered and then breaks the data out into hourly summaries, which is completely valid. However, the DPA chart does it differently in that it only uses the Top 15 from the 30 day trend view to keep the charts consistent. To match up data, you would have to get…