CLDB Cache compact and signture cleanup question

Last post 01-21-2015, 1:19 PM by Sonny St James. 3 replies.
Sort Posts: Previous Next
  • CLDB Cache compact and signture cleanup question
    Posted: 01-21-2015, 10:30 AM

    CV v10 SP7

    I was wondering if anyone knows what goes on during the compact of the CacheTable files that are generated from the DASH copies using the network optimised option. During a seeding process, this cache reaches sizes of over a gig or two, holding a few million signatures, however after a coopact, the size is reduced, and the signatures as well.

    I am thinking that if the compact task cannot gain full access to the file, (Being in use by a DASH task) that it corrupts the file. (Or resets it) Which obviously impacts the DASH process by sending all the signatures over the wire for verification.

    Has anyone had similar experiences with this?

    Maybe this issue is resolved in SP8. I understand there was some work to remove the size limitations of the Cache.

    Thanks

    Sonny

  • Re: CLDB Cache compact and signture cleanup question
    Posted: 01-21-2015, 10:34 AM
    • Ali is not online. Last active: 07-03-2019, 12:32 PM Ali
    • Top 10 Contributor
    • Joined on 08-05-2010

    Hi Sonny,

    Personally haven't seen this, however if you log files from such a scenario where the failure occured, may we ask to log an incident with Support for further review.

    Also do you recall the error message/code you recieved during this situation?

  • Re: CLDB Cache compact and signture cleanup question
    Posted: 01-21-2015, 10:51 AM

    I dont see any errors during the compact period. I have logged similar issues before, but have found that when a compact process occurs, the next job resets the cache totally.

    Mind you I have seen a server reboot also corrupt this cache and froce it to start over. Its really a very fragile cache. I wish CVwould allow the backup of it, but I think its hardcoded to avoid this directory using an agent.

    Fortunately, I make copes of this cache manually when I am expecting a large transfer, like a large data addition, or WAN downtime and there is a job buildup. Replacing the cache with the backup restores the WAN utilization to where it is intended to be.

    Sonny.

  • Re: CLDB Cache compact and signture cleanup question
    Posted: 01-21-2015, 1:19 PM

    Following your breadcrumbs of logging errors, I may have identified why the files are reset:

     

    From the CLDBEngine.log:

    7104  1a54  01/21 11:59:49 616579 CLDBProcessor::DumpCounters: Engine [CLDBEngine_clmpadbk01_0_87], Msg Handler [CLDB Signture Query Handler], Time [6.942541], Invoked [55971], Avg [0.000124], Total Time [66.728307], Total Invoked [494128], Total Avg [0.000135]
    7104  1a54  01/21 11:59:49 616579 CLDBProcessor::DumpCounters: Engine [CLDBEngine_clmpadbk01_0_87], Msg Handler [CLDB  Signture Insert Handler], Time [0.000000], Invoked [0], Avg [0.000000], Total Time [0.214720], Total Invoked [800], Total Avg [0.000268]
    7104  1a54  01/21 12:09:49 616579 Active connections = 16, Last connect time = Wed Jan 21 11:16:06 2015
    7104  1a54  01/21 12:09:52 616579 CCLDBTableManager::IsDBClean isCopyClientCacheDBClean [Job-Id - 616579 ][Copy id - 87] returns No
    7104  1a54  01/21 12:09:53 616579 AdminThread: CLDB found Out of Sync with SIDB. Will be quiting CLDBService...
    7104  1a54  01/21 12:09:53 616579 Waiting for the thread pool to empty itself...
    7104  1a54  01/21 12:09:53 616579 Telling the server to stop and abort all connections.
    7104  1a54  01/21 12:09:53 ###### cvtlGGzzRixxasvvoWiivziiv::Quit() - Quit is received.
    7104  1c5c  01/21 12:09:53 ###### cvtlGGzzRixxasvvoWiivziiv::ListenThread() - ListenThread is exiting.
    7104  1c5c  01/21 12:09:53 ###### cvtlGGzzRixxasvvoWiivziiv::Quit() - Quit is received.
    7104  1fcc  01/21 12:09:53 ###### CCvNsAsyncSocketLayer::CleanUp() - Waiting for IOCP threads to come down
    7104  1fcc  01/21 12:09:53 ###### CCvNsAsyncSocketLayer::CleanUp() - IOCP threads are down now
    7104  1a54  01/21 12:09:54 616579 Dumping Handler Counters.
    7104  1a54  01/21 12:09:54 616579 CLDBProcessor::DumpCounters: Engine [CLDBEngine_clmpadbk01_0_87], Msg Handler [CLDB Signture Query Handler], Time [8.128925], Invoked [61815], Avg [0.000132], Total Time [74.857232], Total Invoked [555943], Total Avg [0.000135]
    7104  1a54  01/21 12:09:54 616579 CLDBProcessor::DumpCounters: Engine [CLDBEngine_clmpadbk01_0_87], Msg Handler [CLDB  Signture Insert Handler], Time [0.000000], Invoked [0], Avg [0.000000], Total Time [0.214720], Total Invoked [800], Total Avg [0.000268]
    7104  1a54  01/21 12:09:54 616579 DeInitializing Message Handlers.
    7104  1a54  01/21 12:09:54 616579 AdminThread Cleanup done! Exiting...
    7104  1fcc  01/21 12:09:54 616579 CVNetworkServer exits, return code is 0

    I think the act of replacing the corrupt SIDB cache with a backup is putting the signatures out of sync with the destination DDB and resetting the file, starting from scratch. This does however cause a much larger data transfer over the WAN as all signatures need to be compared and recorded in the new CacheDB.

    Do you think it would be worth generating a new cacheDB using a copy at the destination of all the data already located in the copy? I could then transfer that cacheDB back to the source as the current cacheDB. Similar to the seeding process for new Media agent content?

    Thinking out loud.

    Sonny.

The content of the forums, threads and posts reflects the thoughts and opinions of each author, and does not represent the thoughts, opinions, plans or strategies of Commvault Systems, Inc. ("Commvault") and Commvault undertakes no obligation to update, correct or modify any statements made in this forum. Any and all third party links, statements, comments, or feedback posted to, or otherwise provided by this forum, thread or post are not affiliated with, nor endorsed by, Commvault.
Commvault, Commvault and logo, the “CV” logo, Commvault Systems, Solving Forward, SIM, Singular Information Management, Simpana, Commvault Galaxy, Unified Data Management, QiNetix, Quick Recovery, QR, CommNet, GridStor, Vault Tracker, InnerVault, QuickSnap, QSnap, Recovery Director, CommServe, CommCell, SnapProtect, ROMS, and CommValue, are trademarks or registered trademarks of Commvault Systems, Inc. All other third party brands, products, service names, trademarks, or registered service marks are the property of and used to identify the products or services of their respective owners. All specifications are subject to change without notice.
Close
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy