I have one client that I currently cover about 400 pieces of equipment that will be expanding to about 2000 in the next few months.

In managing such a large amount of equipment with RBMWare, do you prefer to keep it all in one database or separate it into several smaller ones?

I would always suggest "smaller" databases always have. Small database small problem, large database huge problem. Olov

I prefer to have my data bases set up by area and or machine. For example, data bases would be Furnaces. Routes in that data base would be 19 furnace, 22 furnace, steam & power etc. I then have several smaller routes made up in each route. Examples of routes would be 19 furnace basement, 19 furnace top to bottom, same for 22 furnace.
There are some limits to the size of routes. I have one route that I had to divide into two because there were more collection points than one route file would hold.
Not sure this is of much help, but it's how we do it here.
Ron

This message has been edited. Last edited by: Racer98,

We have a little over 900 pieces of equipment in one database. They are divided into 45 stations or areas. It is very easy to manage and I would not want to break it down into smaller databases. With databases not having a file size limit anymore, I can't see what you would gain in doing so. I don't have to change databases to look at different data and at least one step is elliminated when loading routes.
We also have other databases for different customers that are much smaller, some with less than 100 pieces of equipment, and I still would not want the 900+ size database broken down.

Ronnie

Smaller is better, If you have one large data base and someone changes one machine, then you don't reload the data collector before you collect more data you will have a very hard time downloading the data.

Has something changed with the latest versions of MHM? There used to be a 2GB cap on the DB size....

I haven't upgraded to the latest version of RBM, but I think you can have multiple databases open at once. I don't see the problem with having multiple databases for one plant. Not sure it makes a functional difference. Perhaps it's just a matter of personal preference... not wrong or right way.

Well my motivation is that each database used to be a file (don´t know if they finally moved to a sql database engine that may make things complicated to another level) and if that file got messed up by software, Billy G.(windows) or the smurf´s you still got the other databases and the larger the database the larger the file and the risk for meltdown increase by square of file size in my experience. In a smaller database you will have less things to fix, repair or abandon... Also speed to retrieve data is database size dependent in most systems...... If you keep backups you have no problems anyway? Maybe it´s memory's from old days when database collapse did happen once in awhile that influence me to be restrictive. Maybe the world now is perfect? Take care of your databases anyway. Olov

The good folks at CSI were kind enough to send me this tech note about database size. This technote is specified for v 4.70 and I have asked for confirmation that it is still true, but believe that it is.

http://www.mhm.assetweb.com/DR...055A564?OpenDocument

The 2 gig limit pretty much makes my decision for me, but I am leery of having to make the same changes to AP and AL sets several times.

Thanks to all for the input.

Thanks for posting that document Danny. At the present growth rate of our database we will reach the 2 GB limit in about a year or a little over a year. I guess we will be archiving data or splitting our database up. I still like having one large database but just not as much now

Thanks,
Ronnie

quote:

The 2 gig limit pretty much makes my decision for me, but I am leery of having to make the same changes to AP and AL sets several times.

I agree on the 2 gig making the decision, even though having all my eggs in the same basket or maybe not having them all in the same basket, made up my mind many years ago before RBM came out and DOS was the king, but I do not understand the last thing said about "AP and AL sets several times." Maybe there is an easy way for this if I knew what you needed or was referring to.


Email me if you had rather, than trying to explain it here.
Ralph_Stewart@alertanalytical.com

Ralph,

What I'm referring to is that if I make a change in an AP set and just have one database, the change is made globally. If I split my database into multiple databases and I want to make such a change, I'll have to make it in every database.

And I received confirmation that the tech note applies to all versions.

Danny,

When making the different database, make sure all have the same numerical number and the same setting and use DButly to copy to all databases after changing one set in one database. Use the overwrite option.

dear danny,

with single database is u can manage ur back-up copy well, on the other hand u will have little problem with big database that you can create route for limited equipment(1024points only) for that you have to create different equipment& even for small changes in data base you have to make hammering it will consume lot of time.

Is there no way in RBM to have a "master" AP & AL set list, such that changes are pushed into all associated databases? Seems that would be one of the most "obvious" needs for database management.

I seldom change an AP set once I have it set up. I hope everyone realizes that you should NEVER change an existing AP set once you have collected data on a machine, except to add additional parameters. Changing existing AP sets will totally screw up your trend data. (Is there a way to recalculate trend data once it is "scrambled" by changing the AP set? Guess I should have taken the training.)

Database management, including AP & AL sets, is a necessary evil.

And YES!! we still need the equivalent of the old MRL files for automatic route loading.... the point and click method may be fine for computer geeks, but it TOTALLY SUCKS for real world data collection!!!! (can you tell I feel strongly about this?)

This message has been edited. Last edited by: rustythevibeguy,

Rusty,

In the Autostat package, there is the facility to re-calculte the trend data, if the trends are derived from the stored spectrums/waveforms. The HFD data can't be re-calculated.

Ian

Rusty,

I have a set of standard AP and AL sets that I have developed and use that as a basis for all databases. Then I add them (or very carefully change them*) as required.

*not recommended for beginners

You forgot to put "totally sucks" in bold letters so maybe you aren't angry enough yet.

quote:

You forgot to put "totally sucks" in bold letters...

OK... fixed it. Thanks, Danny.