Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1037508 - sw-system-snapshot blows up UNDO_TBS and failes because of to large transactions
Summary: sw-system-snapshot blows up UNDO_TBS and failes because of to large transactions
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server
Version: 560
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Jan Dobes
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: sat560-triage
TreeView+ depends on / blocked
 
Reported: 2013-12-03 09:59 UTC by Luc de Louw
Modified: 2018-04-09 11:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-09 11:04:36 UTC


Attachments (Terms of Use)

Description Luc de Louw 2013-12-03 09:59:56 UTC
Description of problem:
A Satellite Server which is in use since years having many systems subscribed to it tends to have a huge amount of snapshots stored in the database.

A solution is to run sw-system-snapshot.


Version-Release number of selected component (if applicable):
spacewalk-utils-2.0.2-12

How reproducible:
Always

Steps to Reproduce:
1. Register a few hundreds or thousands of server and let the snapshot tables grow 
2. sw-system-snapshot -u admin -p password --start-date=200001010000 --end-date=201312030000 --all --delete


Actual results:
ISE 500 and a python traceback, while the database query is still running for several hours. Eventually the database transaction failes and a roll-back occures. 

The root cause seems that the deletion of all data is done in one single and huge transaction.


Expected results:
Smaller transactions (more commits) which 1. do not blow up UNDO_TBS and 2. Having at last some transactions done when a timeout occures.



Additional info:
It seems that the tables affected have no or wrong indexes.

Comment 4 Tomas Lestach 2018-04-09 11:04:36 UTC
We have re-reviewed this bug, as part of an ongoing effort to improve Satellite/Proxy feature and bug updates, review and backlog.

This is a low priority bug and has no currently open customer cases. While this bug may still valid, we do not see it being implemented prior to the EOL of the Satellite 5.x product. As such, this is being CLOSED DEFERRED. 

Closing now to help set customer expectations as early as possible. You are welcome to re-open this bug if needed.


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