John,

Could you clarify something?

I understand how .NET CLR and Linked Server queries (and extended stored procs) make use of the Virtual Address Space in the Database Engine's process. However, you mentioned SSIS and I'm not sure I understand how an SSIS package will put pressure on the Database Engine's VAS.

Please correct me if I'm wrong, but my understanding of an SSIS package execution flow is:

1) For ongoing permanent storage, an SSIS package is stored as XML on the hard drive, or in an internal format in an MSDB table, depending on where you "compile" it to via BIDS.

2) When your code calls the SSIS package, you tell the Integration Services service/process where your package is (on the hard drive, in MSDB, etc).

3) The Integration Services service grabs the package and loads it into its address space, and then begins execution.

4) Data obtained and manipulated by the package loads that information into the address space of the SSIS service as it moves through the various Flow tasks inside the package. Anytime the SSIS package accesses SQL Server, it is using standard SQL queries and thus behaves just like any client application would with respect to the DB Engine's memory utilization.

Thus, it is the SSIS service's address space that would be heavily affected by package execution, not the Database Engine's.

So might you mean possibly:

a) If the SSIS package is connecting through a "Shared Memory" protocal instead of TCP/IP or Named Pipes, memory inside the DB Engine's address space is necessary?

b) During execution of Maintenance Plans, which don't require an SSIS service on the machine to be running, the SSIS package supporting the maintenance plan must use the DB Engine's VAS?

Thanks,

Aaron M.