Showing posts with label bit. Show all posts
Showing posts with label bit. Show all posts

Friday, March 30, 2012

PAE & AWE on x64 Windows & SQL

We've just setup some new Microsoft SQL 2005 servers running windows 2003 R2
x64 with 16GB of RAM. Since we are running a 64 bit version of windows and a
64 bit version of SQL, is it any longer neccesary to add the /3GB /PAE
option in the boot.ini and enable AWE in SQL?
Thanks!
Brad"Brad Baker" <brad@.nospam.nospam> wrote in message
news:OF%23WZo3xGHA.2384@.TK2MSFTNGP05.phx.gbl...
> We've just setup some new Microsoft SQL 2005 servers running windows 2003
> R2 x64 with 16GB of RAM. Since we are running a 64 bit version of windows
> and a 64 bit version of SQL, is it any longer neccesary to add the /3GB
> /PAE option in the boot.ini and enable AWE in SQL?
>
Slava says no /3GB, no /PAE, no AWE option. Just grant the SQL account the
"Lock Pages in Memory" privilege.
Q and A: Using Lock Pages In memory on 64 bit platform
Q: Hello Slava, I would like to confirm my understanding that on SQL 2005
64 bit edition it is recommended to grant Lock Pages in Memory right to the
SQL account and then turn on the AWE setting. Thanks
A: Yes, we do recommend to turn on Lock pages in memory so that OS doesn't
page SQL Server out. However on 64 bit you only need to grant the right
"Lock Pages in Memory" to the SQL account for SQL Server to utilize this
feature. You do need to to change any of AWE settings through sp_configure.
http://blogs.msdn.com/slavao/archive/2005/08/31/458545.aspx
Slava explains:
http://blogs.msdn.com/slavao/archive/2005/04/29/413425.aspx
David

PAE & AWE on x64 Windows & SQL

We've just setup some new Microsoft SQL 2005 servers running windows 2003 R2
x64 with 16GB of RAM. Since we are running a 64 bit version of windows and a
64 bit version of SQL, is it any longer neccesary to add the /3GB /PAE
option in the boot.ini and enable AWE in SQL?
Thanks!
Brad"Brad Baker" <brad@.nospam.nospam> wrote in message
news:OF%23WZo3xGHA.2384@.TK2MSFTNGP05.phx.gbl...
> We've just setup some new Microsoft SQL 2005 servers running windows 2003
> R2 x64 with 16GB of RAM. Since we are running a 64 bit version of windows
> and a 64 bit version of SQL, is it any longer neccesary to add the /3GB
> /PAE option in the boot.ini and enable AWE in SQL?
>
Slava says no /3GB, no /PAE, no AWE option. Just grant the SQL account the
"Lock Pages in Memory" privilege.
Q and A: Using Lock Pages In memory on 64 bit platform
Q: Hello Slava, I would like to confirm my understanding that on SQL 2005
64 bit edition it is recommended to grant Lock Pages in Memory right to the
SQL account and then turn on the AWE setting. Thanks
A: Yes, we do recommend to turn on Lock pages in memory so that OS doesn't
page SQL Server out. However on 64 bit you only need to grant the right
"Lock Pages in Memory" to the SQL account for SQL Server to utilize this
feature. You do need to to change any of AWE settings through sp_configure.
http://blogs.msdn.com/slavao/archiv.../31/458545.aspx
Slava explains:
http://blogs.msdn.com/slavao/archiv.../29/413425.aspx
David

Monday, March 26, 2012

Package with File System Task doesn't work without sensitive data with user keys

This problem is a bit weird but I'm just wondering if anybody else experienced this.

I have a package that has file system tasks (copying dtsx files actually). Basically the package copies other packages to a pre-defined destination. Thing is, it only works if one of the packages it is configured to copy has some sort of sensitive data (e.g., a connectionstring with a password), otherwise it reports a success message on execution but doesn't actually do anything. I've checked the forcedexecutionresult and it is set to None for that matter.

Just wondering if anybody else experienced this problem and of course if there's a way to solve it.

Thanks.Could the security permissions be different on your packages that are failing to be moved from those that are succeeding?|||No, they're all set to EncryptSensitiveWithUserKey.

However, all of the packages involved have their sensitive information set to obtaining them from Indirect Configuration Files. The only way around that I found so far was to put in a dummy connection object, set up an XML file package configuration for that dummy, and deploy it that way.

I'm suspecting that the user key isn't generated at all when all the packages get their configs from Indirect Configuration Files. For some reason, DontSaveSensitive doesn't work either. My original package insists on the presence of a key. Might have something to do with file read/write/modify permissions that come with the key?

I still want to do away with the dummy though.

Monday, March 12, 2012

Package Configuration

Here is the scenario we are

trying to use; (it a bit long winded please bare with me)

There are 2 Packages Parent

and Child. Both have 2 Connection Managers (��Configuration�� & ��Data Connection��).

The ��Data Connection�� has an invalid connection set to start with this is so

that we can deploy this to multiple places and use a SQL table to hold the

configuration.


At runtime ��Configuration�� is

set to a valid SQL2005 database connection via the command line or in BI but ��Data

Connection�� is left invalid.


The Package Configuration point

to an SQL server using ��Configuration�� this has the connection string for the ��Data

Connection�� Connection Manager (a valid connection string). The package errors

with can not acquire connection.


The first task is to put the

Connection string of the Connection manager ��Configuration�� in to a variable.

Then the child package is called.


The Child package has the same

2 connections ��Configuration�� & ��Data Connection�� both are Invalid at this

time.


1) We use the Package

Configuration to populate a variable from the parent package which holds the ��Configuration��

connection string.

2) We use a Package

Configuration to populate then Configuration�� connection from the parent

package which holds the ��Configuration�� connection.

3) We use a Package

Configuration to populate the ��Data Connection�� Connection Manager using the ��Configuration��

connection. Which should be Set via step 2 here.


The First task on the child

package has a bit of script to check all the connection manager return a valid

connection to make sure database are up and running before connection. This

fails at the moment return in an error.


We want to use the same code

in multiple environments and as such don��t want to make code changes that are really

only environment changes.

IE connection string to

servers. I can��t seem to see anything saying we are doping anything wrong but if

the connections are all set to a valid connection before running this seems to

work. When invalid connection are used this seems to fall over.

Peter you might be seeing the result of a known issue. When you define a package configuration using 'Parent package variable' type; no matter in which order you place it; it will be executed last.

You can see the details here: https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=126146

PeterCh wrote:


The Child package has the same 2 connections ��Configuration�� & ��Data Connection�� both are Invalid at this time.


1) We use the Package Configuration to populate a variable from the parent package which holds the ��Configuration�� connection string.

2) We use a Package Configuration to populate then Configuration�� connection from the parent package which holds the ��Configuration�� connection.

3) We use a Package Configuration to populate the ��Data Connection�� Connection Manager using the ��Configuration�� connection. Which should be Set via step 2 here.

With this bug, your 2nd step occurs last; so your 3rd step would try to use the invalid connection string defined in the package; in consequence the configuration will not be actually performed.

Just to check, when running the packages in debug mode in BIDS, go to the progress tab and see in which order the package configurations are performed.

As a work around and since this issue only affects the behavior of ��parent package variable�� configuration type; instead of sending the connection string of ��Configuration�� via command line when calling the parent package; you can try to place it in a environment variable or file and then create a configuration on every package. Then create additional package configurations for the remaining connections managers using ��configuration�� connection manager.

I hope this help