Bug 797325 - RHQ_ALERT_NOTIFICATION created with NOLOGGING option in Oracle
RHQ_ALERT_NOTIFICATION created with NOLOGGING option in Oracle
Status: CLOSED DUPLICATE of bug 814839
Product: RHQ Project
Classification: Other
Component: Database (Show other bugs)
All All
high Severity high (vote)
: ---
: JON 3.1.0
Assigned To: John Mazzitelli
Mike Foley
Depends On: 814839
Blocks: jon310-sprint11/rhq44-sprint11
  Show dependency treegraph
Reported: 2012-02-24 18:17 EST by Marc Shirley
Modified: 2012-04-25 08:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-04-25 08:50:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
logging in oracle schema (27.27 KB, image/png)
2012-04-20 14:35 EDT, Mike Foley
no flags Details
my server log (574.91 KB, application/octet-stream)
2012-04-20 15:38 EDT, Mike Foley
no flags Details
turn on oracle logging on relevant tables (6.46 KB, text/x-sql)
2012-04-24 15:51 EDT, John Mazzitelli
no flags Details

  None (edit)
Description Marc Shirley 2012-02-24 18:17:51 EST
Description of problem:
RHQ_ALERT_NOTIFICATION table is created with the NOLOGGING option in an Oracle schema, but should be created without the option as it concerns configuration.  In the case of a database issue on the user side and the user relying on redo logging to rebuild the database, the usage of NOLOGGING means that the user will have to manually review the alert notification configuration for every alert in order to confirm that their notifications are properly configured.  

Depending upon the number of alerts, this could require many man hours to verify, or could mean that a user relying on the notifications for monitoring will overlook error/warning states that they should have been aware of if they do not check that the RHQ_ALERT_NOTIFICATION table was restored properly.

Version-Release number of selected component (if applicable):
RHQ 4.2.0/JON 3.0.0
Comment 1 Mike Foley 2012-02-27 12:03:36 EST
triage asantos, mfoley, crouch, loleary  ...JON 3.1
Comment 2 John Mazzitelli 2012-04-04 16:59:07 EDT
looks like we should be removing the NOLOGGING option from RHQ_ALERT_NOTIFICATION table.

The work around until we patch the dbsetup/dbupgrade code is to run the SQL:

alter table rhq_alert_notification logging
Comment 3 John Mazzitelli 2012-04-05 11:17:47 EDT
master commit aea4f08 adds dbsetup and dbupgrade code to enable oracle logging on rhq_alert_notification table.
Comment 4 Mike Foley 2012-04-20 14:35:00 EDT
attaching an image which shows RHQ_ALERT_NOTIFICATION table still has LOGGING=NO.

marking failed to verify.
Comment 5 Mike Foley 2012-04-20 14:35:29 EDT
Created attachment 579078 [details]
logging in oracle schema
Comment 6 Mike Foley 2012-04-20 15:38:17 EDT
Created attachment 579091 [details]
my server log
Comment 7 John Mazzitelli 2012-04-20 16:06:56 EDT
I'm reverting this until bug #814839 is discussed. It turns out, EVERY table has NOLOGGING enabled. Read bug #814839 for the conversation. Teh current thinking is we do not want or need LOGGING.
Comment 8 John Mazzitelli 2012-04-20 16:13:14 EDT
revert 6ef74e9
Comment 9 John Mazzitelli 2012-04-24 15:51:50 EDT
Created attachment 579978 [details]
turn on oracle logging on relevant tables

see attached for a .sql file you can execute to turn on LOGGING on all relevent tables. Use this if you want to enable LOGGING on RHQ database tables if you already have RHQ installed.

See bug 814839 for tracking the issue of fixing this on initial install.
Comment 10 John Mazzitelli 2012-04-25 08:50:28 EDT
closing this as duplicate - see bug #814839

*** This bug has been marked as a duplicate of bug 814839 ***

Note You need to log in before you can comment on or make changes to this bug.