A: Replication is unaffected by Transactional Logging. Changes are available in the same manner as they are for un-logged databases. Changes are always read from the in-memory versions of databases when they are open and all cached changes are flushed when databases are closed.
Q: If a user is trying to read a note that has not been committed to the NSF with transactional logging enabled does the user session read the note from the transactional log, the UBM or is the note committed to the database first?
A: The note is read from the in-memory versions of databases when they are open and all cached changes are flushed when databases are closed.
Q: If something is done to change the DBIID of a database, are changes committed first before the DBIID gets changed?
A: Yes. Data is not lost. Things that change the DBIID, such as Fixup -J and Compact -B, change the DBIID because they are making database changes that are not logged. The order of operations is this:
(1) Flush all in-memory changes to the database
(2) Clear the DBIID and halt logging for the database
(3) Make the un-logged changes
(4) Flush all in-memory changes to the database
(5) Assign a new DBIID and start logging changes to the database again.
Note: None of these steps can be done manually; all of them are done automatically. The one manual step is to take a new backup of the database after you see the console message "Assigning New DBIID for DB xxxx."
Q: When is it beneficial to run fixup -j?
A: Hopefully never. It would be beneficial only if the database became corrupt and you did not have a backup to roll forward from.
Q: When fixup -j is run on the entire server I notice that it assigns a new DBIID to some databases but not others. Why is this?
A: Transactional logging should reassign the DBIID's for all transactionally logged databases. Fixup -j will run against unlogged as well as logged databases, so the logging status should be checked of the databases that didn't have a DBIID re-assigned to them and validate that it is not logged.
Q: If the DBIID of a database has changed for some reason, how is the database with the old DBIID and the new DBIID incorporated?
A: There is no intermixing. You must re-backup a database when the DBIID changes. Note: there is no relation to the REPLICAID or DBID.
Q: If a server panics and upon restart Domino automatically performs database recovery, will a large amount of data be lost or is the loss minimal?
A: All cached info will be re-applied and only partial API calls will be backed out. That is, if the server was in the middle of a NoteUpdate call, that would get undone. You will see EVERY NOTE you ever added (and the API call returned) with no loss of data. The Transactional Log is written directly, with no file cache (i.e. all writes are "committed" and writes are done to the Transactional Log at least after each transaction or API call).
Q: If only one database on a server becomes corrupt is it possible to restore only this one database from the transactional log or will the entire transactional log need to be replayed?
A: Transactional Logging restores only the database(s) that need to be. The whole log from the time of the backup must be replayed but only records pertaining to the databases being recovered will be processed.
Q: What is the control file used for?
A: It is used by the logger subsystem to know the state of the log files. The logging subsystem is all of the code in nsf\logger, where some of it runs in the "application" process, meaning in the process that makes logging calls (ex. the server, etc).
Q: If there are any databases or directory links on the server, will these databases be transactional logged as well?
A: Yes the actual database will be logged independent of links.
Q: If Compact changes the DBIID then what happens to a backup copy of the database? Will the log be able to recover in the event a database is replaced on-line?
A: It assumes you did not copy back an older version of the database while the server was crashed. Never "touch" databases after a server crash until you get through a clean restart. You can start a clean restart by simply entering the command "nfixup zzzz" before the Domino server is restarted (where zzzz is a database that does not exist). The initialization of fixup will trigger the restart and recover the logged databases to a clean state. This will clear the UBMand will harden all the information to the transactionally logged databases (the actual NSF), then the server can be restarted. Consistency check will run against all non transaction logged databases.
Q: When the server is live, how is it possible to monitor the health of the transactional log?
A: Any extra "monitoring" of the log at run-time is not recommended as it will disturb your system performance. The log is not read very much while the server runs so it is true that issues with the logs would not soon be noticed; however, the log is written to constantly and all hardware would give a bad return code and generate error events if write errors occurred.
Q: The customer uses FTP to move NSF files between "live" servers. Can the Transactional Log recover from finding a new database live while the server is running?
A: IMPORTANT: Never OS copy or FTP a live logged database. The reason is that a new replica creates a replica stub on the new server, then populates the database later, preserving the state of the transaction logging. An OS copied database will be subject to a consistency check when it is placed on the new server.
It is acceptable however to pull or create a new database replica of a live logged database. A new replica creates a replica stub on the new server, then populates the database later, preserving the state of the TL. An OS copied db will be subject to consistency check when it is placed on the new server.
There are no known problems adding new databases (new databases do not have a DBIID yet) to a server "live", but you must get a "clean" version and you should make it appear "instantaneously" so it does not show up as only half there, as it would when you FTP it.
The recommendation is as follows:
- Use dbbackup from API Sample or a backup vendor's backup (dbbackup test tool takes a backup and "applies all pending changes" so it's a healthy backup). Make the extension of the database something non N* line .bak.
- FTP or copy the bak file to the other server.
- Rename the bak to nsf so it "appears" instantaneously.
- The next open will assign a new DBIID and run fixup if it was logged before, to clear the log sequence numbers in the file. It may take a while if it was a large database, but then it will behave normally.
An existing database that is not open that needs to be moved from one server to another should be done using Notes\New Copy or New Replica. Prior to the move, the extension should be changed to something other than .nsf. The database can then be moved via new copy or new replica. When the move is complete, the extension should be changed back to .nsf. This method ensures that transactional logging begins logging the database only when it is complete and consistent. It is important to note that this will change the DBIID of the database so a backup must then be taken.
Q: A database on a Domino server is continuously becoming corrupted and is then being marked as read only. If transactional logging is enabled on the server will it mark the database as read only?
A: The only thing that transactional logging will do is mark the database corrupt. It will never mark the database as read only.
Q: How does transactional logging operate with SCOS (shared mail)?
A: The capability to have transactional logging for SCOS in R5.x does not exist. This capability is present in Notes/Domino 6.
No comments:
Post a Comment