Rainer, Good and bad news...
> > That sounds really great. Before you start coding or preparing > > anything, let me check how well our DBs perform, because it's not > > yet clear if they'll be able to cope with the high insertion rate we > > expect. If we don't go for the Oracle database this work doesn't > > make sense. I bet we'll want the Oracle, anyways. > > Sounds fair. Good news: I did my tests and, for many tasks I need to do, Oracle is our way to go. So, I'm willing to write the module, with your guidance/advise. As I said, I need **excellent** performance. I definitely need batch operations, the ability to prepare the statements given as arguments on the configuration file, and not to commit entries one by one, but after a number of entries are ready or (better) after some not so small time. According to the advise I got from experts around here, I'll have to use Oracle Call Interface for this module, I don't know if there are any licensing issues. It seems I'll have to review how rsyslog's queing modules work... > > For this evaluation, I already have a timestamp formatter that fits > > into Oracle, something that can be used with the property replacer, > > like %timereported:::date-oracle%. > The bad news is that this timestamp formatter works perfectly on interactive sessions (sqlplus) but not on non-interactive ones, f.i, in Python scripts. You need to call Oracle's to_timestamp(string, format), and by bloating your code with this ugly function the rfc-3339 formatter is good enough. So I won't submit this one. Cheers. -- Luis Fernando Muñoz Mejías [email protected] _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
