Shared Memory (lokalne tylko)

Shared Memory to protokół komunikacji dostępny wyłącznie, gdy klient działa na tym samym komputerze co serwer.

Shared Memory jako lokalny protokół połączenia

Shared Memory to lokalny protokół komunikacyjny używany przez Microsoft SQL Server wtedy, gdy aplikacja kliencka i usługa serwera działają na tym samym komputerze. Nie służy do przesyłania żądań przez sieć lokalną ani przez Internet. Oba procesy korzystają z mechanizmów komunikacji dostępnych w systemie operacyjnym, dzięki czemu dane nie muszą opuszczać komputera, na którym działa instancja SQL Server.

W praktyce oznacza to, że klient może nawiązać połączenie z lokalną instancją bez używania adresu IP, portu TCP ani protokołu UDP. Aplikacja nadal korzysta z typowego łańcucha połączenia, nazwy instancji i sterownika zgodnego z SQL Server, ale warstwa transportowa jest wybierana lokalnie. Shared Memory nie jest formatem bazy danych, sposobem przechowywania tabel ani obszarem pamięci RAM przeznaczonym na dane użytkownika.

Warunek działania: klient i serwer na jednej maszynie

Najważniejszym ograniczeniem Shared Memory jest lokalny zasięg. Protokół działa wyłącznie wtedy, gdy program kliencki oraz usługa SQL Server znajdują się w tej samej instalacji systemu operacyjnego i korzystają z zasobów tego samego komputera. Próba połączenia z innego laptopa, komputera PC albo serwera przez nazwę hosta lub adres IP wymaga użycia protokołu sieciowego, na przykład TCP/IP, a nie Shared Memory.

To ograniczenie ma znaczenie podczas przenoszenia aplikacji. Program może działać poprawnie na komputerze, na którym zainstalowano SQL Server, ponieważ sterownik wybiera lokalny transport. Po uruchomieniu tego samego programu na innym urządzeniu połączenie może przestać działać, mimo że nazwa instancji i dane logowania nie zostały zmienione. W takim przypadku trzeba sprawdzić, czy konfiguracja klienta nie wymusza Shared Memory oraz czy dla połączeń zdalnych skonfigurowano właściwy protokół sieciowy.

Wybór protokołu i typowe objawy błędnej konfiguracji

SQL Server pozwala określić kolejność protokołów klienta oraz włączać lub wyłączać poszczególne mechanizmy komunikacji. Ustawienia te są dostępne między innymi w SQL Server Configuration Manager, w konfiguracji protokołów klienta oraz w konfiguracji konkretnej instancji serwera. Jeżeli Shared Memory znajduje się wysoko na liście protokołów, lokalny klient może próbować użyć go przed TCP/IP. Przy połączeniu z tym samym komputerem takie zachowanie jest prawidłowe.

Problemy pojawiają się wtedy, gdy konfiguracja aplikacji zakłada dostęp zdalny, lecz pozostawiono wyłącznie lokalny transport. Objawem może być możliwość uruchomienia programu tylko na komputerze z bazą, brak połączenia po przeniesieniu aplikacji na inne stanowisko albo komunikat wskazujący na niedostępność instancji. W diagnostyce należy rozdzielić trzy kwestie: czy działa usługa SQL Server, czy klient wskazuje właściwą instancję oraz czy wybrany protokół odpowiada rzeczywistej lokalizacji klienta względem serwera.

Sprawdzanie lokalnego połączenia z instancją SQL Server

Diagnostyka powinna rozpocząć się od ustalenia, gdzie faktycznie działa proces klienta i gdzie działa usługa SQL Server. Jeżeli oba elementy są na tej samej maszynie, Shared Memory może być poprawnym transportem. Jeżeli aplikacja korzysta z komputera oddalonego od serwera, trzeba analizować konfigurację TCP/IP, nazwę hosta, port nasłuchu, zaporę sieciową oraz rozwiązywanie nazwy instancji. Sam fakt, że serwer jest widoczny w sieci, nie oznacza jeszcze, że Shared Memory będzie dostępne.

Podczas przeglądu ustawień warto sprawdzić, czy protokół Shared Memory jest włączony dla klienta i instancji, czy usługa SQL Server działa oraz czy aplikacja nie używa innego sterownika z odmienną kolejnością protokołów. Przydatne jest także porównanie połączenia lokalnego z połączeniem przez jawnie wskazany protokół. Taki test pomaga ustalić, czy problem dotyczy samej instancji, danych logowania, nazwy serwera, czy wyłącznie warstwy transportowej. W przypadku błędów systemowych należy dodatkowo przeanalizować dzienniki SQL Server i Podgląd zdarzeń systemu Windows.