2014-10-23 5 views

risposta

4

Non c'è tempo di inattività quando si cambia livello, l'ho fatto alcune volte. Il cambiamento non è immediato, ma richiede almeno 5 minuti, ma durante questo periodo funzionerà normalmente.

2

Non vi sono tempi di inattività durante la modifica di TIERS, ma sono presenti tempi di inattività durante la modifica dei modelli di fatturazione. Devi letteralmente fare il backup dei tuoi database, creare nuovi database nei nuovi modelli di fatturazione e ripristinarli. È quindi necessario modificare tutti i riferimenti del database in app o siti Web. Se desideri cambiare i livelli da un livello di fatturazione che non è più supportato, dovrai prima eseguire la migrazione al nuovo modello di fatturazione. L'abbiamo imparato nel modo più duro. Anche Microsoft non rende facile - non è un'operazione a pulsante.

+0

Sono passato da Web (ritirato) a S0 e non ho visto tempi di inattività. Anche questo dice che non ci sono tempi di inattività: http://azure.microsoft.com/blog/2014/07/08/azure-update-sql-database-easy-upgrade-to-new-service-tiers-performance-improvements -pitr-per-base-e-automatizzato-export-per-tutte-servizio-tiers / – jsgoupil

5

A seconda della definizione di "tempi di inattività". Ho cambiato i livelli di prestazioni molte volte. Passando da standard a premium abbiamo riscontrato molti errori. Eccone alcuni esempi:

System.Data.SqlClient.SqlException (0x80131904): A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) ---> System.ComponentModel.Win32Exception (0x80004005): An existing connection was forcibly closed by the remote host.

System.Data.SqlClient.SqlException (0x80131904): The ALTER DATABASE command is in process. Please wait at least five minutes before logging into database '...', in order for the command to complete. Some system catalogs may be out of date until the command completes. If you have altered the database name, use the NEW database name for future activity.

System.Data.SqlClient.SqlException (0x80131904): The service has encountered an error processing your request. Please try again. Error code 40174. A severe error occurred on the current command. The results, if any, should be discarded.

System.Data.DataException: Unable to commit the transaction. The underlying connection is not open or has not been initialized.

Il mio consiglio è di cambiare i livelli di prestazione fuori dalle ore o durante i periodi di manutenzione se possibile.

4

Come sopra, dipende dalla definizione del tempo di inattività. C'è un breve periodo in cui il tier cambia quando è possibile eseguire il rollback delle transazioni.

Da 'Scaling up o ridimensionamento ...' sezione di questa pagina: https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers

Note that changing the service tier and/or performance level of a database creates a replica of the original database at the new performance level, and then switches connections over to the replica. No data is lost during this process but during the brief moment when we switch over to the replica, connections to the database are disabled, so some transactions in flight may be rolled back. This window varies, but is on average under 4 seconds, and in more than 99% of cases is less than 30 seconds. Very infrequently, especially if there are large numbers of transactions in flight at the moment connections are disabled, this window may be longer.

Dal momento che "in-flight transazione" di solito si riferisce a una transazione che esegue quando una connessione viene interrotta, è sembra che entrambe le connessioni possano essere interrotte a metà transazione, oppure che le transazioni che operano su più connessioni potrebbero fallire e essere ripristinate se una connessione viene negata durante lo switch. In quest'ultimo caso, le transazioni semplici potrebbero non essere spesso influenzate durante il passaggio. Se il primo, i database occupati quasi sicuramente vedranno un certo impatto.