The idea of "discoverability" in UI design is great, but still doesn't replace the benefit of a manual. It's not unusual for someone to point out a feature in DPA that I never noticed or knew about before. It would be great to be able to go through a manual and find all of the features.
I can certainly pass this on to our program manager regarding the comprehensive guide.
Regarding sessions, think SPIDs.
Since there isn't a guide at this point, you can certainly submit a case to support and we can do a tutorial and hopefully address any ambiguity for you.
@Mandevil I'm sure many of my fellow DPA users would appreciate this as much as I. I am curious as to how this has not been done before now. This is my 2 major revisions to DPA so its not like as if the DPA product is new and therefore not had enough time to receive the proper documentation once over. Thanks
One thing I've noted before is the sparseness of the DPA documentation. Oh it's adequate for the installation and getting started, but it's very lacking in technical information.
It's reasonably intuitive to get going, but definitely could use a bit more techy info for us techy DBA types
There's a lot of info in the KB articles, but it's scattered all over the place and some of it is well out of date (e.g. "How to Upgrade from Ignite 6.5 to Ignite PI") and should go in the archives.
2 of 2 people found this helpful
I'm going to answer my own question and that answer is a reluctant and long running NO. While a user with an active support plan can contact tech support for assistance with X feature or to get an answer to Y question those are not answers/solutions but incomplete work-a-rounds that are dependent on the user having a current maintenance contract that is not free. 1) No User of any software product should have to pay to learn how the product they’ve already paid for is supposed to works. 2) The next major update for DPA needs to be documentation, specifically an end to end comprehensive guide to DPA for SQL Server and presumably Oracle and MySQL. Thanks to all who have replied back and effectively voted on this being an issue that needs to be addressed.
1 of 1 people found this helpful
I'd like to add to this in case anyone with Solar Winds who has the ability to fix this lack of documentation issue reads through these forums.
Software documentation is about more than just providing users with a how-to manual or even a set of FAQs. When a licensed user of a piece of software is faced with having to pay to get basic questions addressed about the product because there is no comprehensive documentation that sends a very confusing/mixed message to that users is not the user community as a whole. It also raises the question of the vendors commitment level to their product. If they are going to continue to make the software available then why are they not fully documenting its workings for their licensed users?
Personally I find that when a software vendor avoids product documentation for something that’s has been through several revisions and therefore is no longer “new” its typically due to a lack of resources (not enough employees to produce the documentation), a lack of motivation, a fear of commitment or some combination of these. Any specialty software worth paying for should be comprehensively documented regardless of how intuitive it is. I used to deal with a software vendor that was the market leader of an industry in which the software it produced was the best of a handful of products. For years that vendor continually put out reports for their product that seldom if ever were documented. Needless to say this lead to numerous/unnecessary support calls and wasted man hours trying to figure out if there was a data issue or a reporting issue when something on the report was wrong. With no manual document to reference it was impossible for a user to determine if the report was broke or if it was merely a "design difference". If you don’t know how something is supposed to work then how do you know if its broken when the report does not look/work as you think/expect? So long as you can’t identify if it’s a bug or a design difference your stuck with paying the vendor to "change" the report for you as opposed to fixing something that’s broken.
Eventually the frustration amongst the users community grew to the point that several of the larger customers banded together (forming their own user group) and made their own reports. When that happened the vendor lost the ability to control the reporting side of their product. That in turn lead to lost revenue in report customizations. I imagine this also lead to lost sales behind the scenes due to an increase of distrust between the users and the vendor and all over something that not only was easily avoidable but should never have even been an issue once the product was into its 2nd major version. Don't let this lack of comprehensive documentation to go unresolved.
Thanks for the honest and open feedback. DPA definitely could improve its online documentation and we take documentation very seriously at SolarWinds.
In fact, let me take this opportunity to introduce our brand new Success Center - put together to help customers get more value from our products and centralize all our documentation, knowledge base articles, video, etc.
Especially interesting is the Getting Started section, that helps both new and experienced users leverage our products to their full potential - see the SAM Getting Started section as an example.
Alas, DPA didn't get to be first release of the Getting Started section, but our excellent documentation team is hard at work to build out that section for the rest of our products - stay tuned!
In the meantime, you can access Database Performance Analyzer (DPA) - Updated May 5, 2017 for references to current documentation, popular KB and videos.
Thanks again for your feedback!
PS - if there a specific problem or use case you are looking to solve, post it here and we can add to the list of potential use cases documented in the future.
2 of 2 people found this helpful
Years ago I had put together a 1-day training session on DPA that I delivered for a customer. It walked through the items such as the concept of wait events, how DPA did collections, and how to make your own customizations.
I think the idea of a comprehensive user guide is a good one, as DPA does have a lot of features and many of them are often unknown to users.
Thanks to all who have posted about the need for comprehensive DPA documentation. We are working to make improvements. As of this post, the DPA documentation set includes:
- DPA Installation and Upgrade Guide (38 pages)
- DPA Getting Started Guide (41 pages)
The Getting Started Guide describes DPA's wait-based approach to database monitoring, and walks through several examples of using DPA to investigate performance problems.
- DPA Administrator Guide (281 pages)
The admin guide provides information to help you use DPA's features. The guide is continuously being updated to cover new features and improve coverage of existing features. Recent additions include descriptions of DPA's resource metrics, instructions for excluding SQL statements from monitoring, and improved instructions for creating alerts.
All of these guides (plus release notes and other documents) can be found in our Success Center, here: Documentation for DPA
Of course, documentation always has room for improvement! When you go to any guide page in the Success Center, there's an option to submit feedback. When you click the "Yes" or "No" button under "Was this page helpful?," you can enter specific suggestions. Please let us know what is helpful, what needs to be improved, and what is still missing. Thanks!