Converts the specified container, database, or federated database so that its storage pages use the specified disk format.
(-db dbSysName [-cont contSysName] | -id oid | -fd | -all)
(-db dbSysName [-cont contSysName] | -id oid | -fd | -all)
System name of the container to be converted. If you use this option, you must also use the -db option to specify the database that contains this container. If you use this option, you cannot use the -id, -fd, or -all option. If contSysName contains spaces, you must enclose it in double-quote (" ") characters.
Converts just the system database. (HA) If the federated database is partitioned, all images of the system database are converted.
Reports the number of storage pages whose disk format would be changed. No format conversion is actually performed.
New owning architecture for the specified storage pages in the container, database, or federated database being converted. This architecture defines the disk format that will be used by these pages after conversion. If you omit this option, the default is the architecture of the host on which you are running this tool.
The newArch value must be an architecture name recognized by Objectivity/DB. For a list of the recognized architectures, run this tool with the -help option.
Note: When converting from a 32-bit to a 64-bit architecture, some basic objects might no longer fit in their original storage space due to an increase in the class’s size. Such an object is automatically redirected to a page with more space, and a link to its new location is maintained by a redirection stub left in the original location.
Current owning architecture of the storage pages to be changed in the container, database, or federated database being converted. If different pages are owned by different architectures, only the pages currently owned by oldArch will be changed to the disk format defined by newArch. If you omit this option, the default is to change any storage page that is not already owned by newArch, regardless of its current owning architecture.
The oldArch value must be an architecture name recognized by Objectivity/DB, as described for the -format option.
The special value none suppresses disk-format conversion. This is useful if want to perform only object conversion (with the -convertobjects option).
Performs object conversion on any objects affected by prior schema evolution. Omitting this option converts the disk format of storage pages without performing object conversion on any affected objects.
(Objectivity/C++) This option releases any marked classes from upgrade protection, if necessary, before converting objects in an entire federated database.
Suppresses the copyright notice and program title banner. Useful when invoking the tool from another tool or product.
Prints the tool syntax and definition to the screen, including a list of the architectures supported by Objectivity/DB.
Path to the boot file of the federated database containing the storage pages to be converted. You can omit this argument if you set the OO_FD_BOOT environment variable to the correct path. (HA) You can specify the boot file of any autonomous partition.
This tool changes the disk format of storage pages by specifying a new owning architecture for those pages.
By default, this tool causes the architecture on which it is running to be the new owning architecture of all storage pages in the specified container, database, or federated database. You can add the -format option to specify a different owning architecture.
You can add the -from option to change only those storage pages currently owned by a particular architecture. For example, you might want to change just the pages owned by a particular UNIX architecture so they are owned by another UNIX architecture, without affecting any pages owned by a Windows architecture.
Changing the disk format of a storage page has no effect on the object identifiers (OID) of persistent objects on the page—that is, no logical page numbers or slot numbers are changed.
If you specify multiple containers (for example, by specifying a database), each container is processed in a separate update transaction; the transaction for one container commits before the next one begins. Consequently, ooconvertformat locks at most one container at a time, and conversion can take place while concurrent applications are running. After processing each container, this tool reports the container’s identifier, the number of converted pages, and the number of pages that did not need converting.
You can use the -lockwait option to specify how long ooconvertformat should wait for an update lock on each container. If this tool cannot obtain a lock on a particular container, the container is skipped, an error is reported, and the next container is processed.
Changing the disk format of a storage page creates a new version of the page and deletes the original version. For best space usage, you should eliminate the resulting unused free space by tidying any database in which a large number of pages have been converted. You can obtain a list of databases that may need tidying by specifying the -showtidy option.
Specifying the -convertobjects and -from none options enable you to use ooconvertformat as a tool alternative for converting objects in a container, database, or federated database after schema evolution has been performed. For more information about object conversion after schema evolution, see the documentation for your Objectivity/DB programming interface. (Objectivity/C++) When used for object conversion in an entire federated database, ooconvertformat functions as an upgrade application; otherwise, when used for object conversion in a container or database, the tool functions as a conversion application.
Converting a database or a system database affects only the disk format of its storage pages, and does not affect its internal database format. In particular, converting a pre-Release 9.0 database does not give it the properties of a Release 9.0 (or later) database.
Tuesday, October 30, 2012