Suggestion on how to start a new NimsoftSLM db?

[Daniel Blanco]

Hello, we are pondering the idea of starting a brand new UIM database. Basically due to the fact that our have grown to almost 1TB and the performance is really bad in the UMP. Loading data take a very long time for metrics to show up in the UMP USM page for hosts.

 

We were thinking of moving the existing database over to an archived database which would be used for just reporting purposes. I wanted to know what or how should we go about re-creating the database from a fresh start then point the existing environment to the same database? 

What would be our best options here? 

1. Make the backup copy it over to archived machine?

2. Then on existing SQL box do a shrink down to a small file size? 

 

Just lookign for ideas, suggestions? Thank you.

[Anon Anon]

Hi,

 

Not exactly sure what all data really gets put into the db that is environment specific, but I belive you should be fine rerunning the instanner on your primary hub and creating a new database in that process.

 

I  guess you've already tried tuning your current DB? I have also around 1tb data in my DB and it's not that slow with UMP etc.

 

Restoring the current DB to another server is pretty straight forward, I guess the important thing is how you want to access the data.

 

-jon

[Anon Anon]

Our NimsoftSLM database is currently 5.5 TB running on a clustered Sql
Server with a 3PAR shared storage running on pure SSD. Each of the two
nodes have 144GB RAM and dual E5630 (2.53GHz) CPU. We get over 1GB/s
against the disks.

 

UMP is snappy as ever (or close enough at least), and we have no
problems graphing arbitrary periods on a number of different qos with
things like PRD.

 

The 3 biggest tables are:

TABLE                             ROWS                DATA      INDEX    QOS
RN_QOS_DATA_0007    7.146.672.622    621GB    114GB    QOS_DISK_USAGE
RN_QOS_DATA_0008    6.149.095.413    532GB    105GB    QOS_CPU_USAGE
RN_QOS_DATA_0016    6.113.560.258    527GB    104GB    QOS_DISK_USAGE_PERC

 

However, there is a problem with the default way SQL Server Updates
statistics on tables which caused us some problems. It only updates
statistics if more than 500+20% of the rows are changed/updated/added.
On large tables (like the ones above), this causes the statistics to
not be updated often enough and the result is that sql server will use
the wrong index for the queries depending on what period you are
graphing.

 

Updating the trace flag to make it use dynamic thresholds based on row
count to decide when it should update the statistics for most parts
solves this problem.

 

Bottom line, the trace flag might help you out, and you can always buy
yourself out of the problem with more hardware

[Daniel Blanco]

Thanks for the feedback. We are constantly tweaking our QoS data collection for each probe to minimize overal db size.

 

Does anyone know if there is  a database rebuild tool w/in Nimsoft? 

 

Anders, with the specs you provided for thta db, how many robots are you monitoring and for how long do you retain the data? Ours is set to 180 days and we have about 1000 robots but many of those have VMProbe which could contain 1000's of VM's. 

 

Thanks. Dan

 

[Anon Anon]

Scripts för creating the dB are in data_engine probe folder. I dont think the scripts for UMP are available.

-jon

[Anon Anon]

I asked support about that a short while ago. The response was something along the lines of "why would you want to do that.  no that's not supported."

 

 

[becph01]

Hi Ray,

 

Have you taken a look at your indexes? Are there any traces showing where the queries are being slow? Sometimes adding an additional index speeds things up signiicantly.

 

Are we sure it's the database that's slowing it down?

 

 

[Anon Anon]

Dan, We are monitoring roughly 5500 robots with a retention time of 13 months (403 days). The current retention is from January 1st 2014. For most parts, it's mainly qos up to OS level. Numbers will increase when we do more network and application qos.