It would be helpful to know which tables are the biggies... if you counted the rows and size of the different tables. There has to be something abnormal going on for the database to get to that size... even customers running for years with large networks do not get to that size.
You also need to tell us the TMS version as it's relevant to some of the db upkeep.
The db maintenance is done by stored procedures which you can see by browsing the database itself... but I'm hesitant to give directions on this topic just out on the web because it can be very much a 'try, adapt, try again' type of situation given the table sizes and specifics in play here. Usually I do this live by analyzing what is in play. There have been some defects that can lead to explosive growth in the ticket table for instance.
Are you versed at all with SQL and running stored procedures?
Attached is a script you can run in the database and it will report on the size and # of rows in each of the tables
Thinking more... this is a 'safe' way to let the tools do the job themselves
You can try enabling all the database maint procedures by toggling them on in the database. This has the same effect as enabling them in the GUI... but it will not initiate the jobs, just tell them to be enabled, so they will start to run during the nightly job
Run this sql script against your database to enable all the db jobs at their existing duration
update tmsng.dbo.DatabaseAndLogsMaintenance set Enable = 1 where Description like 'Table_%'
But note the jobs do not attempt to purge all possible data in one pass due to transaction sizes, timeouts, etc. So if left to its own, it would decline over time.
Some questions to answer to check for easy outs....
What is 93gigs? Their data file (the .mdf) or their log file (the .ldf)? Is sql reporting that much space in USE or just the file sizes?
Are they running simple or full recovery on the database?
I apologize for a late reply - but hopefully by now you have some progress
looking at the code, it should delete 10k rows at a time, and keep looping through until there are no more to delete.
Then you'll need to shrink your database files to get the file size back down and reclaim the disk space
I couldn't tell from your snapshots if the database was in simple or full recovery mode. If in full recovery, your log file is going to balloon with all these deletes. you should consider switching to simple recovery mode at least temporarily until the database is back to normal size. Then you don't have to worry about the log file getting out of control mid-process
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: firstname.lastname@example.org Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...