Thanks. Do you write to the same DB or a separate logging/audit DB?
Sent from my iPhone
On Jan 16, 2016, at 7:31 AM, RajeevGM <rprabha01@xxxxxxxxx> wrote:--
Hi Jeff,
I don't know if this is an industry wide practice to write audit/logging data
to a database, but, we do have it this for one of the applications I work
with.
The way it is designed at our place is that the application process /
services are able to "move on" in case the audit db is not available. i.e. It
is an optional write and it has the feature to save it on the o.s (xml files)
if the audit db were to be unavailable. So far the performance (related to
writing the audit data) has not been an issue b/c, the writes are very small.
Hope this helps ?
Rajeev
On Jan 15, 2016, at 5:50 PM, Jeff <backseatdba@xxxxxxxxx> wrote:
I know this is not directly a DBA question but I thought maybe someone would
have some experience.
My web team is wanting to implement a logging service which will log all
calls to their web services and info about who and what was called. And so
they are wanting to store this in the database in some table or tables.
Which basically means that every call to the database will generate an
additional call for logging. To me this seems like a bad idea to store in
the database. I am either thinking of creating a separate database just for
logging or well I don't know. I suggested just writing it all to a file and
use something like Splunk but for some reason which I haven't found out yet
they said that would not work for them.
Any suggestions/advice? Is this normal practice to log back to the database?
