Windows Server

Einari · Guest

No matter what I do I still get these errors:
Could not allocate space for object '(SYSTEM table id: -352638842)' in
database 'SystemCenterReporting' because the 'PRIMARY' filegroup is full.

Have done the following;
minimized databes groom times
deleted rules
have made maintenance plans (backups)
increased database sizes (OnePoint and SystemCenterReporting)

Any suggestions greatly appreciated.

Einari · Guest

Did you men MOMX Partitioning and Grooming ?
This has been a succesful job all the time (and was now too).
(Also the SCDWGroomJob has been succesful).

Einari

"Daniel Lai [MVP-Management Infrastructur" wrote:

Daniel Lai [MVP-Managemen · Guest

Hello,

Thank you for your posting!

Please try to Start the Groom job in SQL Enterprise Manager, Managemernt,
SQL Server Agent, Jobs.

If you have any questions, please feel to let me know. I am glad to be of
assistance.

--
Daniel Lai
Microsoft MVP Program Top Contributor
Windows Server-Management Infrastructure
Microsoft Management Solution Consultant
http://msmvps.com/daniel

"Einari" <Einari@discussions.microsoft.com> wrote in message
news:6DD786F7-04D2-46E9-A669-00A08FE8447E@microsoft.com...

davidtyra@hotmail.com · Guest

Einari,

Is your SystemCenterReporting database actually full or is there space
available? You might also check to make sure that the log files are not
full and that Tempdb is not filling up. Is the DTS job to transfer data
from the Onepoint database failing?

Regards,

David Tyra

Einari · Guest

All database files (and logs) seems now have a least 10% free space.
Could you tell me how to check if DTS job is working properly ?

Einari

"davidtyra@hotmail.com" wrote:

davidtyra@hotmail.com · Guest

Einari,

Look in Control Panel on the MOM database server and right-click
Scheduled Tasks and choose Open. You should see the DTS task listed
there. It will have a Last Result column where you should see a 0x0
(which equals successful result). Last run time should equal 1:00 AM of
today (unless you have changed the schedule).

Regards,

David Tyra

Einari · Guest

David,

Found it. It says 0xffffffff.
It was scheduled at 5.30 AM. I don't remember changing this value here (I
have done Database Maintenance Plans - would these affect this scheduling ?).

Einari

"davidtyra@hotmail.com" wrote:

davidtyra@hotmail.com · Guest

Einari,

OK, that is a failure. You might search on that but I have seen that
0xffffffff error when the MOM operational database is too large. How
large is your Tempdb database and is it full? If it fills up during the
DTS transfer, the transfer will fail and you will see the primary
filegroup errors that you mentioned earlier. Make sure that your
transaction log files are not full either.

Regards,

David Tyra

Einari · Guest

David,

Tempdb is now only 1,62MB and I have now resized so it now has almost 8000MB
free. Transcation log is 400MB and same applies here (ie 5500MB free).
SCR 1300MB, 430 free (transaction log 7MB, 490MB free)
OnePoint 1290MB, 375 free (transaction log 24MB, 176MB free)

Tapio

"davidtyra@hotmail.com" wrote:

davidtyra@hotmail.com · Guest

Einari,

I am not quite sure I follow your numbers but it appears that you have
only 430 MB free space in the Reporting database and 375 MB free in the
operational database. These are both very small amounts and your
primary filegroup is full error could be caused by either one of these.
You need to grow both of these databases. In particular, the
operational database should always have about 40% free space to use for
re-indexing and other database operations. The maximum size for the
database is 30 GB so you should have plenty of room to grow. The
maximum size for the reporting database is 1 TB so you really have room
to grow there. I would suggest growing your databases (do not set them
to auto-grow) so that the databases have room to expand. Your Tempdb
looks like it will be big enough - it should be large enough to hold
all of the data being passed from the operational database to the
reporting database each day. The transaction logs should be sized to
20% of their associated database. I believe this should take care of
your problem. Hopefully, someone can chime in if I have gotten any of
the sizes wrong.

Regards,

David Tyra

Einari · Guest

David,

Today I have tried to do Maintenance plan for backing of OnePoint and SCR
transaction logs. It doesn't work.
I just get these errors:

Backup can not be performed on database 'SystemCenterReporting'. This sub
task is ignored.

And SQL Server Logs says like this:
The log file for database 'SystemCenterReporting' is full. Back up the
transaction log for the database to free up some log space..

I have tried to make both databases larger (and transaction logs too).
But really soon I end up in a situation where both OnePoint and SCR have
only few 100MB free.

David Tyra · Guest

It sounds like the transaction log and perhaps the database need to be a lot
bigger. One thing you could try temporarily is to set the database and log
to auto-grow. This is not normally recommended for MOM databases but the
Reporting database isable to handle it better than the operational database.
Set file size to be unlimited and growth to be something like 100 MB. Let
that run and see if the database operations start succeeding. Once
everything is working, you can turn off autogrow and go back to a statically
sized database and log file. Hopefully, that will help.

Regards,

David Tyra

"Einari" <Einari@discussions.microsoft.com> wrote in message
news:26783C49-8FDC-4DD3-AB95-846C36AF0134@microsoft.com...

Thomas Olsen · Guest

Also take a look at this one to decrease that amount of days for data to
reside in the SCR db before it is deleted:
http://support.microsoft.com/default.aspx?scid=kb;en-us;887016

/Thomas

"David Tyra" <davidtyra@hotmail.com> wrote in message
news:f-GdnQ8-qpreMu3eRVn-uQ@giganews.com...

	Windows Server Forum Index -> MOM	All times are GMT
Page 1 of 1