Domande frequenti sul database SQL

Qual è la versione corrente del database SQL?

La versione corrente del database SQL è V12. La versione V11 è stata ritirata.

Qual è il contratto di servizio per il database SQL?

Microsoft garantisce che per almeno il 99,99% del tempo i clienti avranno a disposizione la connettività tra il database SQL di Microsoft Azure Basic, Standard o Premium, singolo o elastico, e il gateway Internet. Per altre informazioni, vedere Contratto di servizio.

Come si reimposta la password per l'amministratore del server?

Nel portale di Azure fare clic su SQL Server, selezionare il server dall'elenco e quindi fare clic su Reimposta password.

Come si gestiscono database e accessi?

Vedere Gestione di database e accessi.

Come si può garantire che l'accesso al server sia consentito solo agli indirizzi IP autorizzati?

Vedere Procedura: configurare le impostazioni del firewall su Database SQL mediante il portale di Azure.

Come viene indicato l'utilizzo del database SQL in fattura?

Database SQL emette fattura in base a una tariffa oraria stimabile in base al livello di servizio + il livello di prestazioni per database singoli o eDTU per ogni pool elastico. L'utilizzo effettivo è calcolato e ripartito su base oraria. È quindi possibile che nella fattura siano indicate frazioni di un'ora. Ad esempio, se un database esiste per 12 ore in un mese, nella fattura viene indicato l'utilizzo di 0,5 giorni. Inoltre, i livelli di servizio + i livelli delle prestazioni e le DTU per ogni pool sono suddivisi in fattura per permettere di vedere più facilmente il numero di giorni di database utilizzati per ognuno di essi in un singolo mese.

Cosa succede se un database singolo è attivo per meno di un'ora o utilizza un maggiore livello di servizio per meno di un'ora?

Viene fatturata ogni ora per cui un database esiste utilizzando il livello di servizio più elevato + il livello di prestazioni applicati in quell'ora, indipendentemente dall'utilizzo o dal fatto che il database sia stato attivo per meno di un'ora. Ad esempio, se si crea un database singolo che viene eliminato cinque minuti dopo, in fattura viene riportato l'addebito relativo a un'ora di database.

esempi

  • Se si crea un database di livello Basic e quindi si esegue immediatamente l'aggiornamento al livello Standard S1, sarà addebitata la tariffa Standard S1 per la prima ora.
  • Se si aggiorna un database da Basic a Premium alle 22:00 e l'aggiornamento viene completato alle ore 01:35 del giorno successivo, viene addebitata la tariffa Premium a partire dalle ore 01:00.
  • Se si esegue il downgrade di un database da Premium a Basic alle 11:00 e viene completato alle 14:15, viene addebitata la tariffa Premium per il database fino alle 15:00 e successivamente viene addebitata la tariffa Basic.

Come viene indicato l'utilizzo del pool elastico nella fattura e cosa accade quando si modificano le eDTU per ciascun pool?

Gli addebiti relativi ai pool elastici vengono riportati in fattura come DTU elastiche (eDTU) sotto agli incrementi indicati nelle eDTU per ciascun pool nella pagina relativa ai prezzi. Non è previsto alcun costo per database per i pool elastici. Viene fatturata ogni ora che un pool esiste con le eDTU più alte, indipendentemente dall'utilizzo o dal fatto che il pool sia stato attivo per meno di un'ora.

Esempi

  • Se si crea un pool elastico Standard con 200 eDTU alle 11:18, con l'aggiunta di cinque database al pool viene addebitato il costo di 200 eDTU per l'intera ora a partire dalle 11:00 e per la restante parte della giornata.
  • Nel giorno 2, alle ore 5:05 di mattina, il Database 1 inizia a utilizzare 50 DTU e rimane stabile per tutto il giorno. Il Database 2-5 fluttua tra le 0 e le 80 DTU. Durante il giorno vengono aggiunti altri cinque database che utilizzano DTU che variano nel corso della giornata. Il giorno 2 viene fatturato interamente a 200 DTU.
  • Il terzo giorno alle 05:00 vengono aggiunti altri 15 database. L'utilizzo dei database aumenta nel corso della giornata fino a quando si decide di aumentare le DTU per il pool da 200 a 400 alle ore 8:05 di sera. Gli addebiti a livello di 200 eDTU sono stati applicabili fino alle 8 di sera e sono aumentate fino a 400 per le quattro ore rimanenti.

Informazioni su prezzi e fatturazione dei pool elastici

I pool elastici vengono fatturati in base alle caratteristiche seguenti:

  • Un pool elastico viene fatturato al momento della creazione, persino quando nel pool non sono presenti database.
  • Un pool elastico viene fatturato su base oraria. Si tratta della stessa frequenza di controllo dei livelli di prestazioni dei database singoli.
  • Se viene ridimensionato per un nuovo numero di eDTU, un pool elastico non viene fatturato in base al nuovo numero di eDTU fino al completamento dell'operazione di ridimensionamento. Tale comportamento segue lo stesso modello della modifica del livello di prestazioni dei database singoli.
  • Il prezzo di un pool elastico è basato sul numero di eDTU del pool. Il prezzo di un pool elastico è indipendente dal numero e dall'uso dei database elastici in esso contenuti.
  • Il prezzo di base viene calcolato da (numero di eDTU del pool) x (prezzo unitario per eDTU).

Il prezzo unitario delle eDTU per un pool elastico è superiore al prezzo unitario delle DTU per un database singolo nello stesso livello di servizio. Per ulteriori informazioni, vedere Database SQL Prezzi.

Per comprendere i livelli di eDTU e servizio, vedere l'articolo relativo a opzioni e prestazioni del database SQL.

Come viene indicato in fattura l'uso della replica geografica attiva in un pool elastico?

A differenza dei database singoli, l'uso della replica geografica attiva con i database elastici non ha un impatto diretto sulla fatturazione. Vengono addebitate solo le DTU della quali si è effettuato il provisioning per ognuno dei pool (pool primario e secondario)

In che modo l'utilizzo della funzionalità di controllo influisce sulla fatturazione?

La funzionalità di controllo è integrata nel servizio del database SQL, senza costi aggiuntivi, ed è disponibile per i database Basic, Standard, Premium e Premium RS. Tuttavia, per archiviare i log di controllo, la funzionalità di controllo utilizza un account di archiviazione di Azure e le tariffe per le tabelle e code di archiviazione di Azure si applicano in base alle dimensioni del registro di controllo.

Come è possibile trovare i livelli di servizio e delle prestazioni corretti per i database singoli e per i pool elastici?

Sono disponibili alcuni strumenti.

Con quale frequenza è possibile modificare il livello di servizio o di prestazioni di un database singolo?

È possibile modificare il livello di servizio (tra Basic, Standard, Premium e Premium RS) o il livello di prestazioni all'interno di un livello di servizio (ad esempio, da S1 a S2) con la frequenza che più si desidera. Per i database con le versioni precedenti, è possibile modificare il livello di prestazioni o di servizio fino a quattro volte in un periodo di 24 ore.

Con quale frequenza è possibile modificare le DTU per un pool?

Numero di volte desiderato.

Quanto tempo è necessario per modificare il livello di servizio o il livello di prestazioni di un database singolo o per aggiungere o rimuovere un database da un pool elastico?

La modifica del livello di servizio di un database e lo spostamento da e verso un pool richiede che il database venga copiato nella piattaforma come operazione in background. A seconda delle dimensioni dei database, la modifica del livello di servizio può richiedere un periodo di tempo che va da pochi minuti ad alcune ore. In entrambi i casi, i database rimangono in linea e disponibili durante lo spostamento. Per ulteriori informazioni sulla modifica dei database singoli vedere Modificare il livello di servizio di un database.

Quando è meglio usare un database singolo e quando invece è meglio usare database elastici?

In generale, i pool elastici sono progettati per un modello di applicazione tipico di software-as-a-service (SaaS), in cui è presente un solo database per client o tenant. L'acquisto di database singoli e l'overprovisioning al fine di soddisfare una domanda variabile e i picchi di domanda per ogni database non sono spesso metodi convenienti. Per i pool, è possibile gestire le prestazioni collettive del pool e i database aumentano e diminuiscono automaticamente. Il motore intelligente di Azure consiglia un pool per i database se garantito da un modello di utilizzo. Per informazioni, vedere le linee guida sui pool elastici.

Che cosa significa avere fino al 200% delle risorse di archiviazione massime del database sottoposto a provisioning per l'archiviazione di backup?

L'archiviazione dei backup è l'archiviazione associata ai backup dei database automatizzati che vengono usati per il ripristino temporizzato e il ripristino geografico. Il database SQL di Microsoft Azure offre fino al 200% delle risorse di archiviazione massime del database sottoposto a provisioning per la risorsa di archiviazione di backup senza costi aggiuntivi. Ad esempio, se si usa un'istanza di database Standard con una dimensione di database con provisioning pari a 250 GB, sono disponibili 500 GB di archiviazione di backup senza costi aggiuntivi. Se il database supera lo spazio di archiviazione di backup fornito, è possibile scegliere di ridurre il periodo di conservazione contattando il supporto tecnico di Azure oppure di pagare lo spazio di archiviazione di backup aggiuntivo, che viene addebitato in base alla tariffa standard per l'archiviazione con ridondanza geografica e accesso in lettura (RA-GRS, Read-Access Geographically Redundant Storage). Per altre informazioni sui costi per il servizio RA-GRS, vedere Dettagli prezzi di archiviazione.

Se si sta passando da un livello Web/Business a nuovi livelli di servizio, cosa è necessario sapere?

I database SQL di Azure Web e Business sono stati ritirati e sostituiti dai livelli Basic, Standard, Premium, Premium RS ed Elastic.

Qual è l'intervallo di replica previsto durante la replica geografica di un database tra due aree della stessa area geografica di Azure?

È supportato un RPO pari a cinque secondi e l'intervallo di replica è minore se la replica geografica secondaria è ospitata nell'area associata di Azure consigliata e appartiene allo stesso livello di servizio.

Qual è l'intervallo di replica previsto quando la replica geografica secondaria viene creata nella stessa area del database primario?

In base ai dati empirici non c'è molta differenza tra l'intervallo di replica intra-area e l'intervallo inter-area quando viene usata l'area associata di Azure consigliata.

Se si verifica un errore di rete tra due aree, come funziona la logica di ripetizione quando è configurata la replica geografica?

Se si verifica una disconnessione, viene eseguito un tentativo ogni 10 secondi per ristabilire le connessioni.

Cosa si può fare per garantire che una modifica importante al database primario venga replicata?

La replica geografica secondaria è una replica asincrona per la quale non viene eseguita la sincronizzazione completa con la replica primaria. Ma viene fornito un metodo per forzare la sincronizzazione al fine di garantire la replica delle modifiche importanti (ad esempio, gli aggiornamenti della password). La sincronizzazione forzata si riflette sulle prestazioni poiché blocca il thread delle chiamante fino a quando non vengono replicate tutte le transazioni. Per informazioni dettagliate, vedere sp_wait_for_database_copy_sync.

Quali strumenti sono disponibili per monitorare l'intervallo di replica tra il database primario e la replica geografica secondaria?

L'intervallo di replica in tempo reale tra il database primario e la replica geografica secondaria è esposto attraverso una vista a gestione dinamica (DMV). Per informazioni dettagliate, vedere sys.dm_geo_replication_link_status.

Per spostare un database in un server diverso nella stessa sottoscrizione

Per spostare un database tra sottoscrizioni

  • Nel portale di Azurefare clic su SQL Server e quindi selezionare dall'elenco il server che ospita il database. Fare clic su Sposta, quindi selezionare le risorse da spostare e la sottoscrizione in cui spostarle.