How Big are your Odyssey Databases? How big can they be/are there limits? What is a good size? Has anyone seen one get too big? I am using version 2.3.

Jbalko,

THe biggest one I have is 440,000. I don't know if I have seen one to big. I am using Sql Server. It's been a while since I fooled with an oracle db, and I can't remember how big those were.
Are you having trouble with yours?

Dave

no problems, just curious

I have seen 2G Centura Db, but this is not advised 500M max. MSSQL and Oracle can be unlimited.

Emonitor 3.3
MSSQL Database
3Gb
I had the problem only with more than 3 days every 5 secs trend (>50000 samples). This makes Emonitor to think a lot (=restart required) when clicking on that measurement.
Only archive filter helped me at that moment.

Next week I'll try 10Gb database. I could let you know the results.

Alexander,

How are you collecting the data, what is the application?

I think the problem is creation of ULF files to be uploaded using scheduler.

Emonitor is a CBM program, there are other applications which may suit your situation more usefully.

Enlive or RSMACC EOL allow mS update of data that can be viewed at 1 sec intervals.

quote:

How are you collecting the data, what is the application?

It's gas transfer station (7 gas turbines) analyzing and protection system. XMs, Emonitor, RSView32.
XM Emonitor Gateway is getting data every 4 hours (spectras, TWFs). RSView is storing data to the MSSQL datalogs every 5 secs (overall, 1x, 2x, 3x). Then these datalog data in case of alarm is moving to the Emonitor tables in MSSQL. It could be RSSQL instead of RSView32 datalogs.

quote:

I think the problem is creation of ULF files to be uploaded using scheduler.

Yes, it's a bottle neck of the data collection process. ULF files are creating only every 4 hours.

quote:

Emonitor is a CBM program, there are other applications which may suit your situation more usefully.

All this data is required for the analysis.

quote:

Enlive or RSMACC EOL allow mS update of data that can be viewed at 1 sec intervals.

There are no storing capabilities in these software.

Alexander,

I suggest continuing using RSview for trending every 5 secs. Using XM gateway for transferring data to Emonitor every 4 hours should be ok. Why not use Triggered Trend in modules for your analysis instead of transferring all the trend data to Emonitor.

I am sure your problem is data transfer not Emonitor database size.

I use RSMACC EOL as a viewing software for operations. Emonitor XM Gateway runs every 3 minutes. The key I think is to have proper storage parameters set up in Emonitor Odyssey. I also have unload station manager running through Enshare at the same time collecting data from the Enwatch. There are no conflicts in Odyssey except a momentary slow down during database update. I also use the triggered trend capabilities of the XM module itself and store the data in Odyssey. Again no issues at all.

Wayne,

quote:

Why not use Triggered Trend in modules for your analysis instead of transferring all the trend data to Emonitor.

I'm transferring not all data to Emonitor. Triggered trends have only 2048 samples. It's not enough for this application. Standard data collection period is 4 hours. My customer requires every 5 secs overalls in case of alarm level change and above danger threashold, every 10 mins above alert thearshold.

quote:

I am sure your problem is data transfer not Emonitor database size.

It's not data transfer and not DB size. My customer gave me wrong threashold for the turbines. That results in more than 12 million rows=samples in the "singlevaluedata" MSSQL table.

vibbase,

quote:

I use RSMACC EOL as a viewing software for operations.

Unfortunately RSMACC EOL doesn't have datalog capabilities.

quote:

Emonitor XM Gateway runs every 3 minutes. The key I think is to have proper storage parameters set up in Emonitor Odyssey.

How many XMs do you have?

quote:

I also have unload station manager running through Enshare at the same time collecting data from the Enwatch.

To the same measurement definition?

Enwatch is on it's own. RSMACC and Enshare do not like each other very much...........

What do you mean?

The RSMACC configuration utility for Enwatch loads a configuration to the Enwatch. This configuration does not match the configuration loaded from Emonitor through the Hardware setup program. They do not talk to each other. You can collect data from the Enwatch to Emonitor or you can display an overall value in RSMACC but not both. Rockwell is working on this as far as I know.

My entire paper machine and support equipment is about 180 megs and that includes about 2 years of data. No problems at all.