![[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Programming the CLR in SQL Server 2005](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à SDC - Programming the CLR in SQL Server 2005.ppt (1.51 MB)
Similaire à SDC - Programming the CLR in SQL Server 2005.ppt (1.51 MB) (20)
Plus de webhostingguy
Plus de webhostingguy (20)
SDC - Programming the CLR in SQL Server 2005.ppt (1.51 MB)
- 1. Programming the CLR in SQL Server 2005 Mark Blomsma Develop-One Session Code: DB.08
- 14. Functions
- 16. Triggers
- 21. Deployment
- 23. Monitoring
- 25. Questions?
- 28. Evaluatieformulier Vul je evaluatieformulier in en maak kans op een van de prachtige prijzen!! Session Code: DB.08
Notes de l'éditeur
- The Common Language Runtime (CLR) is deeply integrated into the database engine. The CLR is really an engine of sorts that hosts applications—a special kind of application created using managed code. SQL Server is really a cohost of managed code. The SQL Engine works directly with the CLR to manage assemblies that have been placed inside SQL Server and that are called by Transact-SQL or MDX queries. The figure illustrates the coupling between the SQL Server Engine and the CLR. When you create an assembly in SQL Server, the bits are loaded into a table in the database. The assembly is registered but is not automatically pulled into memory. The bits simply exist in the database. The interaction between the CLR/hosting layer and the SQL operating system (OS) occurs until the assembly is called by a procedure. Upon evocation, the SQL Server Engine works with the CLR to manage memory, execution, and destruction of the running code for that assembly. Thus, the CLR goes through the SQL OS for the following: Memory. SQL Server manages its own memory. The CLR asks SQL for memory as needed. Threads/fibers get things done. Since SQL Server uses these natively, it makes sense for SQL to manage the CLR. All the threads are managed by SQL Server. Synchronization is moving data into and out of assemblies to TDS and in memory. The hosting layer has a set of APIs that manage the communication between the SQL Server OS and CLR. When objects are called, the CLR asks SQL Server for memory buffers, thread allocations, and security. The hosting layer manages the multiple security layers. The CLR uses something called an app domain to create an execution context that is really just a container for all the managed code found in a particular namespace. The app domain provides a container that controls interassembly interaction. Basically, no interaction occurs between different app domains. Thus, if a problem occurs, such as a memory issue, the app domain is the main container for SQL Server to unload the assembly. The CLR manages the escalation policy for assemblies. The CLR also maintains the state of the assembly. This topic could take up an entire chapter, but briefly, here’s what you need to know under All memory allocation from CLR through SQL Server.
- Attributes on SqlFunctionAttribute DataAccess IsDeterministic IsPrecise Name
- Safe: compute, access local data / database External access: files, registry, network Unsafe: full trust, unmanaged code, verification
- Here's a brief list of interesting ways to monitor assemblies: Profiler trace events: CLR:load assembly monitors assembly load requests (successes and failures) SQL:BatchStarting, BatchCompleted SP:Starting, Completed, StmtStarting, StmtCompleted monitor execution of Transact-SQL and CLR routines Performance counters: SQL Server: Total CLR time .NET CLR Memory Processor DMVs and catalog views: sys.assembly* shows basic information about the assemblies stored sys.dm_os_memory_clerks sys.dm_clr* sys.dm_exec_query_stats sys.dm_exec_requests sys.dm_exec_cached_plans