I wish to do IDB maintenance in Data Protector 9.0

I wish to do IDB maintenance in DP 9.0, Which command to execute or please confirm if it is same as we do in DP 6/7 version.

Parents
  • Hi tabrez16,

    what's your goal with this? There is a manual procedure for old raima database in versions prior 8.0, that is no longer needed with new postgresql IDB. Its autovacuum procedure takes care of this 

  • I want to do purge and readdb and write DB.

    Is the process same for DP9 as we do in DP6/7 version.

    Or any other commands need to be executed to perform purge and read write.

    if it is done automatically, please confirm me which parameter need to be checked to verify it is done or not. is there any global parameter to be checked to verify whether it is happening automatically or not

  • Guys,

    tabrez16 brings up a valid point.  This got me thinking, and I decided to check my postgresql.conf file.  I see the same thing: #autovacuum = on - which, according to the .conf file itself ("Comments are introduced with # ANYWHERE on a line" [emphasis is mine]), means this is commented out.

    So, HPE folks: Does this mean the autovacuum is running or not?  Is there another file that I need to look at  (other than \ProgramData\OmniBack\server\db80\pg\postgresql.conf)?

    Thanks

    Ken

  • Guys,

    tabrez16 brings up a valid point.  This got me thinking, and I decided to check my postgresql.conf file.  I see the same thing: #autovacuum = on - which, according to the .conf file itself ("Comments are introduced with # ANYWHERE on a line" [emphasis is mine]), means this is commented out.

    So, HPE folks: Does this mean the autovacuum is running or not?  Is there another file that I need to look at  (other than \ProgramData\OmniBack\server\db80\pg\postgresql.conf)?

    Thanks

    Ken

  • Hi Ken,

    I don't really know for sure, but I'd think that

    # The commented-out settings shown in this file represent the default values.

    would mean that all the values found in the autovacuum parameters section, while commented out, just state the compiled-in defaults. Clarification on that by HPE would be great, of course.

    HTH,
    Andre.

  • Dimitar was guiding us to the right direction already. Starting with Data Protector 8.0 we're using PostgreSQL 9.1 as the Internal Database. Even when autovacuum is commented out in postgresql.conf is will run by default. This can be seen much better on UNIX Cell Managers when looking at the ps command output.

    Daily maintenance will purge obsolete items from IDB and autovacuum take care of the rest.

    autovacuum (boolean)
    Controls whether the server should run the autovacuum launcher daemon.
    This is on by default; however, track_counts must also be enabled for autovacuum to work.
    This parameter can only be set in the postgresql.conf file or on the server command line.

    (https://www.postgresql.org/docs/9.1/static/runtime-config-autovacuum.html)

    Hope this helps!

    Regards,
    Sebastian Koehler

  • Sebastian,

    So, based on earlier replies and yours, I'm presuming that finding a line like

    #track_counts = on

    in the postgresql.conf file means the same thing, that track_counts is actually enabled and the autovacuum process is then doing its thing, happily chugging away sucking all the crud out of my >260 GB DCBF folder structure?

    Thanks

    Ken

  • Hi Ken,

    sorry to disappoint you, but autovaccum has nothing to do with the DCBF part. :)

    Autovaccum will take care of what is stored in the DatabaseFiles part of the IDB. Based on my experience the DatabaseFiles part is less than 1% of the whole IDB. You can check that with omnidbutil -info or a recent IDB backup (objects size) for the current size. With 260 GB DCBFs you should have 1-2 GB DatabaseFiles.

    The DCBFs part is maintained by daily mainteance usually running at 12:00 o'clock. For exmaple, if catalog protection of a cartridge expires the catalog data is purged from disk. If a media is overwritten the DCBF will be deleted and recreated. If a media is expired, the DCBF is deleted. Of course references to the DCBFs are stored in the DatabaseFiles part of the IDB. But the vast majority of the data (fnames, etc) are stored in the daily catalog binary files.

    And yes, track_counts is also on by default.

    track_counts (boolean)
    Enables collection of statistics on database activity. This parameter is on by default, because
    the autovacuum daemon needs the collected information. Only superusers can change this setting.

    Regards,
    Sebastian Koehler

     

  • Sebastian,

    Thanks for the clarification.  My database grew a lot early and as we import more servers from other cells it keeps growing, but it appears to have stabilized.  The only thing I'd say is make it easier to install DP to something OTHER than C:.  I don't like my C: drives getting real big, and we generally like to keep apps off the C: on our servers.

    I do think the integration with StoreOnce Catalyst has been a good thing in terms of media management and keeping the database size under control.  It has really reduced our media management workload.

    All previous comments about DP 9 aside, it has allowed me to (at this point) consolidate some 40 cells into one, and another dozen or so will soon join the consolidation.

    Thanks

    Ken

  • Sebastian,

    Thanks for the clarification.  My database grew a lot early and as we import more servers from other cells it keeps growing, but it appears to have stabilized.  The only thing I'd say is make it easier to install DP to something OTHER than C:.  I don't like my C: drives getting real big, and we generally like to keep apps off the C: on our servers.

    I do think the integration with StoreOnce Catalyst has been a good thing in terms of media management and keeping the database size under control.  It has really reduced our media management workload.

    All previous comments about DP 9 aside, it has allowed me to (at this point) consolidate some 40 cells into one, and another dozen or so will soon join the consolidation.

    Thanks

    Ken

  • Sebastian,

    Thanks for the clarification.  My database grew a lot early and as we import more servers from other cells it keeps growing, but it appears to have stabilized.  The only thing I'd say is make it easier to install DP to something OTHER than C:.  I don't like my C: drives getting real big, and we generally like to keep apps off the C: on our servers.

    I do think the integration with StoreOnce Catalyst has been a good thing in terms of media management and keeping the database size under control.  It has really reduced our media management workload.

    All previous comments about DP 9 aside, it has allowed me to (at this point) consolidate some 40 cells into one, and another dozen or so will soon join the consolidation.

    Thanks

    Ken

  • Hi tabrez16,

    it seems this discussion brought up some useful items. If you're ok with the answers, please mark this topic as resolved.

    Regards,
    Sebastian Koehler

Reply Children