Max_identity column values, column histograms, and other catalog metadata are persistently saved to the catalog whenever the server does an explicit or implicit CHECKPOINT.

LOAD TABLE is one statement that issues an implicit CHECKPOINT because it performs page-level undo if the LOAD TABLE fails. In addition to LOAD TABLE, the following statements in Version 12 (Innsbruck) will trigger an implicit or explicit CHECKPOINT, and hence cause the metadata for AUTOINCREMENT columns to be written to the catalog:

• LOAD TABLE statement
• CHECKPOINT statement
• REFRESH MATERIALIZED VIEW statement
• BACKUP statement
• REORGANIZE TABLE statement
• COMMIT statement when the database does not have a transaction log
• CREATE INDEX statement on a function (a computed column)
• ALTER TABLE statement - unless the ALTER TABLE trivially adds a nullable column or adds a referential integrity constraint and does not need to physically modify the table's pages in any way
• ALTER INDEX REBUILD statement
• DROP TABLE and DROP MATERIALIZED VIEW statements, but only if the table or view contains at least one row
• CREATE DBSPACE statement
• DROP DBSPACE statement

Most, though unfortunately not all, of these statements document the side-effect of a checkpoint in their specific documentation, usually in the "Side Effects" section. However, I noticed a few (such as CREATE DBSPACE) that did not do so - and I have corrected this in the 12.0 documentation.