Bug 797325

Summary: RHQ_ALERT_NOTIFICATION created with NOLOGGING option in Oracle
Product: [Other] RHQ Project Reporter: Marc Shirley <mshirley>
Component: DatabaseAssignee: John Mazzitelli <mazz>
Status: CLOSED DUPLICATE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: high    
Version: 4.2CC: hrupp, mazz
Target Milestone: ---   
Target Release: JON 3.1.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-25 12:50:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 814839    
Bug Blocks: 782579    
Attachments:
Description Flags
logging in oracle schema
none
my server log
none
turn on oracle logging on relevant tables none

Description Marc Shirley 2012-02-24 23:17:51 UTC 
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 17:03:36 UTC 
triage asantos, mfoley, crouch, loleary  ...JON 3.1
Comment 2 John Mazzitelli 2012-04-04 20:59:07 UTC 
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 15:17:47 UTC 
master commit aea4f08 adds dbsetup and dbupgrade code to enable oracle logging on rhq_alert_notification table.
Comment 4 Mike Foley 2012-04-20 18:35:00 UTC 
attaching an image which shows RHQ_ALERT_NOTIFICATION table still has LOGGING=NO.

marking failed to verify.
Comment 5 Mike Foley 2012-04-20 18:35:29 UTC 
Created attachment 579078 [details]
logging in oracle schema
Comment 6 Mike Foley 2012-04-20 19:38:17 UTC 
Created attachment 579091 [details]
my server log
Comment 7 John Mazzitelli 2012-04-20 20:06:56 UTC 
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 20:13:14 UTC 
revert 6ef74e9
Comment 9 John Mazzitelli 2012-04-24 19:51:50 UTC 
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 12:50:28 UTC 
closing this as duplicate - see bug #814839

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