This view shows the state of orphan partitions (orphans are partition databases that exist on a node but are either detached or not referenced in metadata).

This view is also available as an LMV (local view per node) view.

Column Name



The node ID of the node where this partition instance is hosted.


Internal ID for replication management. Useful for cross-referencing with tracelogs.


The ID of this instance's distributed database, in the sharded database table of cluster database metadata.


This partition's ordinal. Database partitions are assigned numeric identifiers. For example a database named testdb would have partitions named like testdb_0, testdb_1, etc. In these cases, 0 and 1 would be the ordinals.


The ID of the node this partition instance exists on. For orphans, this will always match the value in the NODE_ID column, but is exposed since it is used internally.


Name of the partition database.


The outcome of the last action performed on this partition instance.


The role of this instance in cluster metadata. Possible values: Non-existent, Master, Sync Replica, Ready Replica, Async Replica, Unrecoverable, Paused Replica.


The role of this instance locally on the node where it exists. Possible values: Master, Replica, Transitioning, Dropping Or Reprovisioning, Unrecoverable, Recovering, Missing (disconnected).


Whether this orphan could potentially block transactions, and thus needs to transition offline.


Whether there is an incomplete asynchronous task still pending.


The ID of this instance in the partition instances table of cluster database metadata.


The ID in cluster metadata of the master instance for this partition. Only non-NULL for remote replicas, and local masters.


Counts the number of times there has been a metadata state change. Not relevant for orphans.


Whether this is a partition of a DR database.


Whether the master instance for this partition ordinal exists and is online.


Whether this is an unlimited storage database with its remote storage dropped, and thus it is not usable.


Term uniquely identifies a period during which an instance of a partition is a master. The transition term refers to the term chosen for the most recent transition on this partition, and is used to avoid taking actions based on out-of-date metadata.


Term uniquely identifies a period during which an instance of a partition is a master. Only defined if there is an instance that is a non-DR master, otherwise it is 0.


The last iteration counter on which this state was updated. Used to cross-check with the other replication management tables.


What action the system will take on this partition to move it to a success state, or nothing if the partition is already in a success state, or if it is impossible to correct its state.


The success states of all partitions are aggregated to form a global success state. Possible values include: Success / Soft Failure / Hard Failure.

Success: the most recent iteration of the replication management thread ended successfully, with local state matching metadata state.

Soft Failure: the local state doesn’t match metadata state, but there is no mismatch that impacts the correct functioning of the cluster (for example, if all that’s wrong is a disconnected async replica, then the cluster is technically healthy, although it is replication management’s responsibility to reconnect it, so we’d be in this state), and thus it is not blocking the advancement of SUCCESSFUL_CLUSTER_LSN.

Hard Failure: the local state does not match metadata state in a way that impacts the correct functioning of the cluster (for example, if a sync replica is disconnected), and will block the advancement of SUCCESSFUL_CLUSTER_LSN.

Last modified: September 14, 2022

Was this article helpful?