'PRIMARY' filegroup is full.

Question

Post reply

'PRIMARY' filegroup is full.

surma.sql

SSCommitted

Points: 1552
More actions
September 20, 2012 at 8:38 am

#267036

Could not allocate space for object 'dbo.cmsPropertyData'.'PK_cmsPropertyData' in database 'HPPortal' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
This is an error log
please help me how to resolve

Viewing 8 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic. Login to reply

Ant-Green SSC Guru Points: 113507 More actions · Answer 1

You will have to do 1 or more of the below

Drop objects

Delete data

Add more drive space

Enable AutoGrowth if disabled

Remove unnessesary files from the file system

surma.sql SSCommitted Points: 1552 More actions · Answer 2

anthony.green (9/20/2012)
You will have to do 1 or more of the below
Drop objects
Delete data
Add more drive space
Enable AutoGrowth if disabled
Remove unnessesary files from the file system

right now i am deleting rows from that table

should it work?

Ant-Green SSC Guru Points: 113507 More actions · Answer 3

yes it will work after the ghost cleanup task has gone in and removed the data but your only buying yourself some time, you will need to get more disk space otherwise you will hit this issue again or setup a archiving routine.

but have you checked that the data in the table is not needed before deleting it?

MysteryJimbo SSC-Insane Points: 24203 More actions · Answer 4

anthony.green (9/20/2012)
You will have to do 1 or more of the below
Drop objects
Delete data
Add more drive space
Enable AutoGrowth if disabled
Remove unnessesary files from the file system

Or add another file to the group on another volume and disable growth on the existing one.

surma.sql SSCommitted Points: 1552 More actions · Answer 5

anthony.green (9/20/2012)
yes it will work after the ghost cleanup task has gone in and removed the data but your only buying yourself some time, you will need to get more disk space otherwise you will hit this issue again or setup a archiving routine.
but have you checked that the data in the table is not needed before deleting it?

That table has all historic info.

that table contains all user archive log entries for application. and it will starts from last 2 years. I already put red flag on this issue to my manager 2 months back. but she did not take it on her mine. so today we delete some of historic data for quick fix.

Now , i think we need to think about better plan, something like need to keep only last 6 months data and we are fine.

Thanks for Your help.

tim_harkin SSCrazy Points: 2399 More actions · Answer 6

surma.sql (9/20/2012)
That table has all historic info.
that table contains all user archive log entries for application. and it will starts from last 2 years. I already put red flag on this issue to my manager 2 months back. but she did not take it on her mine. so today we delete some of historic data for quick fix.
Now , i think we need to think about better plan, something like need to keep only last 6 months data and we are fine.
Thanks for Your help.

Data retention has to be a business decision. Yes, include your manager, but state that "the current system can only hold X months of data, and if more is needed we must"... and lay out options - delete old data, get more storage, export older records and store them in another place, etc.

Do you have a recent backup in case someone suddenly needs these records?

surma.sql SSCommitted Points: 1552 More actions · Answer 7

tim_harkin (9/20/2012)
surma.sql (9/20/2012)
That table has all historic info.
that table contains all user archive log entries for application. and it will starts from last 2 years. I already put red flag on this issue to my manager 2 months back. but she did not take it on her mine. so today we delete some of historic data for quick fix.
Now , i think we need to think about better plan, something like need to keep only last 6 months data and we are fine.
Thanks for Your help.
Data retention has to be a business decision. Yes, include your manager, but state that "the current system can only hold X months of data, and if more is needed we must"... and lay out options - delete old data, get more storage, export older records and store them in another place, etc.
Do you have a recent backup in case someone suddenly needs these records?

Yes, I schedule backup 3 AM in morning and database down early in the morning somewhat around 9AM. so i did manually backup and then remove rows from that table.

Right now Production Server is back with this quick fix. but still need to make some plan for future.

Thanks for reply.