Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

SMP 7.1 SP2 MP1 - Item table growing large

Created: 19 Mar 2013 • Updated: 23 Jul 2013 | 9 comments
This issue has been solved. See solution.

Hi,

Has anyone expirienced that the Item table has grown large after applying Rollup v2 / v3? Unfortunately I cannot 100% recall when i started but my DBA said that the database on the parent NS has grown 60 GB in about one week because he was asking me how much additional disk space he should prepare after he already added additional space.

The Item table on the child servers have aslo grown quite a bit but not as much as the one on the parent.

Any suggestion to "shrink" it back to normal size would be very much appreciated. I would think around 1,5 GB should be normal because that's what it was about 2 months ago....

Thanks

Stefan

Operating Systems:

Comments 9 CommentsJump to latest comment

andykn101's picture

Is it something to do with this:

"Notification Server database on a Child NS is growing very large"

http://www.symantec.com/docs/TECH142944

"Cause

There was a lot of residual entries from completed, stalled and or failed replication jobs that needed to be cleaned up."

Authorised Symantec Consultant (ASC) with Endpoint Management Limited, an Authorised Symantec Delivery Provider based in the UK.

Connect Etiquette: Please "Mark as Solution" posts that fix your problem.

Stefan S.'s picture

I have not seen TECH142944 but I have seen the article linked to that. I have imported the clean-up task and it has been running for a while. However it seems like on the Child NS there is never something to be cleaned as it always comes back with 0 rows affected if running directly in the SQL Management Studio. On the parent though it seems to clean-out a lot but no change in the size of the database / item table.

But maybe the database is now to large that the cleanup fails...

Stefan S.'s picture

We managed to get control back by installing service pack 2 on the SQL. There must have been some kind of bug in SQL....

SOLUTION
Zebbelin's picture

What version of SQL are you using?

Did you just install SP2 and everything was OK, or did you do anything else?

 

Have the same kind of Problem here (SQL 2008R2 SP1)...

Thanks a lot!!!

Stefan S.'s picture

SQL 2008 R2 SP2 (10.50.4000.0).

Are you having a hierarchy? If you do have you might have to check the following article http://www.symantec.com/docs/TECH141847  . This article includes a clean-up task which seems to be necesseray to run on a regular basis if you have hierarchy. It cleans out faile replication jobs.

Zebbelin's picture

Yes we have a hierarchy setup and both DBs are over 80GBs now (20 to 25GB was normal in the past).

So you are saying that you just updated SQL to SP2 and everything was OK?

Will also look in the the known issue.

Thanks for the fast reply :)

Stefan S.'s picture

The problem I had was that the Item table was growing every night (during differential replication) with obout 8 GB. And this stopped after upgrading to SP2. The normal size of the my item table is between 1,2 and 1,4 GB.

It can happen still though that from time to table grows over that size and in that case i need to run the replication clean-up. You need to run the NS.Daily task after that also...

Zebbelin's picture

Ok I imported the task on both servers, but it completes in some seconds.

Size of the table does not change and even after running NS.Daily the size is still the same.

I opend up a case at tech support. Will see what they say.

Your solution sounds promissing, but will take some days for me before I can update the SQL ;-)

Thanks so far. Will post my solution here

Zebbelin's picture

After dealing over 3 Weeks with the Symantec support, they confirmed my initial question about SQL 2008R2 SP1/2.

So, after we updated our SQL 2008R2 to SP2, the item table went to a normal level. It can be monitored on the SQL with:

Use Symantec_CMDB

Go

sp_spaceused item

go

After 3 to 4 hours the item table was on a normal level. After the DB-Shrink the Databases have a normal size now.

Thanks a lot for you hint with SP2! Very useful

SOLUTION