Bug 1409766
| Summary: | [RFE] Provide a tool to execute vacuum full on DWH database | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine-dwh | Reporter: | Shirly Radco <sradco> |
| Component: | Setup | Assignee: | Shirly Radco <sradco> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Lucie Leistnerova <lleistne> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | --- | CC: | bgraveno, bugs, didi, emesika, lleistne, lsvaty, mgoldboi, mperina, oourfali, pstehlik, rgolan, sradco, ylavi |
| Target Milestone: | ovirt-4.2.0 | Keywords: | FutureFeature, Performance |
| Target Release: | 4.2.0 | Flags: | rule-engine:
ovirt-4.2+
rule-engine: exception+ lsvaty: testing_plan_complete+ mgoldboi: planning_ack+ mperina: devel_ack+ lsvaty: testing_ack+ |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: |
This release adds a maintenance tool to run vacuum actions on the DWH database or specific tables.
The tool optimizes table stats and compacts the tables, resulting in less disk space usage. This allows for more efficient maintenance, and the updated table stats allow for better query planning.
Also provided is an engine-setup dialog that offers to perform vacuum during upgrades. This can be automated by the answer file.
|
Story Points: | --- |
| Clone Of: | 1388430 | Environment: | |
| Last Closed: | 2017-12-20 10:59:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1388430 | ||
| Bug Blocks: | 1475130, 1631198 | ||
|
Description
Shirly Radco
2017-01-03 09:57:38 UTC
This RFE is specifically for DWH? I believe the current engine tool should be modified so we can run it on both dbs, or even make it general so it can be run on any db , if db credentials are provided. For engine and ovirt_engine_history dbs, Will only need to supply the db name. (In reply to Shirly Radco from comment #2) > I believe the current engine tool should be modified so we can run it on > both dbs, or even make it general so it can be run on any db , if db > credentials are provided. > For engine and ovirt_engine_history dbs, Will only need to supply the db > name. So why open a bug on DWH? The engine tool and setup plugin is ready see Bug 1388430. This RFE is to allow that to dwh. I changed the RFE name so it won't suggest the solution, but the requirement, to have such a tool for dwh as well. This is unrelated to metrics. You should make the tool available to both DBs, I'm not sure it was engine only focused to begin with. Any updates on this RFE? Talked to Yaniv L, Re-targeted to 4.2. Running dwh-vacuum with active dwh services could end up in deadlock with dwh selects. Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release. Running vacuum when the service is up is strongly discouraged and there is simply no reason to do it. PG already has the auto-vacuum daemon, which does just that. The tool is intended to work in the maintenance window time, specially when you want to do full vacuum in order to reclaim space, and where it takes an exclusive lock on the table. If you want it on automation, make sure you stop the service, it is not the job of the tool to stop the service, because you may want to run vacuum forcibly, or just analyze and it will work just fine. A reminder, the tool is just a thin wrapper around pg's vacuumdb. Please read the docs. Alright, the tool is otherwise working so I'll set to verified. And I created Bug 1490941 that this should be mentioned in tools help. verified in ovirt-engine-4.2.0-0.0.master.20170907100709.git14accac.el7.centos.noarch This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017. Since the problem described in this bug report should be resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |