mandevil · Product Manager · ✭✭✭✭✭

A hash implies one way. Having said that, there's no path backward. I like the idea of persisting and mapping the handle to the hash.

Oh, are you talking about the Orion repository or DPA? Please clarify as my response was specific for DPA.

gcp is correct, currently notifications are assigned at the alert level, not the grouping. Great feature request suggestions! I'd also like to see groupings propagate to other areas of the product (meaning if you define a grouping on the dashboard, you can use that grouping again for alerting or option administration,…

Currently, resource metrics are not in our reports - you can vote the feature request up here: In the resources tab though, you can view the longer timeframes by clicking on the 6 month or 1 year for the category of resources you are interested in. I saw you increased your CLEAN_DAYS_OF_DETAIL for waits... You can also do…

Can you define what you mean by transaction log activity? Do you mean growth, truncation, log writer waits, other?

This post must have slipped past me... Sorry about the delayed reply. Here is an article that explains how to set it up. As to why you would do this, it's so that user accounts don't have to be used and no PW changes have to be maintained. This can make administration of monitored instances easier in large environments.…

Yes, at this time, the wizard will only define one blackout window at a time, so you'd want to create an alert blackout for alerts for each day during business hours.

If you look in the repo for a table named COND, you will see two columns (command and status). The command represents the desired state of monitoring as gcp points out and status reflects, well the status. If you want it to NOT try to restart monitoring, then the command should be set to 'STOP'. Hope that helps.

Awesome - let us know if you run into any issues though or reach out to support at Submit a Customer Service or Technical Support Ticket - SolarWinds

Having said that, detailed information similar to what you are looking for is on our what we're working on list: What We Are Working On for DPA (Updated May 11, 2016) I've seen a preview and it's got some great information (not identical to what you specifically want, but still solid intel around blocking).

Run this query to see what objects in the repo are consuming the most space. That may point to something that's amiss. IF OBJECT_ID('tempdb..#t', 'U') IS NOT NULL DROP TABLE #t CREATE TABLE #t ([name] NVARCHAR(128),[rows] CHAR(11),reserved VARCHAR(18),data VARCHAR(18),index_size VARCHAR(18),unused VARCHAR(18)) -- get the…

The official Oracle stance is that the x$ tables are undocumented, not unsupported. That's a key distinction. I've been on several calls with Oracle support directly and they are quick to state the undocumented part of it. Nothing about this is unsupported nor deprecated. BTW - The reason we go after the x$ tables is for…

VMs are absolutely supported. You'll want to review the system requirements and make sure the VM has plenty of horsepower just like you would a physical server. In fact, I like VMs better as it provides built in fault tolerance...

Thomas - we'll need to see logs and potentially up the verbosity to get a better error stack. Just for fun, have you tried that parameter is the additional jdbc url properties field? I agree though, a support case for this would be the next step.

Have you run through the integration yet? What version of Orion are you running (you mention tab, so thinking prior to 6.2.4)? If you are in eval mode, you can also talk to one of our engineers to get it sorted out...

Clarification - were you looking for logins to DPA or logins to monitored instances?

Sorry about that - after reviewing again, I believe I misspoke. It looks like what you are seeing is the complete definition of the SP, whereas Ignite/DPA is calling out which SQL statement within the SP that's accruing the waits. In the first case, we're seeing this statement running within the SP referenced. This is…

That's true about 9.2, but there were some cool things in 9.1 that would be included in 9.2. Most notably the ability to exclude SQL statements from the trend charts (if there's one that's really skewing the scale, you can make it disappear and then add back in as needed). The other feature I really liked was the ability…

When you have found the query, make sure you click on the query name or the hash for it. Then it should be added as part of your breadcrumbs (context near the top). From there, you can click through all the other dimensions including machines to see what client(s) are running it. Let me know if that doesn't help...

This needs to be configured on the DPA side within it's custom alerts function. This won't currently work from the Orion side.

If they are using windows auth, then you have it. If they are using SQL auth, I don't know of a way to get it through SQL Server...

So we use the CONO table for the OS user in Oracle which is where the confusion was. For SQL, we highjack that table to store databases. We don't actually track login or OSuser for SQL Server, so that means we don't even capture that raw data for SQL Server. You can do it by database user, but not for login. Sorry about…

Yeah, seeing same thing. Our internal documentation appears off. Researching. 8 )

So, you've found out that our schema naming conventions are cryptic. 8 ) We hear that a LOT! Let's start with the two executions. If you do a select id, name from COND, you will see the @dbname (name column) we want to use for this proc. The @osuser is referencing the name column in CONO_1, so as long as you are using…

I think the issue is that the script had like 'LCK%' as the wait and with Oracle, that should have been 'enq%'. I've edited the alert on Thwack. Should be like below. Let me know if this still errors. If you want to test, you can run a "select id, name from cond" and substitute the id number for #DBID#, example: conev_1…

You are correct that if the statement changes, it will get a different hash. Regarding joining for the procedure name, try joining to the const_id table using the consw.izho and const.h columns. In const, you should be able to pull the pname column for the SP.

Mark, is your repo on SQL or Oracle? If you can grab the SQL hash value that we assign in the tool, then we can exclude that hash by referencing the consw_id.izho column. So something like where sw.izho <> hash_number

Ha! That's a lot of jobs! 8 ) Look for other report ideas coming soon (spoiler alert - tempdb, stored procs, other ideas?)!

Let's check this for one of your monitored instances. Against your repository, run this: select id, name from COND -- note the id value for an instance this metric/alert should run against select id, name from CON_METRICS_NAMES_<id from above> Use that metric name in the where clause in the alert as mentioned above. Let me…

I see. Yeah, this will only get your part of the way. My recommendation would be to submit a support ticket. They can help you with which summary tables to query for this information. This will be from sampling and from a wait activity (or processing activity in this case), so not actually telling you user XYZ consumed…