cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
628
Views
10
Helpful
10
Replies
Highlighted
Beginner

RoggerA SQL Drive Low on Space

In our PCCE 11.6 environment RoggerA is throwing alerts for low disc space for D Drive, which contains the SQL database. RoggerB is fine so far. Yesterday it was at 7.2 GB available and is at 6.6 GB today. RoggerB is at 20 GB and holding. We are experiencing high call volume, but wondering if this is something to be concerned about and how to deal with it if so. Should it be purging old data at a faster rate than this? Is there somewhere I can verify that, or can I free up space somehow? 

 

Also can this drive be extended without PCCE getting angry at being outside normal parameters?

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Beginner

Thank you everyone for the assistance and suggestions. It turned out to be Shadow Copy which was enabled only on RoggerA and was occupying 15GB of space. After reducing it and limiting to the bare minimum the drive was back to normal. Not sure what turned it on or gave it such a high limit, but something to watch out for if you experience this as well.

View solution in original post

10 REPLIES 10
Highlighted
Rising star

Check the SQL jobs to see if the purge jobs are failing

Highlighted

I'm not very familiar with SQL, but this looks good to me...

 

SQL.jpg

Highlighted

Okay so that looks good... could you do one more thing? Can you expand the Last Run column and see what time those purge jobs run? Did they run at 12:30AM?

A few things...

Are you running an Outbound Dialer?

Is Rogger A and Rogger B in sync? You can check the max recovery keys in the TCD table to verify

Are the databases staged differently? What I mean by that is... are the databases autogrowth set differently? I think the typical autogrowth/maxsize for the database (not logs) is enable file growth to 100MB and max file size can be unlimited

Do you literally only have the data (MDF) and log SQL (LDF) on that D drive?

 

Highlighted

Are you running an Outbound Dialer?

No, we are strictly inbound through the Contact Center.

 

Is Rogger A and Rogger B in sync? You can check the max recovery keys in the TCD table to verify

They do match when I run Select Max(RecoveryKey) from Termination_Call_Detail on both quickly enough

 

Are the databases staged differently? What I mean by that is... are the databases autogrowth set differently? 

They should be, but I cannot say for sure. They were configured originally by our vendor and I'm not sure how to check this.

 

Do you literally only have the data (MDF) and log SQL (LDF) on that D drive?

Yes, the D drive is just SQL stuff, nothing else. There's just two files on there total.

 

I do have downtime over the weekend, so I am thinking of restarting them to see how that helps. 

Highlighted

Can you double check to see what time those purge jobs ran?

Highlighted

Look to see how old the oldest entry for some of the larger tables are. It could be that for some reason one/some of your tables are not being purged, which is impacting the size.

 

So like if you look at the minimum date for say Call Type Interval, Route Call Detail, Termination Call Detail, etc., what date shows? I believe typically it is 14 days for Rogger and 1065 for HDS.

Highlighted

Dear @bill.king1 

 

Also i experienced same with international customer with Rogger 11.6, the windows paging size increased as calculated by Windows Server Team. Restarting Windows server will release page size.

 

regards,

Ritesh Desai.

*** Please rate helpful post. Please mark as answer if it solves your problem/query.
regards, Ritesh Desai
Highlighted

Can you check these two items and find out which table isn't purging.

1. Open ICMDBA and check Space used summary of Logger Database. 

2. Check the Logger_Admin table to find the purge history.

 

- Ram

Highlighted
Beginner

Thank you everyone for the assistance and suggestions. It turned out to be Shadow Copy which was enabled only on RoggerA and was occupying 15GB of space. After reducing it and limiting to the bare minimum the drive was back to normal. Not sure what turned it on or gave it such a high limit, but something to watch out for if you experience this as well.

View solution in original post

Highlighted

Thanks for updating us