Jak wykonać upgrade na serwerze pracującym w sesji mirroringu:

a. backup

b. usuń witness (aby nie dochodziło do automatycznego przełączenia w czasie przeprowadzanych prac)

c. zmiana trybu na High safety without automatic failover (synchronous)

d. failover wszystkich baz na jeden serwer (np. SQL-1)

e. upgrade na mirrorze (np. SQL-2)

f. po aktualizacji failover na zupgradowanego mirrora (czyli z SQL-1 na SQL-2)

g. upgrade na aktualnym mirrorze (czyli SQL-1)

h. odwrócenie kroków z (b) i (c).

Szczegóły:

http://msdn.microsoft.com/en-us/library/bb497962.aspx

Microsoft wspiera tu nawet upgrade z wersji np. 2008 do 2012 w ten sam sposób. Szczegółowy opis procedury:

http://msdn.microsoft.com/en-us/library/bb677181(v=sql.110).aspx

Chcesz utworzyć nowy dysk w postaci pliku VHD np. aby podpiąć go w maszynie wirtualnej lub wykorzystać go do jakiś testów w swoim systemie operacyjnym.

1. Uruchom zarządzanie komputerem

2. Przejdź do Magazyn >> Zarządzanie dyskami
Czytaj dalej »

Ten proxy określa, jakie konto zostanie użyte podczas wywołania procedury xp_cmdshell, jeżeli użytkownik nie jest w roli sysadmin (gdyby był w sysadmin zostanie użyte konto techniczne serwera). Credentiala definiujesz komendą:

EXEC sp_xp_cmdshell_proxy_account 'your windows account’,’password’

Jeśli brak jest tego credentiala, to otrzymasz błąd:

The xp_cmdshell proxy account information cannot be retrieved or is invalid. Verify that the '##xp_cmdshell_proxy_account##’ credential exists and contains valid information.

Komendy wykonywane poprzez xp_cmdshell wykorzystują ustawienia zdefiniowane w profilu użytkownika, więc jeżeli chcesz je zmienić (np. zmienić format daty podczas wykonywania polecenia dir), zaloguj się do systemu z wykorzystaniem tego konta użytkownika, dokonaj odpowiednich zmian (np. w panelu sterowania w ustawieniach regionalnych). Po ponownym wykonaniu polecenia xp_cmdshell komendy takie jak dir, będą pracowały zgodnie ze zdefiniowanymi ustawieniami lokalnymi.

Znalazłem serwer witness. Niestety brak informacji, jakie inne serwery wykorzystują ten witness.

Co można zrobić? Sprawdź czy nie ma czegoś  w:

select * from sys.endpoints

select * from sys.database_mirroring_endpoints

select * from sys.database_mirroring

select * from sys.dm_db_mirroring_connections

select * from sys.database_mirroring_witnesses

Ostatni widok powinien zawierać rekordy, po jednym na mirrorowaną bazę z informacjami o principalu i mirrorze.

Niestety mi się tu nic nie udało wypatrzeć. Ale skoro ktoś łączy się do witnessa, to musi do tego mieć uprawnienia. Poniższe zapytanie wyświetli te uprawnienia:

SELECT ep.endpoint_id, p.class_desc, p.permission_name, ep.name, sp.name
FROM sys.server_permissions p
INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
INNER JOIN sys.server_principals sp ON p.grantee_principal_id = sp.principal_id

i w moim przypadku pozwoliło mi to skojarzyć, o które serwery chodzi!

select*fromsys.endpoints

select*fromsys.database_mirroring_endpoints

select*fromsys.database_mirroring

select*fromsys.dm_db_mirroring_connections

select*fromsys.database_mirroring_witnesses

Dysk z logiem pełny. Logi pełne. Pliki loga posadowione już na dwóch dyskach. Trzeba zwolnić trochę miejsca

Zaczynasz od

Druga kolumna  zwraca informację o tym, co powoduje przepełnienie loga. W moim przypadku było dość standardowo LOG_BACKUP. Oznacza to, że w pierwszej kolejności należy zwolnić miejsce przez wykonanie bakupu loga. Jest to konieczne, gdy baza pracuje w recovery modelu full, a na systemach produkcyjnych tak jest najczęściej.

Po backupie loga, widać już, że w logu jest sporo wolnego miejsca:

A tu niespodzianke. Log się nie skurczył a jeszcze pojawia się komunikat:

Porady na forach zazwyczaj zalecają przełączenie bazy w recovery model simple, co wyrzuci z loga niebackupowane transakcje i zupełnie przebuduje jego strukturę, a potem powrót  do modelu full. Ale to raczej nie tędy droga. System jest produkcyjny i nie należy przełączać modelu na simple, a na dodatek w moim przypadku… baza pracowała w mirroringu.

Wczytaj się w komunikat. Shrinkować nie można, bo aktywna część loga jest na końcu pliku… Więc może przesuniemy ten „logical log file”. To proste. Wygeneruj po prostu kilka pustych „dummy” transakcji:

I gotowe! Teraz shrink zadziałał od razu!

Warto, aby instalacja aktualizacji SQL  odbywała się bez udziału administratora, klikającego myszką „Next”, „Next”.

Pakiety KB można uruchamiać z linii komend przekazując do nich odpowiednie parametry. Sęk w tym, że te parametry zmieniają się z wersji na wersję.

I tak aktualizacja wszystkich instancji SQL w SQL 2008 załatwiasz komendą:

KB0123456789.exe  /qs /Action=Patch /AllInstances

Ta sama czynność na SQL 2008 R2, 2012 i 2014 to polecenie:

KB0123456789.exe /qs /IAcceptSQLServerLicenseTerms /Action=Patch /AllInstances

Szczegóły:

http://technet.microsoft.com/en-us/library/dd638066(v=sql.120).aspx

Aktualizacje SQL Server mogą odbywać się w dwóch trybach:

• Quick Fix Engeneering (QFE)
• General Distribution Release (GDR)

Czym to się różni? Są to ścieżki kolejnych buildów SQL, podążając którymi można podnosić wersję serwera. Jeśli wybierasz ścieżkę GDR, tzn. że będziesz instalował wyłącznie Service Packs. Natomiast nie przejmujesz się Hot Fixami lub Cummulative Updates. Pamiętaj, że Hot Fix oraz paczka hotfixów zwana Cummulative Update jest o wiele słabiej testowana. Wiele organizacji nie chce (o ile nie musi) instalować CU i świadomie wybiera ścieżkę GDR. Jeżeli w pewnej chwili pojawi się potrzeba zainstalowania CU, po prostu zrób to. Wskoczysz w ten sposób na ścieżkę QFE. Będzie można z niej zejść, jeżeli pojawi się service pack. Instalacja Service pack przenosi cię ponownie do GDR.

A co to jest QFE? W tym przypadku aktualizujesz SQL instalując Cummulative Updates. Pamiętaj, że każdy kolejny CU posiada wszystkie zmiany wprowadzone w poprzednich CU. W pewnym momencie MS wyda service pack i wtedy należy zainstalować service pack i wskoczyć znowu do GDR.

SQL posiada numery build. Numer do 3149 oznacza, że masz SQL GDR. Wartość powyżej 3150 oznacza, że jesteś w QFE. Jeżeli pojawia się Security Update, to znajdziesz oddzielne pakiety KB do zaktualizowania GDR i QFE. Instalacja pakietu QFE na GDR się uda, przenosząc cię do ścieżki QFE. Próba instalacji KB z GDR na systemie podążającym ścieżką QFE zakończy się komunikatem, mówiącym, że posiadasz nowszą wersję… Dlaczego?

Załóżmy, że KB do instalacji podnosi numer builda w GDR do 1300, a w QFE do 4000. Jednak każdy system w ścieżce QFE ma numer builda większy niż 3150. Instalując więc na nim KB podnoszący build do 1300 obniżylibyśmy numer! Stąd komunikat…

http://support2.microsoft.com/kb/935897

http://blogs.msdn.com/b/gauravagg/archive/2007/04/27/jargons-gdr-and-qfe-release.aspx