Previous Page TOC Next Page



— 17 —

Administering Notes Databases

Each database should have a database manager assigned to it. The database manager is responsible for the maintenance of the database. The database manager is responsible for these tasks:

Chapter 8, "Preparing Your Organization," discusses the role of database manager in detail. This chapter shows you how to carry out database manager tasks. Security tasks such as changing the access control list are covered in Chapter 18, "Administering Notes Security."

Installing a New Database

You should have a well defined process for installing new databases on your production servers. This process should be written and available through a Notes database to your application designers, administrators, and users. Chapter 8, "Preparing Your Organization," covers in detail a recommended process for installing new databases. This chapter will simply summarize the steps that you should follow.

Installing a database on to your production servers involves all of the following tasks:

Keep in mind that the amount of testing that each application gets is dependent upon the importance of the application. If you work in a large organization, you may allow a large number of users and application designers to create their own databases. It is quite possible that not all groups will use the same process. However, your important databases and critical applications should go through a formal release process.

Purging Databases

Purging a database is the process of removing old documents. The Purge server task removes old documents and deletion stubs from the database. The purge interval controls both the number of times Purge is used on a database and the minimum age of documents that will be removed. Purge runs against a database every one-third of the purge interval and removes all documents and deletion stubs older than the purge interval. For example, if you set the purge interval at nine days, Purge is run against this database every three days, and any documents or deletion stubs older than nine days will be deleted each time Purge runs. Make sure that your purge interval is long enough to guarantee that deletion stubs have replicated to all other servers. You can set the purge interval independently for each database.

Keep in mind that Purge runs against all documents in a database. If you have a database that mixes highly dynamic data with reference information that doesn't change, Purge will delete your reference information, making the database less useful. As an administrator, you have the option of disabling Purge and/or running Purge only against deletion stubs. You cannot prevent specific documents from being purged. Because of this limitation, you should not mix static and dynamic information in a single database.

You set the purge interval for a database by using the Database Properties dialog box. The Database Properties dialog box is the central management point for a database while using the Notes client.

To set the purge interval for a database, follow these steps:

  1. Click the database icon on the workspace.
  2. Right-click the database icon to open the Database Properties dialog box.
  3. Click the Basics tab.
  4. Click the Replication Settings button.
    The Replications Settings dialog box appears, as shown in Figure 17.1.

    Figure 17.1.
    Use the Replication Settings dialog box to view or change replication settings.

  5. Select the Remove Documents Not Modified check box.
  6. Enter the purge interval that you want for this database in the Days entry field.
  7. Select the appropriate action that should be taken when a document is to be purged. If you don't want the purging process to delete documents, just remove deletion stubs, deselect the Remove Document Not Modified check box.
  8. Choose OK.

A purge interval of 90 days, the default setting, is adequate for most databases. Use a shorter interval if the database is growing and performance problems due to large indexes are causing complaints.

Compacting Databases

Over time, as you add or delete documents from a database, white space creeps into your database. This space causes the database to be larger than it otherwise needs to be. Compacting is the process of reclaiming the white space. For example, when a document is deleted it is replaced with a deletion stub. The space used by the original document is now wasted. It is unlikely that another document will be created that exactly fills the wasted space. Over time, small unused chunks of wasted space appear in a database. Compacting a database removes this wasted space. The most active databases are the ones that need the most compacting. The Notes log and Public Address Book are prime examples.

You can compact a database either from the desktop or on a Notes server. By default, the Compact task is configured to run as one of your nightly jobs. You should run Compact at least once a month.

When Notes compact a database, it first makes a duplicate copy of the database, so you must have at least enough disk space to hold two copies of the database. Compact then copies useful information from the copy back to the original database and throws away any excess left over. The temporary copy is then deleted.

Compact can only run against closed databases, which means that you must shut down the server to compact these databases. A database that is in use either by the Notes server or by a user cannot be compacted. If a user attempts to open a database while it is being compacted, he will get a message indicating that the database is being compacted. When building your server schedule, be sure to schedule the compacting process during your off-peak hours to minimize conflict with end users. Check with your Notes administrator to see if she has configured Compact to run automatically at night. (This is usually the case.) In this event, all that you need to do is make sure that your database is being compacted anytime that it has more than 10 percent white space.



NOTEServer administrators need to remember that certain databases that Notes keeps open all the time, such as the Address Book and log, can't be compacted while the Notes server is running. In this case, the administrator would need to shut down the server, start up the workstation on the server machine, compact these databases by hand, and then restart the server. (I repeatedly emphasize the point about not compacting open databases throughout this book; attempting to compact open databases is often the cause of overnight tasks not running correctly.)

To compact a notes database from the desktop, follow these steps:

  1. Click the database icon.
  2. Right-click the database icon to display the Database Properties dialog box.
  3. Click the Info tab.
  4. Select the Percent Used button. If the percentage used statistic for database falls below 90 percent (10 percent space wasted), you will want to compact the database.
  5. Click the Compact button to compact the database.

See Chapter 16, "Administering Notes Servers," for details on scheduling the Compact server task.

You can also use the Server Administration Panel to compact a database. This is the procedure:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel appears.
  2. Select the server that hosts the database you want to compact.
  3. Click the database icon.
  4. Choose Compact Database.
    A file selection dialog box appears.
  5. Select the database to be compacted.
  6. Choose Compact.
  7. Repeat steps 5 and 6 for any other database you want to compact.
  8. Choose Done.

One side effect of compacting a Notes Release 3.x format database is that the database is converted to Release 4.0 format. Give your Release 3.x databases an extension of .NS3 to prevent Compact from changing the format.

You also can use the Compact command to revert a Release 4 format database to Release 3 format. Enter the following command to change a database to Release 3 format:


Load Compact DatabaseFileName -r

Managing Indexes

Every view or folder for your database is backed up by an index. The view or folder only displays the information currently in the index. If you want your users to view up-to-date information, you need to keep your indexes updated.

Building indexes is one of the most server-intensive tasks in Notes, but you have some options for updating indexes:

You can use any combination of these settings. (Note here that we are talking about indexes for use in folders, not for full-text searching.) You can set the index update properties independently for every view and folder by following these steps:

  1. Open the design for the view.
  2. Choose Design | View Properties.
    The View Properties dialog box opens.
  3. Click the Advanced tab (the icon looks like a hat with a propeller).
  4. Select the desired setting from the Refresh Field drop-down list.

To build an index from the server console, type this command at the server console:


Load UPDALL databasename

Pay particular attention to the indexing settings on databases with more than 10,000 documents or with databases that have more than a combined 1,000 additions and deletions in a day. These databases take considerable time to keep updated. If you have them updated automatically at user access, users end up waiting.

Managing Full-Text Indexes

A full-text index is used differently than the indexes for folders. A full-text index is a search tool, not a presentation tool. A database must have a full-text index before you can perform full-text searches on the database. For example, in a human resources database of résumés received, assume that you want to find a person who has experience in Notes, OS/2, and NetWare. You would perform a full-text search against the human resources database by entering the words OS/2, Notes, and NetWare. All documents that contain all three of these words are returned. A full-text search is far more powerful than this simple example. Check your Notes documentation for full details on performing full-text searches. The focus here is on maintaining these indexes with minimal effort.

A full-text search is actually a collection of files stored in a subdirectory relative to the database. If you were to look at the hard disk, using a program like File Manager (under Windows), you would see that Notes creates a new subdirectory when it creates a full-text index. The name of the subdirectory is based on the database name. If the database is named Hresources.NSF, the full-text index will be in the directory HResources.FT. All the files comprising the full-text index are stored in this directory.



TIP A full-text index takes considerable disk space. The more items from the database you include in the index, the more powerful the searches you can perform. You can include the text from each document as well as attachments in your full-text index. But you will need to balance the disk space available and the search needs for each database.

You need manager or designer access to create a full-text index on a server database. No special access is required when creating a full-text index on your local machine. The only exception to this is if the local replica of the database was created with the uniform access control option selected. In this case, you also need manager or designer access to create a full-text index on a local copy on the local machine.



NOTENotes licenses technology from the Verity Corporation for the full-text search. Verity licenses this same technology to a variety of other database companies.


Estimating the Size of a Full-Text Index

Before creating a full-text index, make sure that you have adequate disk space. A full-text index can be up to 75 percent of the size of the text in your original database, depending on the content of the database and the options selected. The size of the full-text index depends primarily on two factors:

If you are concerned about the size of the full-text index, the Notes administrator can use the NOTES.INI variable FTMaxINSTANCE to control the number of words that Notes will index from a single document. If you include the line


FTMaxINSTANCE=2,000

Notes will index no more than 2,000 words per document. The default is 100,000 words per document. See Chapter 13, "Administrative Tools" for details on editing NOTES.INI.

Use the following formula to estimate the size of the full-text index.

database size ´ percentage of text ´ options factor = full-text size

where your options factor is .5 if you select Word Breaks Only, and .75 if you select Word, Sentence and Paragraph Breaks.

To create a full-text index, perform the following procedure:

  1. Open the Database Properties dialog box by right-clicking the icon for the database.
  2. Click the Full Text tab. Figure 17.2 shows the Database Properties dialog box with the Full Text tab selected.

    Figure 17.2.
    Creating a full-text index with the Database Properties dialog box.

  3. Choose Create Index.
  4. Select the desired options. (The options are described following these steps.)
  5. Choose OK.
  6. If you are building a full-text index in a local database, Notes presents a dialog box asking whether you want to create the index immediately. Choose OK.

When creating a full-text index, you can choose from several options. You can create a case-sensitive index, index all attachments, index encrypted fields, and/or choose to exclude selected words. The following list describes these options:

Full-text indexes can take a considerable amount of time to create. For very large databases with 80,000 to 100,000 documents or more, a Pentium computer can easily take 20 minutes to one hour to create the full-text index.

Replicating Full-Text Indexes

Full-text indexes don't replicate, but the fact that a full-text index should be created does replicate to all replicas of a database. The servers must have designer access in order to replicate the fact that a full-text index should be created. A full-text index is built on the replica copy when the UPDALL server task next runs.

Setting Full-Text Index Update Frequency

You can set a full-text index maximum update frequency after the full-text index has been created. Check with your Notes administrator before setting the frequency of your index update. The notes administrator can use the NOTES.INI file variable Update_Suppression_Time to limit the update frequency. For example, the administrator can insert the line


Update_SUPPRESSION_Time=5

to limit index updates to no more than one every five minutes. To control the full-text index update frequency, follow these steps:

  1. Display the Database Properties dialog box.
  2. Click the Full Text tab.
  3. Select the desired update frequency. Your options include immediate, hourly, daily, and scheduled:


TIP Choose your options carefully when creating a full-text index. If you later decide to change the options on your full-text indexes, you will need to delete and re-create your full-text index with the new options.

Deleting a Full-Text Index

You may be tempted to go to the directory and use a program such as File Manager to delete a full-text index. However, if you do, Notes simply rebuilds the index the next time the UPDALL task runs. To delete an index permanently, you need to use the Database Properties dialog box. Simply display the dialog box, click the Full Text tab, and choose the Delete Index button.

Moving a Database

When a server runs out of disk space, or you need to balance loads between multiple servers, you will want to move databases from one server to another. The data manager needs to work with the Notes administrator to determine when and where a database will be moved. The Notes administrator needs to make sure that proper connection documents are set up so that the database continues to replicate after it has been moved. You have two ways to notify your users of the database move:

No matter which method you use, make sure that your database continues to replicate after moving it from one server to another.

To move a database, you need to create a replica on the new server, delete the original base, update any Address Book documents, and notify users of the move. Before deleting the original database, make a note of the full file and path name. You will need this information to notify users of the move. To move a database, follow these steps:

  1. Select the database icon on the workspace.
  2. Choose File | Database | New Replica.
    Notes creates a new replica database. You can wait for the next replication to have the new replica initialized, or force a replication with the Replicate command.
  3. After a new replica has been initialized, delete the original database by selecting the original database icon on the workspace and choosing File | Database | Delete.
  4. For each replica copy of this database, remove the original server from the access control list, and add the new server's name to the access control list. If you are using group names (for example, LocalDomainServers and OtherDomainServers) or wild cards (such as */Server/Acme), you shouldn't need to perform this step.
  5. Update the Address Book. Be sure that you have the proper connection documents in place so that the new server can replicate changes to the database. Also, if the database was a mail-in database, you need to update the mail-in database document with the new location.

Of course, you can always skip steps 1 and 2 and use operating system commands to copy the file from one server to another.

These steps are ordinarily performed by the Notes server administrator.

Using Mail to Notify Users

If you know which users have been accessing the database on the original server, you can notify them with a mail message. A "database move" mail message contains some explanatory text and a single button. All users need do is select that button and the new database is added to their workspace. The button has a simple formula that adds and opens the new database.

Using a Move Notification Database

If you are not sure which users have been accessing a particular database, you can use a move notification database to notify users. A move notification database replaces the original database and simply tells the users about the move, providing a button to add the new database to the workspace.

You should create the move notification database after you have already created and initialized the replica on the new server. To create a move notification database, follow these steps:

  1. Choose File | Database | New Copy to create a new copy of MoveDB.NSF. Enter the full path and file name of the original database in the Destination Database field.
  2. Compose a move notification form and fill in each of the fields that apply. Specify both the location and name of the original database and the location and name of the new database. The formula for the button is as follows:

This formula uses only Release 3 features and works with both Release 3 and Release 4 databases. This method helps when you need to rename databases from an .NSF extension to an .NS3 extension (to prevent the compactor from changing the database's format).

When users attempt to access the database from the workspace, this notification document appears. All the user needs to do is click the button; Notes adds the new database to the workspace and deletes the icon for the move notification database from the workspace.

Using the Database Analysis Tool

The database analysis tool collects statistics from all the sources a database manager would otherwise need to check manually. Information is collected from the replication history, Notes log, and User Activity dialog box. The analysis tool collects information about

To collect information using the database analysis tool, follow these steps:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel opens.
  2. Select the server containing the database you want to analyze. (You can use any replica of the database.)
  3. Click the database icon.
  4. Choose Database Analysis.
    The Database Analysis dialog box opens, as shown in Figure 17.3.

    Figure 17.3.
    The Database Analysis dialog box.

  5. Click the Source Database button.
    The Database Selection dialog box appears.
  6. Select the database you want to analyze. You can choose a database on any server.
  7. Choose OK.
  8. Click the Results Database button.
    Notes posts the Results Database dialog box.
  9. Specify a results database. If the database doesn't exist, Notes will create it, using the Database Analysis template (DBA4.NTF). You should specify a database on the local machine to optimize performance.
  10. If you want to collect information from several analysis runs, select Append to This Database. Otherwise, select Overwrite This Database.
  11. Choose OK.
  12. Select the information you want to include in the analysis report.
  13. Specify the number of days' worth of documents to search.
  14. Choose Start to begin analyzing the database. Choose Start and Open to automatically open the analysis database once the collection routine finishes.

The analysis routine can take several minutes to complete.

The analysis report contains the following views:

Each document in the report contains the following information:

You should add the Analysis Report database to your workspace if you use the same one repeatedly. Set up one report database and collect information from all of your databases in it. If you manage several hundred databases, you will need to overwrite the existing database each time you run an analysis to avoid cluttering the analysis database.

Fixing Corrupted Databases

Database corruption occurs most frequently as a result of a server crash. Databases that are open when a Notes server crashes can have partially written documents or views. Databases that are open all the time, such as the Public Address Book and the Notes log, are the most likely databases to be corrupted.

Each database contains an internal flag that indicates that it was improperly closed. This flag doesn't automatically mean that the database is corrupted. When Notes encounters a database with this flag set, it runs the Fixup utility. The Fixup utility scans every field in every document in the database, checking for corruption. Corrupted documents can usually be fixed without loss of data, but sometimes a document is deleted. Document deletions due to corruption are not replicated to other copies of the database.

Notes can encounter the improperly closed flag in one of two ways. Notes checks the flag every time a database is opened. You also can have the Fixup utility scan all databases on a server, looking for improperly closed databases. The default Notes server configuration runs Fixup every time the server is started.

Fixup first checks the Notes log and then checks other databases. This scheme enables Fixup to log all activity on databases other than the Notes log. When run at system startup or as a result of opening a database, Fixup doesn't rebuild corrupted views. You must manually run fixup on a database to fix corrupted views.

You can run Fixup manually from the server console by typing this command:


Load Fixup DatabaseName parameters

DatabaseName is an optional database file name, including the path. The default is to scan all databases in the Notes data directory tree. Fixup cannot handle open databases, so make sure that no one is accessing a database when you run Fixup.

Table 17.1 describes the Fixup parameters.

Table 17.1. The Fixup command parameters.


OptionDescription
-L Logs every database suspected of being corrupted. The default is to log only actual problems.
-V Fixup doesn't check any views. This option reduces the time it takes Fixup to run.
-I Check only documents that have changed since the last time Fixup was used on this database.
-N No purge of corrupted documents. Corrupted documents are left intact so that you can attempt to salvage information. Fixup will need to be rerun on this database.

Fixup logs messages to the Notes log. At a minimum, each corrupted document or view generates a message in the log. You can determine the extent of damage to a database by reviewing the log after Fixup completes.

Running Fixup can take a very long time on servers with large databases or a large number of databases. Running Fixup on hub and mail servers can easily take 20 minutes to an hour. A server is unavailable while Fixup is running after a reboot. This means that if a large mail server crashes, users will not be able to access their personal mailboxes for up to an hour. To reduce the time it takes Fixup to run, run multiple fixups. You can run two Fixup tasks for each processor in the machine. It wouldn't help to try and run more, because Fixup uses a large amount of a CPU's time. To increase the number of Fixup tasks, set the Fixup_Tasks parameter in NOTES.INI to the desired number. Don't set this value at more than twice the number of CPUs in a system.

You should run Fixup manually only when you strongly suspect that databases have been corrupted or when you want to fix corrupted views. You can also schedule Fixup, using a program document in the Public Address Book. Fixup will fix corrupted views when run as a scheduled program. Because Fixup consumes so much system resources, you must avoid running it during peak hours. Run Fixup daily only if you have open time during the night when no other process is running and users will not be accessing the server.

Fixup is your best friend when it comes to corrupted databases. Always start by running Fixup when you suspect corruption. But Fixup isn't the only tool. Replacing a corrupted database at the file level, using a replica, is often faster than running Fixup. If you do copy a replica over a corrupted database, you will lose any updates that weren't yet replicated. You should always keep on on-line replica of key databases such as the Notes log and the Public Address Book. You can also use replicas as a way to restore documents purged by the Fixup task. Use the server console to force an immediate replication. Pull updates from the replica to the fixed database by entering the command


Pull servername

where servername is the server hosting the replica.

Pulling changes, rather than performing a full replication, will minimize the amount of time taken by this unscheduled replication.

If more than a few documents were purged, you should consider replacing the whole database file.

You can also restore purged documents by copying them from a replica. This technique is obviously useful only when a few documents need to be restored.

Fixing Corrupted Views

When a view is corrupted, you can use Fixup (as described in the preceding section), or rebuild the view from scratch. You can rebuild a view from the server console using UPDALL, from the user interface using Shift+F9 (to rebuild the current view) or Ctrl+Shift+F9 (to rebuild all views), or by creating a new replica of the entire database.

From the server console enter


Load Updall DatabaseName -R

to rebuild all views in a database.

When all else fails, create a new replica of the database and replicate all documents from the original database. View indexes are never replicated, so the replica will rebuild all views from the original data. You should create a new replica only when the other techniques have failed, because all documents will be marked unread.

Limiting Database Size

You can set a database quota to limit the size of a database. When a database reaches its maximum size, users will not be able to add documents. The only exception to this rule is personal mailboxes. When a personal mailbox reaches its quota, the router can continue to deliver mail, but the user will not be able to file new messages.

Notes server administrators set the database quotas for databases on their servers, but they should do this only after consulting with the database managers of the databases.

You must be listed in the Administrators field in the server document in the Public Address Book to set database quotas.

To set a quota for a database, follow these steps:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel appears.
  2. Click the database icon.
  3. Choose Database Quotas to display the Set Database Quotas dialog box, as shown in Figure 17.4.

    Figure 17.4.
    Set limits on database size by using database quotas.

  4. Select a database from the list.
  5. Select the Quota radio button and enter a maximum database size. The maximum must be greater than the current size.
  6. (optional) Select the Warn if > radio button and enter a threshold value. When the database size first exceeds the threshold, a warning appears in the Notes log. The threshold has no other effect.
  7. Choose Set.
  8. Repeat this procedure for all databases to receive a quota.
  9. Choose Done.

Consider placing quotas on personal mailboxes. This strategy lets you plan upgrades to the mail server. If you set quotas on mailboxes, make sure that users know how to archive mail that they want to save.

Summary

The duties of a database administrator overlap those of a server administrator. The server administrator can often process many databases at once, avoiding the need to have database administrators deal with a single database at a time. The tasks that can be accomplished by both a database administrator and a server administrator include

Because of this overlap, most organizations combine the roles of database administrator and server administrator. When these roles are split, administrators must constantly coordinate with each other. In this scenario, server administrators must coordinate the activities of all the database managers who have databases on the server.

The one activity that justifies separating the role of database manager is the need to control access to data. When the database manager's primary responsibility is managing the ACL, a nontechnical manager can play the role of database manager. The best choice in this situation is the manager responsible for the data contained in the database.

Database managers must always take responsibility for monitoring a database's performance, ACL, replication conflicts, and for fixing a database that has been corrupted.

Previous Page Page Top TOC Next Page