Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

Breaking stuff using SWQL Studio?

Hey y'all, I'm new to SWQL and the Studio and I'm trying to build a modern dashboard on the Orion platform, and I just wanted to know how careful I need to be with my queries in SWQL Studio. I'm basically here to ask if I can break something or crash the server if I query the wrong thing or too much. Note I have been avoiding joins (because im scared) and have mainly been using navigation properties. I've only really played around on a dev server, but I've got access to the production environment now and I just want to make sure I don't mess it up. Thanks!!!

EDIT: I was also wondering if a database is being populated with polled values and I send through a large query would it prevent the polled values from being entered if the system is servicing my query?

Find more posts tagged with

SWQL

Modern Dashboards

SWQL Studio

Accepted answers

All comments

stuartd

The beauty of SWQL, as I understand it, is that unless you delve into the verbs then you can't break anything. BUT you can grind your DB to a standstill so, using your words, don't do "too much".

Don't be scared of JOINs - 2yrs ago I knew about them but hadn't a clue on how to use them and then I got into them and I am what you might call an extremely basic coder in that I can do simple queries. Anything involving CASE or stuff like that still defies my understanding - but you are right to use the navigation properties where you can.

Does your dev server mirror your production - even if reduced in size? If so, I would always test my code on the dev.

HelpMeTHWACK

Yeah, I've been practicing on the dev server although it doesn't contain many of the nodes I'm looking to query unfortunately. Thanks for your help!

jm_sysadmin

First, this is a good question, and the right time to think about preventing slowness is before you have it.

Also, there are built in timeouts for queries, if it runs too long, they stop. Most SWQL when run won't cause an issue, but if you use it to say power an alert that gets check every minute, and another 10 in a dashboard that get refreshed every minute, and a table on the default starting page everyone sees when the pull up the Orion site... you see what I am getting it. It adds up.

Pay attention to the run time. There are ways to see it in use (next part) but in SWQL studio from the SDK it shows you how long a query takes. As you pay attention, you will get a better handle on what is and isn't a good idea. Also, I find that the modern dashboards have pushed me in a positive direction for performance. They do a great job summarizing, so I put a few (maybe 6-10) data points that indicated health or issues onto a top-level dash. Each links down to a dash with more details on a specific topic to summarize, or a page dedicated to details (or even a report).

If you do end up with slowness or performance issues, dig into:

Turn on and use Hubble with Orion modules (solarwinds.com)

HelpMeTHWACK

Thank you for your great reply. My original plan was to make a top-level summary dashboard which linked to others for specific systems so it's great to know that pros do that too! So, from what you're saying, it would put a lot of strain on the system if I put lots of large queries on a dashboard that everyone uses, but just doing large queries once in SWQL Studio to test them isn't going to break anything because, if they're too big, it'll just abort.

adam.beedell

You should be fine. Needing to join should be fairly rare as stuff's usually all auto-joined anyway.

Case statements are your friend.

Dont query the logs DB that seems to be non bueno.