thanks for the answer.
We are also interested in using Oracle on some systems, but I don't know which version is actually needed.
Do you use "Oracle Database 12c Enterprise Edition", "Oracle Database 12c Standard Edition" or "Oracle Database 12c Standard Edition One" for this system?
Your favourite database for db logging?
Search
Re: Your favourite database for db logging?
you can use EE oder SE with WinCC OA. The SE One is not available anymore (from Oracle), it was replaced with SE2.
https://www.oracle.com/database/standar ... index.html
https://www.oracle.com/database/standar ... index.html
Re: Your favourite database for db logging?
@Gertjan
I am also looking forward to test Cassandra, i hope i will find time to install cassandra nodes and add a cassandra plugin for my "NoSQL Logger".
fragment indexes can be the issue. Oracle isn't doing a rebuild automatically.
HBase uses LSMT (Log Structured Merge Trees). And it has a "load balancer" which will split and distribute regions (data partitions) across the data nodes.
InfluxDB is also using some kind of LSMT - a time structured merge tree (https://influxdb.com/docs/v0.9/concepts ... merge-tree)
PS.: redis, take a look on Apache Ignite, a distributed memory cache, seems to be very cool - https://ignite.apache.org/use-cases/compare/redis.html
I am also looking forward to test Cassandra, i hope i will find time to install cassandra nodes and add a cassandra plugin for my "NoSQL Logger".
fragment indexes can be the issue. Oracle isn't doing a rebuild automatically.
HBase uses LSMT (Log Structured Merge Trees). And it has a "load balancer" which will split and distribute regions (data partitions) across the data nodes.
InfluxDB is also using some kind of LSMT - a time structured merge tree (https://influxdb.com/docs/v0.9/concepts ... merge-tree)
PS.: redis, take a look on Apache Ignite, a distributed memory cache, seems to be very cool - https://ignite.apache.org/use-cases/compare/redis.html
Re: Your favourite database for db logging?
Hello,
Frenk Mulder wrote:
This would mean that in a normal running plant the server will be down for several days or more.
If the hardware and network configuration was done in a proper way the recovery will be done fast, even if a huge amount of data (several GB) will be copied.
For details concerning the recovery please have a look at the following FAQs:
https://portal.etm.at/index.php?view=it ... &Itemid=54
https://portal.etm.at/index.php?view=it ... &Itemid=54
Best Regards
Leopold Knipp
Senior Support Specialist
Frenk Mulder wrote:
from my point of view doing a test where 800.000 alarms are simulated while one server is down isn't a real scenario. Normally in average you get only a few alarms every minute.
1. The redu switching time. When you use the normal raima and value archives then starting your redu server can take quite a while. It can quite easily take half an hour. We did the following test : we turned of one server, we generated 800.000 alarms and then started the second server. The time to start the server was quite impressive. There was no difference between the normal start and this 'start with synchronisation' (because there is no sycnhronisation)
This would mean that in a normal running plant the server will be down for several days or more.
If the hardware and network configuration was done in a proper way the recovery will be done fast, even if a huge amount of data (several GB) will be copied.
For details concerning the recovery please have a look at the following FAQs:
https://portal.etm.at/index.php?view=it ... &Itemid=54
https://portal.etm.at/index.php?view=it ... &Itemid=54
Best Regards
Leopold Knipp
Senior Support Specialist
Re: Your favourite database for db logging?
Gertjan van Schijndel wrote:
Here are the results with Cassandra: http://www.rocworks.at/I mentioned Redis, because it is one of the biggest NoSQL databases. But I am really looking forward to the results with the Cassandra database.
In my experience with MS SQL Server the performance degrades, because the indexes gets fragmented over time and needs to be rebuild to improve the performance again. Do the other databases execute these kind of maintenance jobs out of the box?