Puteți dezactiva temporar modificările bazei de date în Microsoft SQL Server?

Într-o actualizare viitoare, va trebui să convertesc mai multe tabele de pe serverul nostru de la UTF-16 la UTF-8. Mă aștept că acest lucru va dura mai multe ore.

Există o modalitate bună de a dezactiva INSERȚII și ACTUALIZĂRI, dar totuși permiteți SELECTAREA în baza de date?

Sau trebuie să blochez modificările la nivel de afaceri / să opresc baza de date în timp ce se realizează actualizarea?

S-ar putea să aveți un Problema XY. Există modalități de a face ceea ce încercați, care nu necesită ca tabelele pe care sunt operate să fie indisponibile pentru mutație pe durata operației. Iată cum l-aș schimba (nivel înalt):

1. Adăugați o nouă coloană cu definiția dorită (tip de date, colare etc.).
2. Utilizați declanșatoarele „după inserare” pentru a vă asigura că mutațiile de date care provin din aplicația dvs. modifică și noua coloană.
3. Completați datele existente în tabel.
4. Aruncă vechea coloană, redenumește noua coloană pentru a avea numele vechii coloane.

Without further knowledge of your database schema, permissions, etc. and some idea of your strategy with respect to your application it is exceedingly difficult to be prescriptive. At a minimum, does the application even allow you to operate in a read-only mode with the table updates blocked?

At a very basic level, "Yes" you can do that... DENY INSERT, UPDATE, DELETE ON <table> TO <user> however it is impossible to say how your application will react. In my experience most applications will splatter errors everywhere and cry bloody murder if you do this, possibly even corrupting the data (unchecked errors, poor use of transactions, etc.). Rarely (possibly never) have I seen an application that gracefully switched to a read-only mode when database access was not as designed/expected.

So TEST! Test, test, test, in a controlled non-production environment until you have a documented process supporting your change.

If your requirements do not allow for an extended outage (or no outage at all) there are more sophisticated ways to handle this. One thought would be to add an after insert / after update trigger to automatically convert new /updated records in a new field while you run maintenance on smaller batches. Once all the data is converted, switch the application to the new field and drop the old one.

Lăsând deoparte UTF-8 și UTF-16, cred că întrebarea mai mare pe care o puneți este cum să implementați modificări la un sistem de producție cu un timp de nefuncționare minim. Sunt sigur că există câteva moduri diferite, dar așa l-aș aborda.

1. Creați o copie a bazei de date.
2. Rulați actualizările schemei pe copie.
3. Utilizați un produs precum Redgate SQL Compare sau scrieți propriile scripturi pentru a vă sincroniza datele. Aduceți-le cât mai aproape
4. Închideți aplicația, resincronizare finală.
5. Schimbați conexiunea la baza de date la baza de date nouă (sau redenumiți bazele de date).
6. Reporniți aplicația.

Știu că acest lucru sună simplist și s-ar putea să nu fie posibil din mai multe motive, dar ar merita investigat.

Aș vrea să fac asta din câteva motive. Întreruperi minime și impact asupra utilizatorilor. Opțiune de revenire în siguranță. O oportunitate de a testa impactul modificărilor schemei/datelor.

Apreciez că acest lucru devine mai complicat dacă există alte aplicații sau conexiuni de integrare la baza ta de date, dar nici să anulezi un upgrade eșuat nu este prea distractiv.