they were in one of the lists in the section David linked to, but now they are in all four. thanks for catching this David!

William, is it possible that the DR async and failover members do not have all of the needed encryption keys loaded? See Activating Journal Encryption in a Mirror in the High Availability Guide. This text applies to releases supporting multiple encryption keys; what release are you running?

please see Murray Oldfield's Caché VMware Best Practice Guide. this extensive and thorough review has a brief section addressing your topic; you could follow up with Murray if you have further questions. 

it is not enough for the restored database to be colocated with the Caché instance on the target server. the new database must be configured within Caché.

1. in the management portal on the target system, select System Administration > Configuration > System Configuration > Local Databases.
2. on the Local Databases page, click the Create New Database button.
3. on the first panel of the Database Wizard, enter a name for the new database and the local path to the database you restored to this host, and click Next.
4. the next panel says:
   Database file, CACHE.DAT, already exists in directory. If you do not want to use it, please press the [Back] button and modify the Directory.
5. click Finish to configure the database. other than the name, the characteristics of the source database you backed up are carried over to the newly configured database on the target system.

Raghu,

For information on configuring the journal directories using the management portal, please see Configuring Journal Settings in the Caché Data Integrity Guide. You can also configure the WIJ directory using the page described there.

It looks like you probably saw the general discussion of best practices regarding  the separation of journal, WIJ, and database directories in File System Recommendations in the Caché Installation Guide. I will make sure to update this section with an explicit link to the above section, and make it clear that these directories are not specified during installation. (For a separate discussion of journaling best practices regarding the locations of these directories, see Journaling Best Practices, also in the Data Integrity Guide.)

rcb

The section Defragmenting Globals in a Database (http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSA_manage#GSA_defrag_databases_freespace) in the  System Administration Guide says:

In general, it is not necessary to run defragmentation on any regular basis. Some workloads, however, particularly those that read large portions of a database sequentially, can benefit from having global blocks organized sequentially. 

This section was carefully revised a couple of releases ago and that advice represents current wisdom about the operation. Defragmenting globals is preferred over OS-level defragmentation.

See that section also for information about scheduling the operation and other concerns.

yes, now i see the problem.  i didn't realize there is no option for installing a standalone agent in a different directory; i've never done it, and i assumed since you were installing it on an system without Caché you would be able to choose the installation directory. (of course, if that were the case, it should have been noted in the ISCAgent section in the Mirroring chapter.) adding that as you suggest seems to make a lot of sense. but that would need to be validated by Tom Woodfin and the mirroring team.

have you filed a prodlog on this?