Ondblog Modifying the Informix log mode

-N No Logging no logs
-U unbuffered Logging non-buffered log
-B Buffered Logging buffer log
-a unbuffered Logging, mode ANSI ANSI modes
No Logging no logs
----"No log" mode writes only a small amount of information to the logical log, which records only the DDL statements that are executed, and the rows affected by the statements are not written to the log, only the command itself and the code that is returned. A database environment without logs can have a high throughput rate, but is not capable of rebuilding changes to the database in the event of a serious instance failure. The changes written to the disk are all the information you can get. Recoveries that do not have a log database in an instance can only be made in the last instance backup that was created.

unbuffered Logging non-buffered log
----A database environment that uses "unbuffered log" mode whenever a transaction commits, the physical and logical log buffers containing the transaction information are flushed to disk.
----use of non-buffered logs, data integrity and consistency can be guaranteed at the transaction level, even if serious instance errors occur. However, because each commit transaction causes the buffer to be flushed to disk, disk I/O is increased. Also, because refreshes write the entire buffer contents to the logical log according to the progress of the current transaction, there is a lot of unused data in the logical log pages. The log fills up quickly, but the "real" data contained in it is much less than the buffer log database environment.

Buffered Logging Buffer Log
----A database environment that uses buffered log mode retains these transaction information in both the logical and physical log buffers until the buffer fills up, or a checkpoint operation occurs, or the user connection that generated the transaction is closed before the transaction has been written.
----There is a situation where the buffered log database is forced to write out its transactional information: because there is only one set of logical log buffers in the instance, when a transaction is committed by a non-buffered log database in the instance, the buffered log information is written out to disk along with the non-buffered log information.
----in the buffered logs database environment, the disk I/O caused by each transaction is greatly reduced, so the instance runs faster, but because transaction information is stored in shared memory, serious instance errors can be dangerous, and when the shared memory of the instance is freed, transaction information that has not yet been written to disk is lost.

* The non-buffered log mode and the buffered log mode operate exactly the same way, depending on when the log records are written to disk,

unbuffered Logging, mode ANSI ANSI mode
----ANSI Mode operates the same way as non-buffered logs, but it also enforces consistency with ANSI transactions. ANSI conformance includes features and rules such as the unique owner name of the reference table, the different default values for table-level permissions, the ability to read and update cursors, and the difference between the character and decimal data types over the data type or how the definition statement reacts.
*online dymanic server does not strictly enforce compliance with all ANSI standards in an ANSI database environment, and if you execute a non-ANSI SQL statement, the instance generates a warning message but still handles it down. Unless the operating environment requires the use of ANSI standards, there is no benefit to using ANSI mode.

To change the log mode with ONTPAE:
Ontape–n Sales Changes the database "sales" from one-u,-b,-a mode to the-n mode,

Ontape–u Sales Changes the database "sales" from-N to-u mode,

Ontape–b Sales changes the database "Sales" from-N to-B mode,
Ontape–a Sales changes the database "Sales" from-N to-a mode,
*Ontape tool in-u,-b,-a three modes any one of the changes to another does not need to create a system backup;
To change completely from a log mode to a log mode, or vice versa, you need to create a level 0 backup;

To change the log mode with Ondblog:
The Ondblog tool simply sets a flag that indicates what the database log schema will be changed to after the next level 0 backup.

The options for the Ondblog tool are as follows:
Nolog changing the database to no log mode
Unbuf Non-buffered logs
BUF buffer Log
ANSI ANSI logging mode
Cancel cancels the previously made request to change the log mode

Additional options:
1. With some database names separated by spaces, the log patterns for these databases will be changed.
The 2.–F option is followed by a file name that contains the name of the database for which you want to change the log mode, which are listed separately in the file and one row.
* If there is no –f file name and no space-separated database name, the Ondblog tool will change all databases in the instance to the required log mode after the next level 0 backup.
* Whether you use the Ontape tool or the combination of Ondblog and ontape to change the log mode of the database, the instance does not have to be in the quiescent state, but when attempting to change the log mode, no active user threads can be connected to the instance. Otherwise, a "-107" error is generated.
* If the ontape command has been executed to change the log mode of the database and is interrupted in the middle, the database is still closed for user connections until a full instance backup is created, regardless of whether or not you want to change the log mode

View the log mode of the database by using the following statement

echo "SELECT * from sysdatabases" |dbaccess sysmaster

Ondblog Modifying the Informix log mode