Managing login policies on read-only databases

When you start a database in a read-only mode, the login policies are based on the existing persistent state of the database. The effect of any login policies you assign is limited to the current session.

If login management is enabled on a database that you later start in read-only mode, the following restrictions apply:

  • Login management by the server is based on the state of the database before it is started.

  • Explicit statements that change the state of the database are denied and result in an error.

  • The server continues to maintain dynamic information, such as failed_login_attempts and last_login_time, for each user. However, this information is maintained in transient memory and is lost when you shut down the database. The database returns to the same state it was in before you started it.

  • If the account is locked by the existing login management policy, a user cannot log in. Also, the usual methods for changing a password during log in are unavailable.

  • If the database is read-only because of its role as a mirror database in a high availability system, then the effect of any statement executed on the primary database is reflected in the mirror database. Also, the dynamic information collected on the primary server is sent to the mirror database and is merged in transient memory with the information collected for the mirror database.

  • If the database is read-only because of its role as a mirror database in a high availability system or as a copy node in a read-only scale-out system, then the effect of any statement executed on the primary database is reflected in the read-only database. Also, the dynamic information collected on the primary server is sent to the read-only database and is merged in transient memory with the information collected for the read-only database.