Tape drive performance data - from commserv database table mmdrivehistory ?

Last post 07-21-2010, 5:52 PM by Carlo.G. 4 replies.
Sort Posts: Previous Next
  • Tape drive performance data - from commserv database table mmdrivehistory ?
    Posted: 07-15-2010, 7:14 PM


    This is a long post.  I've tried to include information that may be usefull to other people, and there are 3 questions at the end.

    We are running Commvault Simpana 8,  for backups only (no archive yet), mostly to an LTO4 tape library.

    For a while now we have been trying to find a way to report on tape drive performance measurments for our Commvault backups.    When the backup operators come to me and say "we need more tape drives because backups take too long", I want to know if the problem is really tape drive capacity.  Are we really making good use of the existing drives....getting good thoughput on the all night...or is there some kind of scheduling or performance bottleneck that adding more drives won't really fix?  Those LTO4 drives are supposed to be able to do up to 400GB/hour.  I'll settle for 200GB/hour, but I'm not going to buy more drives if we aren't even making the existing ones work hard.

    Job throughput does not give us any measure to tape drive perf because multiple jobs may write to one drive at the same time, and one drive can write to multipe tapes at the same time.  Commmvault does not seem to have any ability to report on past drive throughput.

    For a disk library, we could get perf data (GB written, GB/hour...) at the OS level, but Windows OS does not see to have any performance counters for tape drives!  And, even if it did, we would have the issue of consolidating data from multiple media agents sharing the same drives.

    But in the Commvault GUI you can query the throughput of a drive for the past 1 hours, or x hours.   That data has to coming from somewhere.  And I think I've found where.  It's in a commserv database table called MMDriveHistory.  This table has two different types of drive history records:  type 1 are hourly, and type 2 seem to be event based.  Each record has a timestart column and a modified column.  For type 1, the timestart column almost always aligns on an hour, and the modified column may many hours later than the timestart.  For type 2, modified is aways the same as timestart.

    This table seemed to be the answer to my need.  But it only retains data for the past week.  Now I working on SQL code to accumulate the history in another database.  The tricky bit is that records get updates up to 3 days after they are first created.  Yes, we occasionally have tape jobs that run 3 days. 

    See attached sample SQL code for queries on the mmdrivehistory table.

    My Questions:

    1. Anybody got a better idea on how to get measurements of tape drive throughput?
    2. Anybody know how to change the length of time MMDriveHistory retains data?
    3. Anybody else using this table?  Can you tell us more about the historytypes
    Attachment: commvault posting.sql
  • Re: Tape drive performance data - from commserv database table mmdrivehistory ?
    Posted: 07-16-2010, 11:03 AM

    Hello Carlo,  Thanks for the post. Much of what you are looking or is provided as part of our Simpana Monitor product.  There are Media Management Performance Reports that pull from these tables in the CommCell(s) and retain more of the history.  So I would have to say that would be the better way...  :-)


    Although at your own risk you can change this time period as we don't encourage customer's making direct changes to the CS database.  I know you are probably an experienced DBA but I must put disclaimer to ensure you perform a DB Backup of your CommServe database before making any changes.

    dbo.GXGlobalParam is the table and DailyHistoryForQNetRetentionPeriod controls in days how long to keep this data, default is 7 days.  This is not tweakable from the GUI.  You should be extremely careful as if this will increase the size of your database as some of these tables can get very large if not pruned by our data aging process on a regular basis.   Caution: If increased to high could cause a domino effect and could making data aging take longer, database queries take longer, increase locks.  Which could lead to other issues.  For our customers that use the Simpana Monitor product, Simpana Monitor gathers this information over time in its own SQL Database.

    Mark Spencer
    CommVault, Business Critical Support
  • Re: Tape drive performance data - from commserv database table mmdrivehistory ?
    Posted: 07-16-2010, 11:23 AM

    Thanks very much for that nugget.  

    I do generally avoid making any kind of direct update/change to databases of proprietary software.  It's generally not a good idea for all the reasons you listed and more. 

    I was working on a process to accumulate a copy of this data in another database, but I should defintely look into the Simpana Monitor product. 



  • Re: Tape drive performance data - from commserv database table mmdrivehistory ?
    Posted: 07-16-2010, 12:17 PM

    Thanks Carlo,   If you find any answer that answers you question if you could mark solved.   On a separate not here is also good rule of thumb when it comes to multiplexing to your LTO4 drives (see below Multiplexing Performance Optimizations Options).  These are really fast drives so it may you could be either over plex'd or not enough causing a shoe shine effect when the buffer of the drive empties and fills.  If many of these clients are LAN based and are not MediaAgents (LanFree) then it could be they cannot feed the hungry tape drives fast enough.  This is something you will have to play with in your environment.  There are things that can be done at the client level that can improve overall throughput of the backups.  For example a badly fragmented drive on a client can cause really slow read speeds on the client.  You have the ability to perform multiple reads from a client's disk(s), keep in mind this will create an additonal backup streams and may be dependant on how many spindles each drive may have.  I have seen some clients with extremely i/o capability pull several streams at once.  This could be useful for those clients which are capable of very high i/o on the disk subsystem.  You can reference the following link, this is called multi streaming.  Multi streaming can also be done in conjuction with multiplexing on the drives, the link goes over that as well.  http://documentation.commvault.com/commvault/release_8_0_0/books_online_1/english_us/features/adv_backup_options/auto_fs_multi_streaming.htm



    The time required to complete data movement operations to tape may be reduced through the use of multiplexing to stream data from multiple systems simultaneously to one tape drive, reducing the aggregate amount of time required to complete these operations.  Whereas multiplexing does nothing to improve individual job performance, the coordination of multiple jobs to a single target does increase data movement efficiency.  Through the improved utilization of the tape drive(s) within a library backup windows may be reduced given the optimization of the total number of write operations completed via a reduction in drive eject operations, drive ‘shoe-shining’, and other mechanical conditions. This condition is most noticeable when slower client server backups are joined in a multi-plexed configuration to a tape drive or drives.


    It is NOT recommended to over ‘Plex client server writes to a single tape device as this will reduce both backup and restore performance for those jobs. The multiplexing factor for a given set of jobs should be set equal to the ratio of tape drive throughput and client source speed.  Example:  Assuming a rate throughput for a tape drive at  40 MB per second and a client throughput on network and with compression of 12 MB per second, a multiplexing factor of 3 is recommended. 

    NOTE:  Ensure that the TCP/OIP network between the client server systems and Media Agent(s) that move the data to tape is capable of supporting multiple simultaneous backups.

     NOTE:  CommVault restores do NOT suffer a “Plex penalty” based on restores of multiplexed data.

     Configuration of this Option for Data Movement Optimization:

     Typical multiplexing factors are set between 2 and 5 on 100BaseT networks.

    Typical multiplexing factors are set between 5 and 8 on 1000BaseT networks.  

    Mark Spencer
    CommVault, Business Critical Support
  • Re: Tape drive performance data - from commserv database table mmdrivehistory ?
    Posted: 07-21-2010, 5:52 PM

    Ah....I had not noticed the button to mark the thread resolved.  And then I clicked on the wrong post.  The realy answer to my questions is in Mark's first response, not the second.

    Thanks, Mark!

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.
Copyright © 2019 Commvault | All Rights Reserved. | Legal | Privacy Policy