November 2007 Archives

Often people are confused by how to configure their ALUI portal to run with a SQL Server configured to run with a named instance. This post will quickly review what this database configuration is, then it will explain how to run the portal with such a configuration.

MSSQL 2000 and 2005 allow multiple instances of the database to run on the same installation. When you create these instances, you distinguish them by a name that lets you refer to them in a human-centric way and a port number that is used across the network in a computer-centric way. For example, I might create a SQL Server instance named stagingdb to run on port 2048.

You can see how your server is configured as follows:

  • Go to Programs -> Microsoft SQL Server 2005 -> Configuration Tools -> SQL Server Configuration Manager.
  • Within that tool, go to SQL Server 2005 Network Configuration -> Protocols for {instance-name} -> TCP/IP Properties
  • Go to the IP Addresses panel, then scroll down to the TCP Dynamic Ports to see what port number corresponds to the instance.

 named-instance-config

Microsoft tools such as Query Analyzer and SQL Server Management Studio let you connect to this in a friendly way, for example, I can specify that I want to connect to the database "mymachine\stagingdb," then behind the scenes it will connect on port 2048 to that instance.

However, if I have a Java application that is not aware of the Microsoft concept of named instances, then I will need to connect to it using the database "mymachine" and the port "2048."

So what about your portal? When you go through the Portal Configuration Manager (which has the same UI for Java and for .NET portals), the common UI doesn't allow you refer to your database using the instance name. You've got to drop the name and just use the port. For example, on my machine, I have this:

 portal-config-named-instance

Notice that even though the Portal Configuration Manager prompts me with the default MSSQL port of 1433, I put in 1555. Also notice that even though my instance happens to be "localhost\SQLEXPRESS," I refer to it here as simply "localhost."

How to Revive a Failed Search Node

| | Comments (2)
I recently posted about how to restore a search cluster that has failed. Step 1 was to make sure all the nodes are running. But what if one of the nodes won't start? What do you do when a node itself is corrupted?

Ironically, you can't use the tools to reset a node if the node is broken and won't start. But you can go on the file system and clean it up with these steps--though make sure the node really is stopped before you do this.

In shorthand for the Unix-minded:

set search_home=d:\bea\alui\ptsearchserver\6.1
set node=alui-ss-0101
rm -rf %search_home%\%node%\index\*
mkdir %search_home%\%node%\index\1
echo 1 > %search_home%\%node%\index\ready
cd %search_home%\%node%\index\1
..\..\..\bin\native\emptyarchive lexicon archive
..\..\..\bin\native\emptyarchive spell spell

Or more prosaically for those who prefer Windows and a mouse:

  1. Go into the index folder of the node. On my machine, it's d:\bea\alui\ptsearchserver\6.1\bbenac0201\index.
  2. The index folder will contain a folder named 1. Open this folder and delete all its contents.
  3. The index folder may also contain a folder named 2. If this is the case, delete the folder 2.
  4. The index folder should contain a file named "ready." Open it and make sure it contains just the number 1. This "ready" file tells the node to look within folder 1 for its content.
  5. Open a command prompt within the folder 1.
  6. Run these commands, the first of which should create about 8 files, the second of which should create about 7:
    ..\..\..\bin\native\emptyarchive lexicon archive
    ..\..\..\bin\native\emptyarchive spell spell
At this point, you should be able to start your node. It will contact the search cluster and populate itself with the current search index.
Ever have problems with your search cluster getting corrupted? One way to fix it is to wipe it out and reindex everything, but that may take 24 hours. A better approach is to use the feature of scheduling checkpoints to backup your cluster daily, then restoring that checkpoint if corruption occurs.

If your ALUI system isn't set to do daily checkpoints, configure them as follows:

  1. Browse to the portal's admin section, then select the utility "Search Cluster Manager."
  2. In the left navigation, select "Checkpoint Manager."
  3. On the far right, click "Initiate Checkpoint" to open the Checkpoint Scheduler.
  4. Select the "Scheduled" radio button, select today's date, set a time, and set it to repeat every 1 day. Click OK.
  5. After the Checkpoint Scheduler closes, you'll see in the "Checkpoint Activity Status" section when the next scheduled checkpoint will run.
  6. Click "Finish" and your system will then backup your search index daily into checkpoints.

If at some point you realize your cluster is corrupt and you need to restore it, and you've been creating checkpoints periodically, then:

  1. Makes sure all the nodes in the search cluster are started. If one of the nodes won't start, you might want to use these instructions to revive it.
  2. Browse to the portal's admin section, then select the utility "Search Cluster Manager."
  3. In the left navigation, select "Checkpoint Manager."
  4. In the center of the screen you'll see a list of checkpoints. The most recent ones will show themselves as "Available" in the last column.
  5. Click on the checkpoint you want to restore. Its row will change from white to light green.
  6. Click the "Restore Checkpoint" button on the right side of the screen below the list of checkpoints.
  7. Watch the "Checkpoint Activity Status" section to see status. Use the refresh button at the top of the screen to update status. It may show messages like "Node pswwwlab-0301 completed copying - 0%."
  8. When it completes, you'll see in the "Named Restore Status" area something like this:
    Cluster is currently in a named restore state.
    Cluster restored from c:\\bea\\alui\\ptsearchserver\\6.1\\cluster\checkpoints\0_1_0.
    The named restore state - SUCCEEDED.
    The named restore must either be discarded or committed.
  9. Finally, you must "Commit" the checkpoint by using the "Commit" button at the bottom right of the screen.
  10. At this point the search cluster will be restored.

Note that by default, the most recent three search checkpoints are stored. So on the fourth day, the first checkpoint gets deleted. In some cases, you may prefer to have more or fewer checkpoints. If this is the case, then edit the cluster.ini file in your search cluster. Add the following new parameter to set the desired number of saved checkpoints, in this case, 2:

RF_NUM_CHECKPOINTS_SAVED=2

If you're lucky, you'll never need to restore a checkpoint. But you'd better be prepared. So make sure you've set this up!