many Servers of SQL server 2012 needs mirroring I have now simply 2 SQL Server 2012.
I want to configure database mirroring between the 2 servers.

My questions are:


How can it automatically change host of one if the other one was dropped ?
Is the performance of mirroring acceptable and is there another way to make one as host and other is backup then if the main server was dropped the other works automatically better than mirroring?
How can it automatically change host of one if the other one was dropped ?

From the client application side, your application connection string should use FailoverPartner pointing to secondary or mirrored server.

If you connect with ADO.NET or the SQL Native Client to a database that is being mirrored, your application can take advantage of the drivers ability to automatically redirect connections when a database mirroring failover occurs. You must specify the initial principal server and database in the connection string and the failover partner server.

Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;
Initial Catalog=myDataBase;Integrated Security=True;

From database side, if you are running with a witness in high-safety mode (high-safety mode with automatic failover), then ONLY you will have flexibility of automatic failover, rest are manual failover.
Even though, mirroring allows you to do automatic failover in high-safety mode, make sure your keep monitoring the REDO queue as this can impact the recovery during a failover scenario.
FROM BOL :

Rolling forward the database involves applying whatever log records are currently in the redo queue on the mirror server.
The redo queue consists of the log records that have been written to disk on the mirror server but not yet rolled forward on the mirror database.
Failover time for the database depends on how fast the mirror server can roll forward the log in the redo queue, which, in turn, is determined primarily by the system hardware and the current work load. Potentially, a principal database can become so busy that the principal server ships log to the mirror server much faster than it can roll the log forward. In this situation, failover might take significant time while the mirror server rolls forward the log in the redo queue.
Is the performance of mirroring acceptable and is there another way to make one as host and other is backup then if the main server was dropped the other works automatically better than mirroring?

To monitor performance, you need to monitor and baseline your server instance using :

On the principal:

Log Bytes Sent/sec: Number of bytes of the log sent to the mirror per second.

Log Send Queue KB: Total kilobytes of the log that have not yet been sent to the mirror server.

Transaction Delay: Delay (in milliseconds) in waiting for commit acknowledgement from the mirror. This counters reports the total delay for all the transactions in process at that time. To determine the average delay per transaction, divide this counter by the Transactions/sec counter. When running asynchronous mirroring this counter will always be 0.

Transactions/sec: The transaction throughput of the database. This counter is in the Databases performance object.

Log Bytes Flushed/sec: The rate at which log records are written to the disk. This is the log generation rate of the application. It plays a very important role in determining database mirroring performance. This counter is in the Databases performance object.

Disk Write Bytes/sec: The rate at which the disk is written to. This counter is in the Logical Disk performance object and represents. Monitor this counter for the data as well as the log disks.


On the mirror:

Redo Bytes/sec: Number of bytes of the transaction log applied on the mirror database per second.

Redo Queue KB: Total kilobytes of hardened log that remain to be applied to the mirror database to roll it forward.

Disk Write Bytes/sec: The rate at which the disk is written to. This counter is in the Logical Disk performance object and represents. Monitor this counter for the data as well as the log disks on the mirror.

As a side note, you need to take care of migrating jobs, ssis packages, logins, etc once you failover to secondary or mirrored database.