Projektowanie zestawy
W tym temacie opisano następujące czynniki należy rozważyć podczas projektowania zestawów:
Zestawy wspólne pakowanie
Zarządzanie zabezpieczeniami wirtualny plik dziennika
Ograniczenia dotyczące zestawów
Zestawy opakowań
wirtualny plik dziennika Może zawierać funkcje dla więcej niż jednego SQL Server Procedura lub wpisz jej klasy i metody. W większości przypadków, warto pakiet funkcje służące do wykonywania funkcji pokrewnych w ramach tego samego wirtualny plik dziennika, zwłaszcza wtedy, gdy te procedury udostępniania klas, metod, których wymagają innych procedur.Na przykład klas, wykonywanie zadań związanych z zarządzaniem wprowadzania danych dla wspólnych Wyzwalacze (CLR) środowiska wykonawczego języka i CLR procedury przechowywane mogą być spakowane w tego samego wirtualny plik dziennika.Dzieje się tak, ponieważ metody dla tych klas są bardziej prawdopodobne, że wywołania sobie nawzajem od tych mniej powiązanych zadań.
Kod opakowania do wirtualny plik dziennika, gdy, należy wziąć pod uwagę następujące czynności:
Typy zdefiniowane przez użytkownika środowiska CLR i indeksy, które zależą od funkcji zdefiniowanych przez użytkownika środowiska CLR może być przyczyną danych w bazie danych, zależy od tego wirtualny plik dziennika.Modyfikowanie kodu wirtualny plik dziennika jest często bardziej złożone, gdy jest zależny od wirtualny plik dziennika w bazie danych.Dlatego lepiej jest zwykle do oddzielenia kod, na którym opierają się zależności danych (na przykład w przypadku typów zdefiniowanych przez użytkownika i indeksów za pomocą funkcji zdefiniowanych przez użytkownika) z kodu, który nie ma zależności tych danych.Aby uzyskać więcej informacji zobacz Zestawy wykonawczych i ALTER ASSEMBLY (Transact-SQL).
Jeśli fragment kod zarządzany wymaga wyższych uprawnień, lepiej podzielić ten kod na oddzielne jest wirtualny plik dziennika z kodu, która nie wymaga wyższych uprawnień.
Zarządzanie zabezpieczeniami wirtualny plik dziennika
Można kontrolować, ile wirtualny plik dziennika mogą uzyskać dostęp do zasobów chronionych przez zabezpieczenia programu Access kod .NET podczas uruchamiania kod zarządzany.W tym celu należy określić jedną z trzech zestawów uprawnień podczas tworzenia lub modyfikowania wirtualny plik dziennika: BEZPIECZNE EXTERNAL_ACCESS, lub UNSAFE.
BEZPIECZNE
BEZPIECZNE jest domyślny zestaw uprawnień i jest najbardziej restrykcyjne.Kod uruchamiany przez zespół z uprawnieniami awaryjny nie może uzyskać dostępu do zasobów zewnętrznych systemowych, takich jak pliki, w sieci, zmiennych środowiskowych lub w rejestrze.Kod awaryjny może uzyskiwać dostęp do danych z lokalnej SQL Server w bazach danych lub wykonywanie obliczeń i logika biznesowa, które nie wymagają dostępu do zasobów poza lokalnych bazach danych.
Większość zestawów wykonywać obliczeń i danych zadań związanych z zarządzaniem bez dostępu do zasobów poza SQL Server. Firma Microsoft zaleca więc BEZPIECZNEJ jako wirtualny plik dziennika uprawnień wirtualny plik dziennika.
EXTERNAL_ACCESS
Umożliwia EXTERNAL_ACCESS dla zespołów, aby uzyskać dostęp do niektórych zasobów systemowych zewnętrznych takich jak pliki, sieci, usługi sieci Web, zmiennych środowiskowych i rejestru.Tylko SQL Server identyfikatory logowania z uprawnieniami dostępu EXTERNAL mogą tworzyć zestawy EXTERNAL_ACCESS.
AWARYJNY i zestawy EXTERNAL_ACCESS może zawierać tylko kod verifiably typu palety.Oznacza to, że te zestawy może uzyskać dostęp tylko do klasy za pomocą punktów wejścia dobrze określone, które są prawidłowe dla definicji typu.Dlatego też arbitralnie nie mają dostępu buforów pamięci właścicielem nie kod.Ponadto nie można wykonać operacji, które może mieć niekorzystny wpływ na niezawodność z SQL Server proces.
NIEBEZPIECZNE
Umożliwia bezpieczne zestawów nieograniczony dostęp do zasobów, do wewnątrz i na zewnątrz SQL Server. Kod, który działa z w trakcie UNSAFE wirtualny plik dziennika mogą wywoływać kod niezarządzany.
Ponadto określanie UNSAFE pozwala na kod w wirtualny plik dziennika do wykonywania operacji, które są uważane za niebezpieczne typu przez inspektora środowiska CLR.Czynności te może potencjalnie uzyskać dostęp do buforów pamięci w SQL Server przestrzeni procesu, który w niekontrolowany sposób. NIEBEZPIECZNE zestawy można także potencjalnie subvert system zabezpieczeń: SQL Server lub plików wykonywalnych języka wspólnego. NIEBEZPIECZNE uprawnień należy przyznawać tylko do bardzo zaufanych zestawów przez doświadczonych programistów i administratorów.Tylko członkowie sysadmin stała rola serwera można utworzyć NIEBEZPIECZNY zestawów.
Ograniczenia dotyczące zestawów
SQL Server Niektóre ograniczenia są umieszczane w kod zarządzany w zestawach, aby upewnić się, że może działać w sposób niezawodny i skalowalny.Oznacza to, że pewne operacje, które mogą wpłynąć na niezawodności serwera, nie są dozwolone w zestawach bezpieczne i EXTERNAL_ACCESS.
Niedozwolone atrybuty niestandardowe
Zestawy nie mogą być odnotowany następujące atrybuty niestandardowe:
System.ContextStaticAttribute
System.MTAThreadAttribute
System.Runtime.CompilerServices.MethodImplAttribute
System.Runtime.CompilerServices.CompilationRelaxationsAttribute
System.Runtime.Remoting.Contexts.ContextAttribute
System.Runtime.Remoting.Contexts.SynchronizationAttribute
System.Runtime.InteropServices.DllImportAttribute
System.Security.Permissions.CodeAccessSecurityAttribute
System.STAThreadAttribute
System.ThreadStaticAttribute
Ponadto bezpieczne i EXTERNAL_ACCESS zestawów nie mogą być odnotowany następujące atrybuty niestandardowe:
System.Security.SuppressUnmanagedCodeSecurityAttribute
System.Security.UnverifiableCodeAttribute
Niedozwolone interfejsów API systemu .NET Framework
Any Microsoft .NET Framework API that is annotated with one of the disallowed HostProtectionAttributes cannot be called from SAFE and EXTERNAL_ACCESS assemblies.
eSelfAffectingProcessMgmt
eSelfAffectingThreading
eSynchronization
eSharedState
eExternalProcessMgmt
eExternalThreading
eSecurityInfrastructure
eMayLeakOnAbort
eUI
Obsługiwany system .NET Framework zestawy
Każdy zespół, do której odwołuje się Twój niestandardowy wirtualny plik dziennika muszą być ładowane do SQL Server za pomocą MONTAŻOWYCH CREATE. Poniżej .NET Framework zestawy już są ładowane do SQL Server i dlatego mogą odwoływać się zestawów niestandardowych bez konieczności używania MONTAŻOWYCH CREATE.
custommarshallers.dll
Microsoft.visualbasic.dll
Microsoft.visualc.dll
mscorlib.dll
system.data.dll
System.Data.SqlXml.dll
system.dll
system.security.dll
system.web.services.dll
system.xml.dll
System.Transactions
System.Data.OracleClient
System.Configuration