Wybór instancji (default/named instance)

Wybór między instancją domyślną a nazwaną wpływa na sposób, w jaki klienci łączą się z serwerem.

Wybór instancji: znaczenie ustawienia default i named instance

Wybór instancji, czyli rozstrzygnięcie, czy używana będzie instancja domyślna, czy instancja nazwana, jest jednym z podstawowych elementów konfiguracji połączenia z systemem bazodanowym. Instancja oznacza uruchomione środowisko usługi, które przyjmuje żądania klientów, zarządza bazami danych, obsługuje uwierzytelnianie i udostępnia określone zasoby. W praktyce nie chodzi wyłącznie o nazwę widoczną w narzędziu administracyjnym. Wybrany wariant wpływa także na sposób zapisu adresu serwera, działanie mechanizmów wykrywania usługi, konfigurację zapory sieciowej oraz organizację kilku niezależnych środowisk działających na jednym komputerze.

Instancja domyślna jest zwykle identyfikowana przez samą nazwę hosta albo adres urządzenia. Połączenie może więc przyjmować postać zbliżoną do komputer-firmowy lub 192.168.1.20, zależnie od używanego systemu i sterownika. Instancja nazwana wymaga dodatkowego oznaczenia, na przykład w formie komputer-firmowy\SPRZEDAZ. W tym drugim przypadku klient musi wiedzieć, jaka nazwa została nadana usłudze, a środowisko sieciowe musi umożliwić prawidłowe odnalezienie właściwego procesu.

Nie należy utożsamiać instancji z pojedynczą bazą danych. Jedna instancja może zarządzać wieloma bazami, a na tym samym komputerze może działać kilka instancji odseparowanych konfiguracją, katalogami plików, portami i uprawnieniami. Dzięki temu możliwe jest rozdzielenie środowisk przeznaczonych do różnych zastosowań, jednak każdy dodatkowy wariant zwiększa liczbę ustawień wymagających kontroli.

Wybór instancji domyślnej a named instance w połączeniach

W przypadku instancji domyślnej klient kieruje żądanie do standardowo rozpoznawanej usługi na wskazanym hoście. Jeżeli konfiguracja jest typowa, adres pozostaje prosty, a aplikacja nie musi przechowywać dodatkowego identyfikatora instancji. Taki model bywa wygodny w małych instalacjach, podczas migracji programu na nowy komputer oraz wtedy, gdy działa tylko jedno środowisko bazodanowe. Prostota adresu nie oznacza jednak, że konfiguracja może zostać pominięta. Nadal trzeba sprawdzić, czy usługa działa, czy nasłuchuje na oczekiwanym porcie i czy reguły sieciowe zezwalają na ruch.

Instancja nazwana jest rozpoznawana przez nazwę przypisaną podczas instalacji lub późniejszej konfiguracji. Zaletą takiego rozwiązania jest czytelne rozdzielenie kilku środowisk. Można na przykład utrzymywać osobne instancje dla programu magazynowego, aplikacji księgowej i testów, bez mieszania ich ustawień w ramach jednej usługi. Wadą jest większa zależność od mechanizmów lokalizujących instancję. Gdy klient otrzymuje wyłącznie nazwę hosta, bez nazwy instancji, połączenie może trafić do niewłaściwego miejsca albo zakończyć się komunikatem o niedostępności.

Ważną rolę odgrywa usługa pomocnicza odpowiedzialna za wskazanie portu przypisanego do instancji nazwanej. Jeżeli aplikacja korzysta z nazwy zamiast bezpośredniego numeru portu, klient może najpierw skontaktować się z mechanizmem rozpoznawania, a dopiero potem nawiązać właściwe połączenie. Zatrzymanie takiej usługi, blokada jej komunikacji lub niejednoznaczna konfiguracja zapory może dać objawy przypominające awarię bazy, mimo że sama instancja nadal działa.

Alternatywą jest połączenie bezpośrednio z portem. Wtedy adres może mieć postać serwer,port, a nazwa instancji nie jest potrzebna podczas zestawiania sesji. Rozwiązanie to ogranicza zależność od automatycznego wykrywania, ale wymaga stałej wiedzy o używanym porcie. Przy zmianie konfiguracji trzeba zaktualizować ustawienia aplikacji, dokumentację oraz ewentualne reguły zapory. Z tego powodu wybór między instancją domyślną i nazwaną powinien uwzględniać nie tylko wygodę instalacji, lecz także sposób późniejszego utrzymania.

Wybór instancji a typowe objawy błędnej konfiguracji

Najczęstszym sygnałem problemu jest brak możliwości zalogowania się do aplikacji, która wcześniej działała poprawnie. Komunikat może wskazywać na niedostępny host, odrzucone połączenie, przekroczenie czasu oczekiwania albo nieprawidłową nazwę usługi. Każdy z tych objawów może wynikać z innej przyczyny, dlatego samo ponowne instalowanie programu zwykle nie rozwiązuje problemu. Najpierw powinno zostać ustalone, czy używana jest instancja domyślna, czy nazwana, oraz jaki adres zapisano w konfiguracji klienta.

Do częstych pomyłek należy wpisanie samej nazwy komputera tam, gdzie wymagana jest nazwa instancji nazwan ej, albo dopisanie nazwy instancji do środowiska skonfigurowanego jako domyślne. Problem może pojawić się również po zmianie nazwy komputera, odtworzeniu systemu z kopii, aktualizacji sterownika lub przeniesieniu bazy na inne urządzenie. Niekiedy aplikacja korzysta z ustawień zapisanych w kilku miejscach: w pliku konfiguracyjnym, rejestrze systemowym, profilu użytkownika albo parametrach skrótu. Rozbieżność między tymi wpisami utrudnia diagnozę.

Objawem bywa także działanie programu tylko na komputerze, na którym znajduje się usługa. Taka sytuacja sugeruje, że lokalne połączenie jest możliwe, lecz komunikacja sieciowa nie została poprawnie udostępniona. Należy wtedy zweryfikować nasłuchiwanie na właściwym interfejsie, reguły zapory, dostępność portu oraz poprawność nazwy używanej przez inne stanowiska. Jeżeli problem występuje tylko u jednego użytkownika, warto sprawdzić lokalny profil, zapisane poświadczenia, sterownik oraz ustawienia DNS. Jeżeli dotyczy wszystkich klientów, większe znaczenie ma konfiguracja usługi lub sieci.

Nie powinno się zmieniać przypadkowo nazwy instancji w działającym środowisku. Taka modyfikacja może unieważnić ustawienia aplikacji, zadania automatyczne, skrypty kopii zapasowych oraz wpisy używane przez inne komputery. Bezpieczniejsze jest ustalenie obecnego wariantu, wykonanie kopii konfiguracji i dopiero potem planowanie zmiany. W wielu przypadkach wystarczy poprawienie adresu połączenia albo uruchomienie właściwej usługi.

Wybór instancji w codziennej konfiguracji stanowiska

Przed wpisaniem danych do programu warto zebrać kilka informacji: nazwę komputera, nazwę instancji, sposób uwierzytelniania, numer portu oraz informację, czy połączenie ma działać tylko lokalnie, czy także przez sieć. Dane te powinny pochodzić z dokumentacji instalacji albo z konfiguracji usługi, a nie z przypadkowych podpowiedzi znalezionych w systemie. Szczególnej uwagi wymaga sytuacja, w której na jednym komputerze istnieje więcej niż jedno środowisko bazodanowe. Sama nazwa hosta nie wskazuje wtedy jednoznacznie, do którego z nich ma zostać skierowane połączenie.

Przydatne jest zapisanie pełnego, jednoznacznego adresu używanego przez aplikację. W przypadku instancji nazwanej powinno się zachować zarówno nazwę hosta, jak i nazwę instancji. Gdy stosowany jest port, należy odnotować jego wartość oraz sprawdzić, czy pozostaje stała po ponownym uruchomieniu usługi. Dokumentacja powinna obejmować również nazwę bazy, konto wykorzystywane przez aplikację i sposób nadawania uprawnień, bez przechowywania haseł w otwartym tekście.

Po zmianie ustawień należy wykonać test z tego samego komputera i konta, z którego korzysta aplikacja. Test administracyjny wykonany z uprzywilejowanego profilu może dać wynik pozytywny, mimo że zwykły użytkownik nadal nie ma dostępu. Warto sprawdzić kilka scenariuszy: połączenie lokalne, połączenie z innego stanowiska, ponowne uruchomienie systemu oraz działanie aplikacji po wylogowaniu. Takie podejście pomaga odróżnić problem z wyborem instancji od problemu z uprawnieniami, zaporą lub usługą systemową.

• Najpierw ustala się, czy wymagane jest połączenie z instancją domyślną, czy z instancją nazwaną.
• Następnie porównuje się adres zapisany w aplikacji z rzeczywistą nazwą hosta i usługą działającą w systemie.
• Potem sprawdza się dostępność portu, reguły zapory i możliwość odnalezienia usługi z danego stanowiska.
• Na końcu wykonuje się test aplikacyjny oraz zapisuje działającą konfigurację do dalszego użytku.

Wybór instancji i moment zgłoszenia do serwisu

Zgłoszenie do serwisu jest uzasadnione, gdy nie można ustalić, która instancja obsługuje aplikację, gdy po awarii systemu zniknęła usługa albo gdy po zmianie komputera program nie nawiązuje połączenia. Pomoc bywa potrzebna także wtedy, gdy kilka aplikacji korzysta z różnych środowisk i nie wiadomo, czy problem dotyczy adresu, portu, uprawnień, sterownika czy samej usługi. Przed przekazaniem sprzętu dobrze przygotować opis objawów, nazwę programu, moment wystąpienia problemu oraz informację, czy kłopot dotyczy jednego stanowiska, czy większej liczby komputerów.

W Warszawie takie przypadki można skonsultować z Warszawskim Pogotowiem Komputerowym 24/7 pod numerem +48 22 100 48 29. W ramach rozpoznania analizuje się konfigurację komputera, sposób uruchamiania usługi i parametry połączenia, a następnie wskazuje przyczynę rozbieżności między instancją domyślną i nazwaną. Szczególnie ważne jest zachowanie kopii konfiguracji oraz danych użytkownika przed zmianami, ponieważ nieprawidłowe usunięcie usługi lub bazy może utrudnić późniejsze odtworzenie działania programu.

Nie zawsze konieczna jest zmiana instancji. Czasem właściwym rozwiązaniem jest przywrócenie usługi, korekta adresu w aplikacji, udostępnienie portu albo uporządkowanie wpisów po migracji. Jeżeli natomiast kilka środowisk zostało zainstalowanych bez spójnego planu, warto uporządkować ich nazwy, dokumentację i zależności. Dzięki temu późniejszy wybór instancji będzie jednoznaczny, a rozpoznawanie problemów z połączeniem zajmie mniej czasu.