Da sviluppatore a impresa andrà bene, assicurati solo che se stai usando le licenze per processore hai delle licenze sul server di destinazione per coprire tutte le CPU. E non basta nasconderli da SQL, se sono fisicamente connessi alla macchina, sei responsabile per loro.
Inoltre, quando si passa da una build inferiore a una build superiore, la versione del database aumenta. Esistono alcuni scenari in cui ciò può essere problematico, ad esempio se si utilizza un supporto di 15.000 partizioni su una build specifica del 2008, non funzionerà quando si esegue l'aggiornamento a una build specifica di 2008 R2. Potresti anche fare affidamento su ottimizzazioni (e disporre di soluzioni alternative) che in realtà sono bug in una build precedente ma che sono stati corretti nella nuova build e ciò potrebbe portare a prestazioni peggiori. È inoltre fondamentale rivedere eventuali flag di traccia in uso all'origine e determinare se devono essere abilitati anche a destinazione. Non importa lavori, accessi, ecc.
Ovviamente non puoi tornare indietro. Non ho mai provato un downgrade minore come 10.0.5512 -> 10.0.5500 ma non è assolutamente possibile passare al service pack o alla versione. Quindi, se hai un database 2012 sulla tua istanza Developer Edition e vuoi metterlo sulla tua istanza 2008 in produzione, avrai il tuo lavoro tagliato per te (vedi qui e qui ), specialmente se hai usato le funzionalità 2012 .
Ma per coprire altri casi che potrebbero far atterrare le persone a questa domanda (ad esempio qualcuno vuole passare da Developer -> Standard o Enterprise -> Express o cosa hai) ...
Esistono altre versioni -> aggiornamenti di edizione che non andranno così bene, ad es. Da Developer -> Express se hai utilizzato funzionalità non supportate in Express (e lo stesso vale per qualsiasi edizione diversa da Enterprise). Alcuni esempi di funzionalità che non potrai utilizzare nelle edizioni di basso livello (nel qual caso il ripristino morirà nel momento in cui tenta di portare il database online):
- partizionamento
- Modifica acquisizione dati
- Compressione dati
- Crittografia dei dati trasparente
Non so se c'è un modo per dirlo direttamente dal file .BAK (sono sicuro che c'è un po 'di magia che può essere estratta dalle intestazioni di pagina da qualche parte, o se hai un fine settimana da masterizzare con un editor esadecimale) , ma mentre il database è ancora intatto sull'istanza di origine, puoi sempre fare quanto segue per vedere se stai utilizzando funzionalità disponibili a causa dello SKU in cui ti trovi:
SELECT feature_name FROM sys.dm_db_persisted_sku_features;
Non sono sicuro che SQL Server Audit debba essere in quell'elenco: l'esclusività dell'edizione di quella funzionalità è cambiata, quindi probabilmente dipende da cosa ci stai facendo. Ci sono altre cose che potresti usare ma che non verranno visualizzate nel DMV (alcune perché sono nel tuo codice, che il DMV non analizza, e altre perché il tuo database si basa su cose esterne come SQL Server Agent , Service Broker, ecc.):
- mirroring
- alcune forme di replica
- log shipping
- snapshot del database
- indicizzazione online
- viste partizionate distribuite aggiornabili
- compressione di backup
- gestione basata sulle politiche
- guide di piano
- posta nel database
- piani di manutenzione
- ricerca full-text
Ci sono anche casi in cui non sarai in grado di passare da Developer a Express a causa delle limitazioni sulla dimensione dei file (i database Express sono limitati a 10 GB nella dimensione totale dei file di dati).
Ovviamente potrebbero esserci altri gotcha di cui non verrai avvertito: non impediranno la migrazione, ma potrebbero portare a prestazioni molto diverse sull'obiettivo. Esempi:
- Limitazioni della memoria / CPU diverse sulla versione di destinazione (o persino sul sistema operativo sottostante sulla destinazione). Un po 'di gente che è passata dal 2008 R2 Enterprise al 2012 Enterprise (CAL), dove il servizio è artificialmente limitato ai primi 20 core). Ciò può portare a differenze di prestazioni semplici (ad esempio memoria insufficiente per soddisfare una query o prestazioni di query parallele molto più lente); quelli più sottili includono le scelte del piano fatte a causa del diverso hardware sottostante.
- La dipendenza da funzionalità come la corrispondenza della vista indicizzata sulla sorgente non verrà automaticamente rispettata sulla destinazione senza cambiare il codice sorgente da usare
NOEXPAND. E potresti anche non essere consapevole del fatto che questa capacità è il motivo per cui le tue domande rallentano improvvisamente.
- Lo stesso vale per le operazioni su indici paralleli e probabilmente una serie di altre ottimizzazioni che non vengono in mente in questo momento (per fortuna lavoro quasi esclusivamente nello spazio Enterprise, quindi nella maggior parte dei casi non devo preoccuparmi dei limiti delle edizioni inferiori ).
AGGIORNAMENTO basato su questo duplicato :
Potrebbero verificarsi casi in cui si tenta di ripristinare un database da una determinata edizione a una versione inferiore (anche sulla stessa versione) e si ottengono errori che non sono utili :
RIPRISTINO non riuscito per il server 'server \ istanza'.
RESTORE non è stato in grado di avviare il database 'nome database'.
Questo non è molto intuitivo. Tuttavia, se si approfondisce il registro degli eventi di SQL Server, verranno visualizzati errori più utili (solo un esempio):
Il "nome database" non può essere avviato poiché alcune delle funzionalità del database non sono disponibili nell'edizione corrente di SQL Server.
Il database "nome database" non può essere avviato in questa edizione di SQL Server perché contiene una funzione di partizione "_dta_pf__9987". Solo l'edizione Enterprise di SQL Server supporta le funzioni di partizione.
Ora, non è del tutto vero: puoi anche ripristinare l'edizione di valutazione o l'edizione per sviluppatori, ma non è questo il punto. Per ripristinare questo database, hai sostanzialmente due opzioni:
- Ripristina su un'edizione appropriata di SQL Server, il che significa individuare o installare una nuova istanza.
- Ripristina il backup sul server di origine come nuovo database con un nome diverso, rimuovi tutte le funzionalità Enterprise, quindi esegui nuovamente il backup del database e ripristinalo sulla versione minore. (In questo caso specifico, ho lasciato il nome della funzione di partizione nel messaggio di errore, perché sembra comunque una cosa scartabile - è stata creata dal Database Engine Tuning Advisor e potrebbe essere stata fatta da qualcuno che non ha del tutto sapere cosa stavano facendo. Questo non è sempre il caso.)
Una variazione su (2) sarebbe semplicemente rimuovere il partizionamento e altre funzionalità sul database di origine e fare un altro backup. Ma se non è rotto ...