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

Gaps in Polling/Chart Data during DB Maintenance

jbaulsir

Since upgrading to 8.5.1 we are see gaps in polling/chart data when DB maintenance is running.

Antyone know a fix or experencing the same?

ChartCA75E4AK.jpg

Find more posts tagged with

Accepted answers

All comments

jbaulsir

So I'm the only one with this problem?

I guess I'll have to open a ticket (ack)............

Miron

Hey Mate,

I also get this problem, to which I have not received any resolutions as yet.

jbaulsir

I opened a ticket, and thusfar the only solution seem to be to get a more powerful SQL server.

What are you running on?

FormerMember

If you're getting gaps, it suggests that when DB maintenance runs, you're hitting I/O problems. It's not necessarily that you need a bigger SQL server (although you might), but you need to configure your server for better I/O.

mhh351

I have had that for several releases. The dB maintenance for large databases requires a lot of time. While this is going on, the database is naturally locked. Since the polling engine has no idea WHY the database is locked, it just waits patiently for a confirmation from SQL, the polling interval stretches out to past the next interval(s). Therefore, gaps appear.

This is so regular, that we look for the interruption to confirm that the DB was maintained.

Any help with this from support would be great. A bigger server is clearly not the solution. Ours is pretty beefy already.

NasaGeek

We saw this on hardware that was more than enough to handle the job. Support did not figure this out, but we traced the problem to some BSD devices we were polling. Once we removed these, the application became stable again.

I have noticed that the performance is worse in 8.5.1 than it was with 8.1. It got better and now worse.

I should state that we were loosing points all the time all over the place, but during the maintenance we hardly had any points, 2-3 hours of nothing.

vhcato

Heres what we've seen...

Our previous SQL server was a clustered pair of SAN attached, dual processor HP DL380-G3's (with hyper-threading) with 8 GB of RAM (Win2000 and SQL Server 2000). One server in the cluster was hosting only the Orion instance, and it had 4 GB of RAM allocated to it. We were running Orion v7.8.5 at the time, and the nightly maintenance routine took a little over an hour to complete. During this time, we were seeing some significant holes in collected data.

Our new SQL server is a standalone dual quad-core HP DL380-G5 with 8 GB of RAM and 15K RPM SAS local disks. This server is running Win2003 EE (64-bit), and SQL Server 2005 SE (also 64-bit), and the SQL instance has 6 GB allocated. We moved to the 8.5.1 release of Orion when we moved to this server, and our nightly maintenance now takes approximately 4 minutes.

WINNT

Vic,

I don't think your new hardware was the main factor in the database maintenance running time. I have an HP DL380 G3 with hyper-threading with 4 GB RAM Windows Server 2003, SQL Server 2000 Standard, on local RAID-5. Version 7 of NPM had different maintenance code which took a little over 8 hours. With version 8, it now takes only 1.25 hours. I have been monitoring the start/stop times of the process since we started having issues in v7 when it would never finish, and the data collection was all but halted. Our database is 54 GB.