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

  • It's daily maintenance in global file, which runs by default at noon if it's not disabled, or changed: 

    # DailyMaintenanceTime=HH:MM

    When it runs old sessions, session messages and dcbf files for unprotected media are purged.

    An indirect indication of daily purge running would be 0KB file with modification time of 12:00 PM in your IDB messages folder eg: 


    Directory of C:\ProgramData\OmniBack\server\db80\msg\2016\01

    01/31/2016 10:00 AM <DIR> .
    01/31/2016 10:00 AM <DIR> ..
    01/31/2016 12:00 PM 0 01-0001
    01/01/2016 09:00 AM 3,740 01-0002
    01/31/2016 12:00 PM 0 01-0003
    02/01/2016 12:00 PM 0 02-0001
    01/02/2016 09:00 AM 3,740 02-0002

    The need for readdb and writedb is  taken care of by postgres autovacuum http://www.postgresql.org/docs/9.5/static/routine-vacuuming.html

    It's enabled by default in postgresql.conf file: 

    #------------------------------------------------------------------------------
    # AUTOVACUUM PARAMETERS
    #------------------------------------------------------------------------------

    #autovacuum = on # Enable autovacuum subprocess? 'on'

  • AutoVacuum is not enabled

    If i remove the # and enable the Autovaccum, when will this Autovaccum be performed.

    What else need to ne enabled to have no impact to backups.

    As per below note it requires track_counts to also be on. Any thing else. Please share more info and bext way to enable AutoVacuum.

    # AUTOVACUUM PARAMETERS
    #------------------------------------------------------------------------------

    #autovacuum = on # Enable autovacuum subprocess? 'on'
    # requires track_counts to also be on.
    #log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
    # their durations, > 0 logs only
    # actions running at least this number
    # of milliseconds.
    #autovacuum_max_workers = 3 # max number of autovacuum subprocesses
    # (change requires restart)
    #autovacuum_naptime = 1min # time between autovacuum runs
    #autovacuum_vacuum_threshold = 50 # min number of row updates before
    # vacuum
    #autovacuum_analyze_threshold = 50 # min number of row updates before
    # analyze
    #autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum
    #autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze
    #autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum
    # (change requires restart)
    #autovacuum_vacuum_cost_delay = 20ms # default vacuum cost delay for
    # autovacuum, in milliseconds;
    # -1 means use vacuum_cost_delay
    #autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for
    # autovacuum, -1 means use
    # vacuum_cost_limit


  • wrote:

    I want to do purge and readdb and write DB.


    Why? Cargo cult?

    The whole raison d'être for the IDB change between 7.0 and 8.0 was to get rid of the very reasons that made this procedure necessary before. The old IDB had a file name part that managed to reduce the total space necessary for storing every single path name in all of the backups, mainly by having every unique name stored just once and optimized further by chopping them up into path components of various lenghts. The disadvantage was that environments with a large influx of new (never seen before) path names and - as a result - a large rate of path names getting obsoleted when backups expired, would accrete a pile of filename junk in that part of the IDB. So much you had to regularly purge it. And that alone would only make things worse, as the resulting comb of a fragmented DB table, when filled again from the beginning, would turn into a tragic source of random read access on every following IDB check or backup, with times required for these operations exploding into multiple hours. So to get rid of the fragmentation caused by purge, you had to dump and restore the IDB in place, as this would compact it down to the remaining filename entries and make it more linear access, specifically when it started to grow again.

    Now all this is thankfully gone. The PostgreSQL part is just the client, object, session, device and media metadata and even with vast numbers of media, it is of a trivial size and doesn't need any significant maintenance. The filenames are now part of the DCBFs which has one drawback: They are now much larger. There is no more filename deduplication as we had it before. But this also means that filenames are coming (with backups) and going (with recycling of expired media) fully automatically as DCBFs are coming and going. There is no more explicit maintenance here, it's implicit in the DCBF lifecycle. A classic time-space-tradeoff in the end. And we're speaking of human time here, given how long a purge/writedb/readdb maintenance operation could take and occupy my full attention (lest I wreck the entire installation with a wrong spell). Now we have something else to find to do with this time. Luckily, there's enough other issues in DP8/9 to waste it with ;)

    HTH,
    Andre.

  • 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.

Reply Children
No Data