The arbiter server resolves disputes between the servers regarding which server should be the primary server. Without an arbiter, if server A starts up when server B is unavailable, server A can not determine if its copy of the database files is the most current. Starting a database using files that are not current results in the loss of transactions that have already been applied and committed to the other copy of the database. In addition, the other copy of the database would be unusable for mirroring once the two partner servers re-established communication.

In addition to resolving disputes at startup, the arbiter is involved if the communication link between two servers is broken, but both of those servers are still running. Without an arbiter, both servers could assume that they should take ownership of a database. Again, this would result in lost transactions and incompatible databases. With an arbiter, the primary server can verify that it still owns the database and can remain available to clients. If the primary server loses communications with both the mirror and the arbiter, it must shut down and wait for either one to become available.

An arbiter server can function as arbiter for more than one mirror system. It can also act as a database server for other databases.