Database keeps failing - please help!

[mhudson]

I am running Notes/Domino 5.0 on my server. Last week a frequently-used database failed for some unknown reason. When I checked the file size, it was 786k, instead of the normal 21+MB. I restored the database file from a backup tape made a day earlier, and it worked again - for about a day.
It has since failed again with the 786k file size. No other databases are showing any problems. Any ideas as to what could be going on here? Please make any tips as detailed as possible, as I am far from a Notes expert. Thanks.

 

[pmonett]

When you say the database "failed" : what did it fail to do ? Did you get an error message when opening it, or did you just find less documents than usual ?

 

[mhudson]

Sorry for the sparse information. When the database is accessed, it says "Unable to initialize - there are no views selected", then goes on about replicating the database. Hope this helps. By the way, I restored it again yesterday from the last good backup of it on tape from the week before, and it worked all day. Did absolutely nothing differently. I won't be back to work until Monday, so I'll find out then how long it lasts.
Thanks!

 

[Packet7]

I would check your Notes.ini on your server to see if "Design" is scheduled to run on a nightly schedule.

ServerTasksAt1=Catalog,Design <---HERE
ServerTasksAt2=UpdAll,Object Collect mailobj.nsf
ServerTasksAt3=Object Info -Full
ServerTasksAt5=Statlog

If this is the case, I would try the following:

Remove &quot;Design&quot; from ServerTasksAt1= line and bounce (reboot) your server. The following day, monitor the status of the DB. If this corrects the problem, check to see what template the DB inherits it's design from (DB Properties, Deisgn tab - protractor icon). You could have a problem with your template file, causing the DB to lose it's views.

If this is the case, you can remove the inheritance, so the DB doesn't utilize the Designer or repair the template.

Hope this helps.

John Judge
MCSE, MCSA, MCP, CCNA, CNA, Network +, A+

 

[pmonett]

I agree with Packet7, save that I would first remove the design inheritance instead of modifying the server schedule and cancelling design on all databases.

Indeed, if something is removing all views, it stands to reason that the db size would decrease dramatically.

Also, check in the design that individual design notes do not inherit by themselves. That can happen when the designer copies design elements from other databases and keeps the design inheritance that goes with it.
That way, you can end up with a db that does not inherit design on the db level, but some elements inside still do.
It is a great feature when you do it on purpose, but it can also wreak havoc if you are not informed.

 

[mhudson]

Thanks, guys, I'll check on these itmes when I go back in Mon. morning.

 

[mhudson]

Hey Packet7,
I checked the Notes.ini file and these entries were found:
ServerTasks=Replica,Router,Update,Stats,AMgr,Adminp,Sched,CalConn
ServerTasksAt1=Catalog, Design
ServerTasksAt2=UpdAll,Object Collect mailobj.nsf
ServerTasksAt5=Statlog

I have removed the reference to Design and saved the file out. Strangely enough, I found two different copies of Notes on the server - one copy in the root and one in sysvol. The Notes.ini file in the Notes folder in the root did not have any of these entries, and this is the copy of Notes from which we operate daily. Since all this was set up before my arrival here, this is kinda confusing. The databases in sysvol all had file dates of 2+ years old. What do you make of this?

 

[Packet7]

Sounds like you had an older (R4.x) version of Notes installed. By default, R5 stores it's notes.ini within the Notes Program directory.

Did you get the chance to check the design inheritance yet, like pmonnet recommended?

Let me know.




John Judge
MCSE, MCSA, MCP, CCNA, CNA, Network +, A+

 

[mhudson]

Yes, there is an older version on the system , but it is just kinda &quot;there&quot; and not in the way, being in the Sysvol share. The Notes.Ini file was in the C:\Notes folder and that is the one where I removed the Design from the ServerTasksAt1=Catalog, Design
entry. I rebooted the server and restarted Domino server, and still get the same results. This morning the database had again shrunk from 21+MB to 768kb overnight. I have again restored it from an earlier backup and checked all the properties, which match those of all the other databases that give me no problems.
When the database is accessed, it gives the following message &quot;Database is not fully initialized yet. (It does not contain any views). You will have to use 'Replicate...' on the File, Replication ' menu to intialize it.&quot; Doing so does nothing to change it, as it says it was replicated but not initialized.
Any ideas, guys, before it get the hammer?

 

[Packet7]

Right-click the DB icon on your workspace, click properties, click the Design Tab (protractor and ruler icon). Is this DB inheriting it's design from a template? If so, which one?

Also, when you mention your &quot;restore from an earlier backup&quot;, what tape are you using? The night before, last full?

I would pull a replica down at night before you leave (right click, replication, new replica, point locally), so that you can restore it quicker until it's resolved.

Once you have a local replica, try and compact the DB locally. You compactor task on your server could be causing the issue.

What type of Virus Scan are you using on your Domino server? If your using Scan Mail for Notes, try running a manual scan of the DB.

Hope this helps. Keep me posted.

John Judge
MCSE, MCSA, MCP, CCNA, CNA, Network +, A+

 

[ohinz]

Hi

You have found the exact point of trouble..
You have trouble with replication.

Replication can destroy the views. Replication can delete documents. The designer task can only delete views. That cannot be the cause of the new size.

There is a server or user who try to put a replica on the server.
That has nothing to do with the designer task or something like that.

This trouble can have more than one cause.
One cause: Someone make a copy instead of a replica.*
Another one: Someone use &quot;create replica&quot; on another server or client with the target of your server.

This are the most &quot;popular&quot; reasons.

The way of solution: Find the computer that tries to replicate the database.

* Notes identifies replica with the replication ID. Every database and every replica has it's own ID.
One possiblebility: Another server uses a backup of a notes database...

Ole

 

[mhudson]

I checked all the properties of the offending database, and it is not inheriting anything. The backup I was restoring from was from Wednesday 2 weeks ago, which worked briefly last week before failing. After restoring that same file and getting repeated failures, I restored the file from Tuesday of 2 weeks ago. I checked all it's properties, and all is in order and it works for now. I created a local replica on the server just in case, and it works also.

Alas, we are not running any antivirus on the server itself, just on all the workstations, which I know is probably foolish and I hope to remedy soon.

I'll keep my fingers crossed it doesn't go tits-up by tomorrow!

Thanks.

 

[Packet7]

I think Ole made a good point. Try and disable replication in the DB, since it doesn't appear to me that you need it replicating anyway. I think we are starting to rule out all possibilities here...

Good luck.

John Judge
MCSE, MCSA, MCP, CCNA, CNA, Network +, A+

 

[mhudson]

Hey guys, after restoring the database from the Tuesday backup, it is still running without problems. Why the Wednesday backup would work and then fail later is still a mystery to me. Hopefully we have brought an end to this saga. I have learned a few things I didn't know before, and I want to wholeheartedly thank each of you for you input and help on this. You guys are great, and this is why I come here when in need.

 

[mhudson]

This an update to the failing database situation which I had erroneously thought had been fixed. After having tried all the excellent suggestions you guys generously provided to correct the problem, I thought I had that dog whipped, only to see it fail again. What I finally wound up doing was to create a local copy of the database, and then copy it back to the server. When I checked it, it still worked fine. Upon checking the properties, I discovered it was now half the size of the original file, but with the same number of documents. Same for the local copy.
Apparently, &quot;something&quot; caused the file to become hideously bloated, and creating the local copy somehow corrected this (compaction, maybe?). The database has now run fine for the past couple of days, and the file size is behaving as would be expected.
Any theories on this? Again, I want to thank all you guys for your generous help.

 

[ohinz]

Do you make a local copy (using notes) or do you replicate it?
If you make a copy of the database with File -> Database -> New Copy..., Notes creates a new database ID and new UID for all documents.
(For the server, it is a new database because of the DB ID...)

If you make a copy like described, the other Client/Server cannot replicate and destroy the new database. (Replication is controlled by the replication IDs, and a copy has a new one)

Ole