Udostępnij za pośrednictwem


Omówienie integracji środowiska CLR

Dotyczy:programu SQL ServerAzure SQL Managed Instance

Środowisko uruchomieniowe języka wspólnego (CLR) jest sercem programu .NET Framework i zapewnia środowisko wykonawcze dla całego kodu programu .NET Framework. Kod uruchamiany w ramach środowiska CLR jest określany jako zarządzany kod. ClR udostępnia różne funkcje i usługi wymagane do wykonywania programu, w tym kompilację just in time (JIT), przydzielanie pamięci i zarządzanie nią, wymuszanie bezpieczeństwa typu, obsługa wyjątków, zarządzanie wątkami i zabezpieczenia. Aby uzyskać więcej informacji, zobacz .NET Framework development guide.

Nuta

Aby uzyskać więcej informacji na temat korzystania z nowej platformy .NET z rozszerzeniami języka programu SQL Server, zobacz Jak wywołać środowisko uruchomieniowe platformy .NET w rozszerzeniach języka programu SQL Server.

Za pomocą środowiska CLR hostowanego w programie SQL Server (nazywanej integracją CLR) można tworzyć procedury składowane, wyzwalacze, funkcje zdefiniowane przez użytkownika, typy zdefiniowane przez użytkownika i agregacje zdefiniowane przez użytkownika w kodzie zarządzanym. Ponieważ kod zarządzany kompiluje się do kodu natywnego przed wykonaniem, można osiągnąć znaczny wzrost wydajności w niektórych scenariuszach.

Zabezpieczenia dostępu kodu

W programie SQL Server 2016 (13.x) i starszych wersjach zabezpieczenia dostępu kodu (CAS) uniemożliwiły wykonywanie określonych operacji przez zestawy.

ClR używa zabezpieczeń dostępu kodu (CAS) w programie .NET Framework, który nie jest już obsługiwany jako granica zabezpieczeń. Zestaw CLR utworzony za pomocą PERMISSION_SET = SAFE może mieć dostęp do zasobów systemu zewnętrznego, wywołać kod niezarządzany i uzyskać uprawnienia administratora systemu. W programie SQL Server 2017 (14.x) i nowszych wersjach opcja sp_configure, ścisłe zabezpieczenia, zwiększa bezpieczeństwo zestawów CLR. clr strict security jest domyślnie włączona i traktuje zestawy SAFE i EXTERNAL_ACCESS tak, jakby zostały oznaczone UNSAFE. Opcja clr strict security może być wyłączona w celu zapewnienia zgodności z poprzednimi wersjami, ale nie jest zalecana.

Zalecamy podpisanie wszystkich zestawów przy użyciu certyfikatu lub klucza asymetrycznego z odpowiednim identyfikatorem logowania, któremu udzielono UNSAFE ASSEMBLY uprawnienia w bazie danych master. Administratorzy programu SQL Server mogą również dodawać zestawy do listy zestawów, którym aparat bazy danych powinien ufać. Aby uzyskać więcej informacji, zobacz sys.sp_add_trusted_assembly.

Zalety integracji środowiska CLR

Transact-SQL jest przeznaczony do bezpośredniego dostępu do danych i manipulowania nimi w bazie danych. Chociaż Transact-SQL wyróżnia się w dostępie do danych i zarządzaniu nimi, nie jest to pełny język programowania. Na przykład Transact-SQL nie obsługuje tablic, kolekcji, pętli dla każdego, przesunięcia bitowego lub klas. Chociaż niektóre z tych konstrukcji można symulować w języku Transact-SQL, kod zarządzany ma zintegrowaną obsługę tych konstrukcji. W zależności od scenariusza te funkcje mogą stanowić przekonujący powód do zaimplementowania niektórych funkcji bazy danych w kodzie zarządzanym.

Język Visual Basic i C# oferują funkcje obiektowe, takie jak hermetyzacja, dziedziczenie i polimorfizm. Powiązany kod można teraz łatwo organizować w klasy i przestrzenie nazw. Podczas pracy z dużą ilością kodu serwera te funkcje umożliwiają łatwiejsze organizowanie i konserwowanie kodu.

Kod zarządzany jest lepiej dostosowany niż Transact-SQL do obliczeń i skomplikowanej logiki wykonywania oraz oferuje rozbudowaną obsługę wielu złożonych zadań, w tym obsługę ciągów i wyrażenia regularne. Dzięki funkcjom znajdującym się w programie .NET Framework masz dostęp do tysięcy wstępnie utworzonych klas i procedur. Do tych klas można łatwo uzyskać dostęp z dowolnej procedury składowanej, wyzwalacza lub funkcji zdefiniowanej przez użytkownika. Biblioteka klas bazowych (BCL) zawiera klasy, które zapewniają funkcjonalność manipulowania ciągami, zaawansowanych operacji matematycznych, dostępu do plików, kryptografii i nie tylko.

Nuta

Chociaż wiele z tych klas jest dostępnych do użycia z poziomu kodu CLR w programie SQL Server, te, które nie są odpowiednie do użycia po stronie serwera (na przykład klasy okien), nie są dostępne. Aby uzyskać więcej informacji, zobacz Obsługiwane biblioteki programu .NET Framework.

Jedną z zalet kodu zarządzanego jest bezpieczeństwo typu lub zapewnienie, że kod uzyskuje dostęp do typów tylko w dobrze zdefiniowanych, dopuszczalnych sposobach. Przed wykonaniem kodu zarządzanego clR sprawdza, czy kod jest bezpieczny. Na przykład kod jest sprawdzany, aby upewnić się, że nie jest odczytywana żadna pamięć, która nie została wcześniej zapisana. ClR może również pomóc w zapewnieniu, że kod nie manipuluje niezarządzaną pamięcią.

Integracja środowiska CLR oferuje potencjał poprawy wydajności. Aby uzyskać informacje, zobacz Wydajność architektury integracji środowiska CLR.

Wybieranie między Transact-SQL i kodem zarządzanym

Podczas pisania procedur składowanych, wyzwalaczy i funkcji zdefiniowanych przez użytkownika należy zdecydować, czy używać tradycyjnego języka Transact-SQL, czy języka .NET Framework, takiego jak Visual Basic lub C#. Użyj Transact-SQL, gdy kod wykonuje głównie dostęp do danych z niewielką lub bez logiki proceduralnej. Użyj kodu zarządzanego dla funkcji i procedur intensywnie korzystających z procesora CPU, które zawierają złożoną logikę lub gdy chcesz korzystać z listy BCL programu .NET Framework.

Wybieranie między wykonaniem na serwerze a wykonaniem w kliencie

Innym czynnikiem decyzji o tym, czy należy używać Transact-SQL czy kodu zarządzanego, jest to, gdzie chcesz, aby kod znajdował się, komputer serwera lub komputer kliencki. Na serwerze można uruchamiać zarówno Transact-SQL, jak i kod zarządzany. Dzięki temu kod i dane są blisko siebie i można korzystać z mocy obliczeniowej serwera. Z drugiej strony warto unikać umieszczania zadań intensywnie korzystających z procesora na serwerze bazy danych. Większość komputerów klienckich jest obecnie wydajna i warto wykorzystać tę moc obliczeniową, umieszczając jak na kliencie jak najwięcej kodu. Kod zarządzany może być uruchamiany na komputerze klienckim, a Transact-SQL nie.

Wybieranie między rozszerzonymi procedurami składowanymi i kodem zarządzanym

Rozszerzone procedury składowane można utworzyć w celu wykonywania funkcji, które nie są możliwe w przypadku Transact-SQL procedur składowanych. Rozszerzone procedury składowane mogą jednak naruszyć integralność procesu programu SQL Server, podczas gdy kod zarządzany zweryfikowany jako bezpieczny dla typu nie może. Ponadto zarządzanie pamięcią, planowanie wątków i światłowodów oraz usługi synchronizacji są bardziej zintegrowane między zarządzanym kodem CLR i programem SQL Server. Dzięki integracji środowiska CLR masz bezpieczniejszy sposób niż rozszerzone procedury składowane do pisania procedur składowanych, które należy wykonać, nie można wykonywać zadań w języku Transact-SQL. Aby uzyskać więcej informacji na temat integracji środowiska CLR i rozszerzonych procedur składowanych, zobacz Wydajność architektury integracji środowiska CLR.