Showing posts with label ssis. Show all posts
Showing posts with label ssis. Show all posts

Friday, March 30, 2012

max memory for SSIS?

If we have a SQL Server 2005 standard edition/Windows 2003 Standard
Environment on a 32 bit 2 dual core proc Dell 2850 server, what is the
maximum size of the memory we could possibly have?
Thank you,
ShivaAnswered in microsoft.public.sqlserver.integrationsvcs
*mike hodgson*
http://sqlnerd.blogspot.com
Shiva wrote:

>If we have a SQL Server 2005 standard edition/Windows 2003 Standard
>Environment on a 32 bit 2 dual core proc Dell 2850 server, what is the
>maximum size of the memory we could possibly have?
>Thank you,
>Shiva
>
>
>

Max memory for SSIS

If we have a SQL Server 2005 standard edition/Windows 2003 Standard Environment on a 32 bit 2 dual core proc Dell 2850 server, what is the maximum size of the memory we could possibly have?

Thank you,

Shiva

SQL 2005 standard doesn't have a maximum memory, you are constrained by your OS and hardware. I think it's around 4 gigs for 2003 standard 32bit.|||

yosonu wrote:

If we have a SQL Server 2005 standard edition/Windows 2003 Standard Environment on a 32 bit 2 dual core proc Dell 2850 server, what is the maximum size of the memory we could possibly have?

Thank you,

Shiva

Is this a question about SSIS? If so, read this: http://blogs.conchango.com/jamiethomson/archive/2005/05/29/1486.aspx

If not, try a different forum.

-Jamie

|||

The 32bit Windows limit is 2GB per process. You can increase this to 3GB, using the boot.ini switch, /3GB.

A classic tip around this is to use several packages and Execute Process Tasks to combine them, but set the out of process option on, as this means each package then gets 2GB as each is it's own process. For small packages this may be detrimental though.

sql

Monday, February 20, 2012

master/Child Deployment

Hi Guru's,

I am facing a problem in deploying the SSIS packages.

My Scenario is like this

1. Have one Master SSIS Package.

2. Master SSIS Package inturn calls 3 Different packages using execute package task.

3. I have a common Configuration file for all these packages.

4. I am using File System deployment.

5. I have imported all the packages i.e master and the 3 child packages using SQL Server management studio.

6. Now i have created a job, and added the master package as a step.

7. I have a variable declared in the configuration file and the child packages will be getting their path from this variable.

The problem since i know the imported packages lies in "C:\Program Files\Microsoft SQL Server\90\DTS\Packages\<<Folder Name>>" i have poited the child package variable to point to this directory.

I still want to import all the packages and want to get this directory info dynamically thorugh the script so that i can assign this at run time.

I am using "Directory.GetCurrentDirectory" But it's giving me a different location when we run the master package.

Can any one has any idea or comments how to retrive the path of the master package?

Even a work around or any other option is also fine....

Regads,

Dev

I may not be clear on your requirements, but here's what I do:

I have a configuration file that is used by all packages, for database connections and whatnot, and a I have one that is specifically for the master. If any of the child packages need anything from the master configuration file, the master package will pass the information down to them.

The master has a variable named ChildPackagePath which is the folder location of the child packages. This variable is set by the master's configuration file. I then use expressions on the connection managers to the child packages to set the Connection String property as @.ChildPackagePath + "packagname.dtsx".

This allows you to vary the location of the child packages by the server environment. I don't think that determining the package location dynamically at runtime is possible. Your best bet is to use a path defined in a configuration file, or use a path that is dynamically available in an environment variable such as USERPROFILE.