Forum Discussion

Mike_Reed's avatar
Mike_Reed
Level 4
9 years ago

10.0.4 JournalStub Table 1.3TB in Size Ouch and Growing

Can anyone tell me why in EV 10.0.4 on one and one only the Databse Size has a JournalStub Database Table that is 1.3TB in size and gowing. I checked the other JournalStub DB Tables on the onter EV Databases and they are in the meg range. Were ruunning out of space on that Windows 2008 R2 64 Partition due to this table being that size.

The Database is a Vault Store for Exchange. We have 2 Vault Stores for our 4 Exchange Servers and I checked the other Database and its JournalStub Database Table is 0.00MB.

Very Strange..............

 

 

Any thoughts would greatly be appreciated.

  • There was a defect in some of the 10.0.3/10.0.4 builds where the transaction history wasn't getting purged properly, so records would stack up in JournalArchive/JournalDelete/JournalUpdate and JournalStub. Of these, JournalStub will have the biggest size even if it doesn't have the highest row count, due to the Payload column which is used to build Vault Cache.  If you are running one of the versions in this article, then that is probably what is bloating your Database.  https://www.veritas.com/support/en_US/article.000022110

    You should confirm that it's not whitespace and, if not, then engage Support to confirm that this is the problem. If so, you'll need to upgrade, which may need to wait till after you tackle some of this backlog (assuming that is where the problem lies). Support can probably give some recommendations on how to clean out a backlog in these tables. It's unfortunately not as simple as just truncating out the table, and with 1TB+ in size, I would be real reluctant to let the upgraded SQL routines take care of that on their own.

  • Vault Cache will use that table. Are you doing any large imports that would add to the table?

  • DcVast, none that I'm aware of. We noticed that the space was incresing and notified our SQL DBA and he had stated it was this table that was growing. How do we flush it if its possible.

     

    Thank you........

  • In SQL Management Studio, if you get Properties on the database, what does it show for size and space available? No PST migrations? What is your archiving schedule and how much are you archiving?

  • i've never seen anything like this with such a massive table over a TB in size. have your DBA make sure it's not all just whitespace. and if it is, look into your SQL maintenance plans to make sure they're occuring according to best practices.

  • There was a defect in some of the 10.0.3/10.0.4 builds where the transaction history wasn't getting purged properly, so records would stack up in JournalArchive/JournalDelete/JournalUpdate and JournalStub. Of these, JournalStub will have the biggest size even if it doesn't have the highest row count, due to the Payload column which is used to build Vault Cache.  If you are running one of the versions in this article, then that is probably what is bloating your Database.  https://www.veritas.com/support/en_US/article.000022110

    You should confirm that it's not whitespace and, if not, then engage Support to confirm that this is the problem. If so, you'll need to upgrade, which may need to wait till after you tackle some of this backlog (assuming that is where the problem lies). Support can probably give some recommendations on how to clean out a backlog in these tables. It's unfortunately not as simple as just truncating out the table, and with 1TB+ in size, I would be real reluctant to let the upgraded SQL routines take care of that on their own.

  • Patti hit it right on the head. It is a issue with EV10.0.4 and the fix is moving to EV11, go figure, thanks to all for the feedback. This site rocks. ;)