The dbbackups do complete without error. I do notice that there has
been an error in the log each of the last several nights 30905 ..
"The nightly maintenance stored procedure failed. It will be retried
in roughly 24 hours. If this error continues to occur, the Live
Communications Server service will need to be restarted.
Hresult: 0
Sql native error: 22D8
Cause: Possible issues with backend database.
Resolution:
Ensure the backend is functioning correctly."
This morning, I did restart LCS without incident. It appears to be
working fine for the 1000 users. A change in my contacts list survives
signout/signin, so the database is working, right? The only other
indication of problem is that one of many users I added yesterday say
"User is not provisioned in the database", even though he appears to
be in Active Directory. I removed and readded him without success.
Other than the event mentioned above, there are no other interesting
events.
I just downloaded the SP1 version of the Resource Kit and ran
dbanalyze. It sat for several minutes, then said
"Timeout expired. The timeout period elapsed prior to completion of
the operation or the server is not responding."
I do not know what process is suppose to trim this log file back. My
SQL guy says that the log has to be backed up separately to get it to
flush, but he was not familiar with dbbackup (which obviously backs
them up), and I also believe that the event that has been occurring
every night for a week saying that "Nightly maintenance" could not run
may also be responsible. I'm hoping (without much confidence) that
this morning's restart will allow the Nightly Maintenance to run.
The reason I ask is that I have seen a lot of similar items when a
file-level AV scans the Exchange databases.
--
Bob Christian II
http://blogspot.bobchristian.com - Blog
"Kevin" <anon...@post.ing> wrote in message
news:cumtc1l7mkbj67bhp...@4ax.com...
Nonetheless, I have disabled file-level AV to see if that helps.
The rtc.ldf file continues to grow by 2 gig a day, and the nightly
maintenance fails, even though I restarted LC Friday morning.
You have already downloaded the LCS 2005 Resource kit for SP1 nd ran
dbanalyze /report:diag That is probably the main suggestion which I would
make. ...and it's upsetting that it did not complete.
DBbackup is the command. If you installed LCS in the default directories
then all you should need is dbbackup /backupfile:filenamehere in order to
backup the SQL server or MSDE. This is stored in the LCS \Server\Support
directory, so you may have to call it through the path c:\Program
Files\Microsoft LC 2005\Server\Support\dbbackup.exe
I don't know enough about SQL to suggest running a shrinkfile operation.
That, however, may be an option if you talk to PSS, but I would not
recommend it.
Though this is not what you want to hear, it may be worth talking to PSS
about this problem.
--
Bob Christian II
http://blogspot.bobchristian.com - Blog
"Kevin" <anon...@post.ing> wrote in message
news:4bo4d1tf5i5ul3h12...@4ax.com...
I'm familiar with dbbackup, although it isn't clear that dbbackup is
responsible for flushing the log file. It appears to me that LCS
"Nightly Maintenance" is. The log growth and the nightly failure of
"Nightly Maintenance" started at the same time. We are still doing
dbbackups daily .. it's just that it now backs up 20-30 gig (still
growing 2-3 gig a day) because it includes the log file. Actually,
that's how I was alerted to this last week - the 70 gig disk I write
the backup to, normally keeping 7 copies of 250 meg, filled up.
I'm not at all SQL literate, but is it possible that transactions pend
in the log file until they are committed to the database? And the
problem here could be that it can't commit anything to the database?
That's my theory and I'm sticking to it.
Bob
--
Bob Christian II
http://blogspot.bobchristian.com - Blog
"Kevin" <anon...@post.ing> wrote in message
news:iua8d1hcoob9ak17f...@4ax.com...
Apparently, there was a transaction on June 28 that never got
committed and it was blocking all subsequent transactions - they just
built in the log file. I had to end the rtcsrv process and then stop
MSSQL$RTC .. then reboot, and allow SQL to roll in the pending
transaction.
I then separately had to truncate the log file. (PSS was very helpful
with this).
I think it is mostly resolved but we are still getting the occassional
30903 event indicating that the "The Endpoint expiration stored
procedure failed. " which concerns me because these events also came
just before the June 28 transaction. PSS is looking at a SQL trace
showing "deadlocks" which I assume isn't good.