Database error 0xfffffd9a - AGAIN

[AdminStooge]

This is the second time we have had this issue. The first time it took a fail-over in our exchange cluster to resolve this issue. This time it took our First Storage Group offline. This Storage Group hosts Fax Folders, 3 Mailbox Stores and the Public Folder Store.
I mounted the stores again so the user community only experienced a brief outage but I would really like to eliminate this from happening again.
I ran the EPBA Tool and have provided you with the htm file to you to view. Please feel free to contact me with suggestions on how to resolve this issue.

Here is the errors I receive within the Application Log:
Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "First Storage Group\Maibox Store 2 (exchange environment)".

Database error 0xfffffd9a occurred in function JTAB_BASE::EcDelete while accessing the database "First Storage Group\Mailbox Store 3 (exchange environment)".

Database error 0xfffffd9a occurred in function JTAB_BASE::EcSetColumn while accessing the database "First Storage Group\Mailbox Store (exchange environment)".

I ran EBPA Tool and got the following for my exchange environment:
Server Clustered Environment

Database backup critical Server: Clustered Environment
Database 'Fax Folders' on server Clustered Environment has not had a full online backup for 123 days. Database backup stamp: 04/21/2005 09:01:54.

Server Both Nodes

HeapDeCommitFreeBlockThreshold not set Server: Both Nodes
Server Active Node has 1 GB or more of memory, accommodates 1073 mailboxes, and the HeapDeCommitFreeBlockThreshold parameter has not been set to 262144. Virtual memory may become quickly fragmented and system instability may occur.

Thank you for your help into this matter.

 

[netometer]

Hi!
First, here is what I found for the error that you get (probably you’ve already read this):

http://support.microsoft.com/default.aspx?scid=kb;en-us;836611

I think that the message:
“Database 'Fax Folders' on server Clustered Environment has not had a full online backup for 123 days”
means that probably the log files for this database are not cleared and combined with the info from the KB836611 article :
“There are more then 1,008 log files between checkpoints to replay on the server.”

That’s all I could find till now. I’ll try to find more info on this because it really is a weird problem.

NetoMeter

http://www.netometer.net

 

[AdminStooge]

I found this on the net:

http://www.windowsitpro.com/Article/ArticleID/46650/46650.html

But I don't know how to check the checkpoint depth for my exchange cluster....

 

[netometer]

Here is an article about modifying the checkpoint depth for an Exchange 2000 cluster. I can not find a similar one for Exchange 2003 but at least it explains what is the idea behind it:

http://support.microsoft.com/default.aspx?scid=kb;en-us;886298

NetoMeter

http://www.netometer.net

 

[AdminStooge]

I checked with Premier Support and they don't believe changing the checkpoint depth with resolve the issue, they believe it could be caused by my backup being runned by Veritas.

 

[netometer]

What about
“Database 'Fax Folders' on server Clustered Environment has not had a full online backup for 123 days”

Can you try to back up this database or clear the log files for it?
If you are not going to back it ip on regular bases enable circular logging for it.

NetoMeter

http://www.netometer.net

 

[AdminStooge]

It's schedule to run on the daily basis between 2am - 6am
but the last full backup is marked - 4/21/2005 9:01 AM

Any thoughts?

 

[xmsre]

Well, that would be the problem. What backup product are you using? Does it log anything when a backup fails?

 

[AdminStooge]

This is what I'm seeing when I right click on the Fax Folders and go to Properties. I then go to the database tab and this is where I notice this information.

As far as I know, Veritas is the only tool backing up exchange.

 

[AdminStooge]

I'm currently backing up the following:

\\exchange cluster\Microsoft Information Store\First Storage Group
\\exchange cluster\Microsoft Exchange Public Folders

\\SMTP server\First Storage Group

And here are some of the errors that I have come across with this backup job which is scheduled to run nightly @7:59pm.
--------------------------------------------------------------------------------------------------------
Backup - exchange cluster Access is denied to Remote Agent. Check the login account for the specified device. [this error has just started to appear]

Unable to attach to \\exchange cluster\Microsoft Information Store\First Storage Group.

Unable to attach to \\exchange cluster\Microsoft Exchange Public Folders.
--------------------------------------------------------------------------------------------------------

The reason I asking about exchange and Veritas is that we have been experiencing some exchange issues and I'm sure some of you have seen me post about the following errors that I have found within the Application Log:
Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "First Storage Group\Mailbox Store 2 (exchange environment)".

Database error 0xfffffd9a occurred in function JTAB_BASE::EcDelete while accessing the database "First Storage Group\Mailbox Store 3 (exchange environment)".

Database error 0xfffffd9a occurred in function JTAB_BASE::EcSetColumn while accessing the database "First Storage Group\Mailbox Store (exchange environment)".

I talked to Premier Support about it and they suggested that it could lie with Veritas and the errors that Veritas is creating with not being able to complete a full backup. I'm in the process of removing the remote agent of the exchange cluster but to do this, it requires a reboot of the server. I will have to wait till next Friday evening for our next scheduled maintenance window.
I plan on reinstalling the remote agent, delete the current exchange backup job and recreating a new one. Hopefully this will allow us to get full backups of our exchange environment and resolve that database error 0xfffffd9a.

 

[xmsre]

If you have the space, try running a manual backup with ntbackup, and see if this truncates your logs and updates the last full backup date. It sounds like your backup have either not been firing, or have been failing. You should be able to look on the veritas media server and figure this out.