Hi there,
I am running on my machine the following SQL statements on my (local) SQL
Server:
SET NOCOUNT ON
SET ROWCOUNT 1500
delete_more:
delete table1 where field1 = '1' and field2 = '2'
IF @.@.ROWCOUNT > 0 GOTO delete_more
SET ROWCOUNT 0
The table has arround 5 million records and the DELETE statement would
delete arround 100000 records. I can see by running sp_lock that SQL is
escalating the locks to a table lock.
I am running in paralel the following:
SET ROWCOUNT 100
delete table1 where field1 = '3' and field2 = '2'
SET ROWCOUNT 0
This query is running fine, however the DELETE statement fails with the
error 1204:
"The SQL Server cannot obtain a LOCK resource at this time". Can somebody
shed some light for me here? Am I not able to run two DELETE statements is
paralel or am I doing something wrong?
I am running with the run_value for locks set to 0.
Thank you in advance.You mentioned there is already a table lock on that particular table, as it
is deleting millions of records. You probably need to wait for this
transaction to complete before you execute another delete statement on the
same table.
I suspect changing isolation level would solve your purpose.
"Andrei" wrote:
> Hi there,
> I am running on my machine the following SQL statements on my (local) SQL
> Server:
> SET NOCOUNT ON
> SET ROWCOUNT 1500
> delete_more:
> delete table1 where field1 = '1' and field2 = '2'
> IF @.@.ROWCOUNT > 0 GOTO delete_more
> SET ROWCOUNT 0
> The table has arround 5 million records and the DELETE statement would
> delete arround 100000 records. I can see by running sp_lock that SQL is
> escalating the locks to a table lock.
> I am running in paralel the following:
> SET ROWCOUNT 100
> delete table1 where field1 = '3' and field2 = '2'
> SET ROWCOUNT 0
> This query is running fine, however the DELETE statement fails with the
> error 1204:
> "The SQL Server cannot obtain a LOCK resource at this time". Can somebody
> shed some light for me here? Am I not able to run two DELETE statements is
> paralel or am I doing something wrong?
> I am running with the run_value for locks set to 0.
> Thank you in advance.|||What I want is to run several jobs concurrently, I do not want to wait for
one to finish in order to start the second one.
However I do not understand why I get the error, since the first statement
is suppose to delete 1500 records (so maximum 1500 key locks applied, if
there is no lock escalation) and the second statement is deleting 100
records. Am I missing something here?
"GYK" wrote:
> You mentioned there is already a table lock on that particular table, as it
> is deleting millions of records. You probably need to wait for this
> transaction to complete before you execute another delete statement on the
> same table.
> I suspect changing isolation level would solve your purpose.
> "Andrei" wrote:
> > Hi there,
> >
> > I am running on my machine the following SQL statements on my (local) SQL
> > Server:
> >
> > SET NOCOUNT ON
> >
> > SET ROWCOUNT 1500
> > delete_more:
> > delete table1 where field1 = '1' and field2 = '2'
> > IF @.@.ROWCOUNT > 0 GOTO delete_more
> > SET ROWCOUNT 0
> >
> > The table has arround 5 million records and the DELETE statement would
> > delete arround 100000 records. I can see by running sp_lock that SQL is
> > escalating the locks to a table lock.
> >
> > I am running in paralel the following:
> > SET ROWCOUNT 100
> > delete table1 where field1 = '3' and field2 = '2'
> > SET ROWCOUNT 0
> >
> > This query is running fine, however the DELETE statement fails with the
> > error 1204:
> > "The SQL Server cannot obtain a LOCK resource at this time". Can somebody
> > shed some light for me here? Am I not able to run two DELETE statements is
> > paralel or am I doing something wrong?
> >
> > I am running with the run_value for locks set to 0.
> >
> > Thank you in advance.
Showing posts with label lock. Show all posts
Showing posts with label lock. Show all posts
Friday, March 16, 2012
Thursday, March 8, 2012
"sa" Login locking resources?
I see lock timeouts in my trace and the object_id is for the same table
every time.
However, something does not seem right - the timeouts all show login = "sa".
Also, when I did a trace of lock acquired I see a lot of locks for that
table being acquired by login = "sa". There are locks being acquired by the
user being used for the connection by the application. But I cannot figure
out why "sa" is locking anything.
Can anyone out there help me?
TIA,
RohanDo you have any scheduled jobs that could be running in the context of 'sa'.
.?
"Rohan Hattangdi" wrote:
> I see lock timeouts in my trace and the object_id is for the same table
> every time.
> However, something does not seem right - the timeouts all show login = "sa
".
> Also, when I did a trace of lock acquired I see a lot of locks for that
> table being acquired by login = "sa". There are locks being acquired by th
e
> user being used for the connection by the application. But I cannot figure
> out why "sa" is locking anything.
> Can anyone out there help me?
> TIA,
> Rohan
>
>|||No ...
This is a load-test server and the only three jobs on there are for backup,
integrity checks and optimizations - they run at 12am, 1am and 2am
respectively. So it could not be jobs.
Any other ideas?
TIA,
Rohan
"Alien2_51" <dan.billow.remove@.monacocoach.removeme.com> wrote in message
news:E4FED000-D1E9-4D15-8118-8E751AA94CD9@.microsoft.com...
> Do you have any scheduled jobs that could be running in the context of
> 'sa'...?
> "Rohan Hattangdi" wrote:
>|||Rohan Hattangdi wrote:
> No ...
> This is a load-test server and the only three jobs on there are for
> backup, integrity checks and optimizations - they run at 12am, 1am
> and 2am respectively. So it could not be jobs.
> Any other ideas?
> TIA,
> Rohan
>
Change the "sa" password and see if the problem continues. If someone is
using the "sa" account without you knowing about it or an application
somewhere hard-codes the account login, you're likely to get a phone
call.
The other thing you can do is check the net_address in the sysprocesses
table and call your network admin and have him/her tell you whose PC the
MAC address belongs to.
David Gugick
Imceda Software
www.imceda.com|||That is a good idea.
Let me see what happens now.
Thank you,
Rohan
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:OUDf6ylKFHA.1284@.TK2MSFTNGP14.phx.gbl...
> Rohan Hattangdi wrote:
> Change the "sa" password and see if the problem continues. If someone is
> using the "sa" account without you knowing about it or an application
> somewhere hard-codes the account login, you're likely to get a phone call.
> The other thing you can do is check the net_address in the sysprocesses
> table and call your network admin and have him/her tell you whose PC the
> MAC address belongs to.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com|||I spoke too soon.
Changing the pwd seems to have had no effect.
This is very strange. Why would it say "sa"? If a lock timeout event
occurs on the connection made by the application, should not the login name
be that used by the application to connect to SQL Server?
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:OUDf6ylKFHA.1284@.TK2MSFTNGP14.phx.gbl...
> Rohan Hattangdi wrote:
> Change the "sa" password and see if the problem continues. If someone is
> using the "sa" account without you knowing about it or an application
> somewhere hard-codes the account login, you're likely to get a phone call.
> The other thing you can do is check the net_address in the sysprocesses
> table and call your network admin and have him/her tell you whose PC the
> MAC address belongs to.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com|||Rohan Hattangdi wrote:
> I spoke too soon.
> Changing the pwd seems to have had no effect.
> This is very strange. Why would it say "sa"? If a lock timeout event
> occurs on the connection made by the application, should not the
> login name be that used by the application to connect to SQL Server?
Were those "sa" logins logged out before the password change? If not, I
think they woudl stay connected and would just have a problem the next
time around. But, yes, in most cases you should see the login name used
in the lock timeout event. Unless you are using Application Roles.
Run sp_helprole and see if any are Application Roles.
David Gugick
Imceda Software
www.imceda.com
every time.
However, something does not seem right - the timeouts all show login = "sa".
Also, when I did a trace of lock acquired I see a lot of locks for that
table being acquired by login = "sa". There are locks being acquired by the
user being used for the connection by the application. But I cannot figure
out why "sa" is locking anything.
Can anyone out there help me?
TIA,
RohanDo you have any scheduled jobs that could be running in the context of 'sa'.
.?
"Rohan Hattangdi" wrote:
> I see lock timeouts in my trace and the object_id is for the same table
> every time.
> However, something does not seem right - the timeouts all show login = "sa
".
> Also, when I did a trace of lock acquired I see a lot of locks for that
> table being acquired by login = "sa". There are locks being acquired by th
e
> user being used for the connection by the application. But I cannot figure
> out why "sa" is locking anything.
> Can anyone out there help me?
> TIA,
> Rohan
>
>|||No ...
This is a load-test server and the only three jobs on there are for backup,
integrity checks and optimizations - they run at 12am, 1am and 2am
respectively. So it could not be jobs.
Any other ideas?
TIA,
Rohan
"Alien2_51" <dan.billow.remove@.monacocoach.removeme.com> wrote in message
news:E4FED000-D1E9-4D15-8118-8E751AA94CD9@.microsoft.com...
> Do you have any scheduled jobs that could be running in the context of
> 'sa'...?
> "Rohan Hattangdi" wrote:
>|||Rohan Hattangdi wrote:
> No ...
> This is a load-test server and the only three jobs on there are for
> backup, integrity checks and optimizations - they run at 12am, 1am
> and 2am respectively. So it could not be jobs.
> Any other ideas?
> TIA,
> Rohan
>
Change the "sa" password and see if the problem continues. If someone is
using the "sa" account without you knowing about it or an application
somewhere hard-codes the account login, you're likely to get a phone
call.
The other thing you can do is check the net_address in the sysprocesses
table and call your network admin and have him/her tell you whose PC the
MAC address belongs to.
David Gugick
Imceda Software
www.imceda.com|||That is a good idea.
Let me see what happens now.
Thank you,
Rohan
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:OUDf6ylKFHA.1284@.TK2MSFTNGP14.phx.gbl...
> Rohan Hattangdi wrote:
> Change the "sa" password and see if the problem continues. If someone is
> using the "sa" account without you knowing about it or an application
> somewhere hard-codes the account login, you're likely to get a phone call.
> The other thing you can do is check the net_address in the sysprocesses
> table and call your network admin and have him/her tell you whose PC the
> MAC address belongs to.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com|||I spoke too soon.
Changing the pwd seems to have had no effect.
This is very strange. Why would it say "sa"? If a lock timeout event
occurs on the connection made by the application, should not the login name
be that used by the application to connect to SQL Server?
"David Gugick" <davidg-nospam@.imceda.com> wrote in message
news:OUDf6ylKFHA.1284@.TK2MSFTNGP14.phx.gbl...
> Rohan Hattangdi wrote:
> Change the "sa" password and see if the problem continues. If someone is
> using the "sa" account without you knowing about it or an application
> somewhere hard-codes the account login, you're likely to get a phone call.
> The other thing you can do is check the net_address in the sysprocesses
> table and call your network admin and have him/her tell you whose PC the
> MAC address belongs to.
>
> --
> David Gugick
> Imceda Software
> www.imceda.com|||Rohan Hattangdi wrote:
> I spoke too soon.
> Changing the pwd seems to have had no effect.
> This is very strange. Why would it say "sa"? If a lock timeout event
> occurs on the connection made by the application, should not the
> login name be that used by the application to connect to SQL Server?
Were those "sa" logins logged out before the password change? If not, I
think they woudl stay connected and would just have a problem the next
time around. But, yes, in most cases you should see the login name used
in the lock timeout event. Unless you are using Application Roles.
Run sp_helprole and see if any are Application Roles.
David Gugick
Imceda Software
www.imceda.com
Saturday, February 25, 2012
"Lock Pages in Memory" Service Account and SQL Agent
Microsoft recommends using the Lock Pages in Memory privilege for SQl
Server 2005 x64 running on Windows Server 2003 R2 x64.
If granting this privilege allows this user to Lock Pages in Memory,
should SQL Agent be changed to use a different service account that
does not have this privilege? (both SQL and Agent use the same account
currently)
I am thinking that if both SQL Server and SQL Agent are running under
a account with this privilege if they will conflict. Is this the case?Perhaps you are talking about this on BOL
"Although it is not required, we recommend locking pages in memory when
using 64-bit operating systems. For 32-bit operating systems, Lock pages in
memory permission must be granted before AWE is configured for SQL Server."
I do not see why there could be a conflict if both services are using the
same Windows account and this account has the Lock pages in memory permission
granted. It should be Ok.
(BOL note from
Enabling Memory Support for Over 4 GB of Physical Memory
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/34950321-2bfd-4679-8f1b-0a0a440eb443.htm
)
Hope this helps,
Ben Nevarez
"Neufusion" wrote:
> Microsoft recommends using the Lock Pages in Memory privilege for SQl
> Server 2005 x64 running on Windows Server 2003 R2 x64.
> If granting this privilege allows this user to Lock Pages in Memory,
> should SQL Agent be changed to use a different service account that
> does not have this privilege? (both SQL and Agent use the same account
> currently)
> I am thinking that if both SQL Server and SQL Agent are running under
> a account with this privilege if they will conflict. Is this the case?
>|||The main SQL Server service is specifically designed for managing large
amounts of memory and has an option to use AWE but the SQL Agent only works
like any other regular program as far as memory management's concerned
(Virtual Memory). Therefore there's no reason to think both services would
make large AWE allocations at startup.
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
Benchmark your query performance
http://www.SQLBenchmarkPro.com
"Neufusion" <mikeymiller@.gmail.com> wrote in message
news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
> Microsoft recommends using the Lock Pages in Memory privilege for SQl
> Server 2005 x64 running on Windows Server 2003 R2 x64.
> If granting this privilege allows this user to Lock Pages in Memory,
> should SQL Agent be changed to use a different service account that
> does not have this privilege? (both SQL and Agent use the same account
> currently)
> I am thinking that if both SQL Server and SQL Agent are running under
> a account with this privilege if they will conflict. Is this the case?|||If I remember correctly, the "Lock pages in memory" setting only applies to
Enterprise, not Standard edition. not sure which you are running
--
Kevin3NF
SQL Server dude
You want fries with that?
http://kevin3nf.blogspot.com/
I only check the newsgroups during work hours, M-F.
Hit my blog and the contact links if necessary...I may be available.
"Neufusion" <mikeymiller@.gmail.com> wrote in message
news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
> Microsoft recommends using the Lock Pages in Memory privilege for SQl
> Server 2005 x64 running on Windows Server 2003 R2 x64.
> If granting this privilege allows this user to Lock Pages in Memory,
> should SQL Agent be changed to use a different service account that
> does not have this privilege? (both SQL and Agent use the same account
> currently)
> I am thinking that if both SQL Server and SQL Agent are running under
> a account with this privilege if they will conflict. Is this the case?|||This was true for SQL 2000 but not SQL 2005
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
Benchmark your query performance
http://www.SQLBenchmarkPro.com
"Kevin3NF" <kevin@.SPAMTRAP.3nf-inc.com> wrote in message
news:Oh8WQgnYIHA.3964@.TK2MSFTNGP03.phx.gbl...
> If I remember correctly, the "Lock pages in memory" setting only applies
> to Enterprise, not Standard edition. not sure which you are running
> --
> Kevin3NF
> SQL Server dude
> You want fries with that?
> http://kevin3nf.blogspot.com/
> I only check the newsgroups during work hours, M-F.
> Hit my blog and the contact links if necessary...I may be available.
>
> "Neufusion" <mikeymiller@.gmail.com> wrote in message
> news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
>> Microsoft recommends using the Lock Pages in Memory privilege for SQl
>> Server 2005 x64 running on Windows Server 2003 R2 x64.
>> If granting this privilege allows this user to Lock Pages in Memory,
>> should SQL Agent be changed to use a different service account that
>> does not have this privilege? (both SQL and Agent use the same account
>> currently)
>> I am thinking that if both SQL Server and SQL Agent are running under
>> a account with this privilege if they will conflict. Is this the case?
>|||http://support.microsoft.com/kb/918483/en-us
Note For 64-bit systems, SQL Server 2005 Enterprise Edition is the only
edition that is designed to use lock pages in memory.
Am I misreading? I have a 3 node, 2 instance cluster my customer is about
to upgrade for this very reason...
--
Kevin3NF
SQL Server dude
You want fries with that?
http://kevin3nf.blogspot.com/
I only check the newsgroups during work hours, M-F.
Hit my blog and the contact links if necessary...I may be available.
"Greg Linwood" <g_linwood@.hotmail.com> wrote in message
news:utExsLrYIHA.4196@.TK2MSFTNGP04.phx.gbl...
> This was true for SQL 2000 but not SQL 2005
> Regards,
> Greg Linwood
> SQL Server MVP
> http://blogs.sqlserver.org.au/blogs/greg_linwood
> Benchmark your query performance
> http://www.SQLBenchmarkPro.com
> "Kevin3NF" <kevin@.SPAMTRAP.3nf-inc.com> wrote in message
> news:Oh8WQgnYIHA.3964@.TK2MSFTNGP03.phx.gbl...
>> If I remember correctly, the "Lock pages in memory" setting only applies
>> to Enterprise, not Standard edition. not sure which you are running
>> --
>> Kevin3NF
>> SQL Server dude
>> You want fries with that?
>> http://kevin3nf.blogspot.com/
>> I only check the newsgroups during work hours, M-F.
>> Hit my blog and the contact links if necessary...I may be available.
>>
>> "Neufusion" <mikeymiller@.gmail.com> wrote in message
>> news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
>> Microsoft recommends using the Lock Pages in Memory privilege for SQl
>> Server 2005 x64 running on Windows Server 2003 R2 x64.
>> If granting this privilege allows this user to Lock Pages in Memory,
>> should SQL Agent be changed to use a different service account that
>> does not have this privilege? (both SQL and Agent use the same account
>> currently)
>> I am thinking that if both SQL Server and SQL Agent are running under
>> a account with this privilege if they will conflict. Is this the case?
>>
>
Server 2005 x64 running on Windows Server 2003 R2 x64.
If granting this privilege allows this user to Lock Pages in Memory,
should SQL Agent be changed to use a different service account that
does not have this privilege? (both SQL and Agent use the same account
currently)
I am thinking that if both SQL Server and SQL Agent are running under
a account with this privilege if they will conflict. Is this the case?Perhaps you are talking about this on BOL
"Although it is not required, we recommend locking pages in memory when
using 64-bit operating systems. For 32-bit operating systems, Lock pages in
memory permission must be granted before AWE is configured for SQL Server."
I do not see why there could be a conflict if both services are using the
same Windows account and this account has the Lock pages in memory permission
granted. It should be Ok.
(BOL note from
Enabling Memory Support for Over 4 GB of Physical Memory
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/34950321-2bfd-4679-8f1b-0a0a440eb443.htm
)
Hope this helps,
Ben Nevarez
"Neufusion" wrote:
> Microsoft recommends using the Lock Pages in Memory privilege for SQl
> Server 2005 x64 running on Windows Server 2003 R2 x64.
> If granting this privilege allows this user to Lock Pages in Memory,
> should SQL Agent be changed to use a different service account that
> does not have this privilege? (both SQL and Agent use the same account
> currently)
> I am thinking that if both SQL Server and SQL Agent are running under
> a account with this privilege if they will conflict. Is this the case?
>|||The main SQL Server service is specifically designed for managing large
amounts of memory and has an option to use AWE but the SQL Agent only works
like any other regular program as far as memory management's concerned
(Virtual Memory). Therefore there's no reason to think both services would
make large AWE allocations at startup.
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
Benchmark your query performance
http://www.SQLBenchmarkPro.com
"Neufusion" <mikeymiller@.gmail.com> wrote in message
news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
> Microsoft recommends using the Lock Pages in Memory privilege for SQl
> Server 2005 x64 running on Windows Server 2003 R2 x64.
> If granting this privilege allows this user to Lock Pages in Memory,
> should SQL Agent be changed to use a different service account that
> does not have this privilege? (both SQL and Agent use the same account
> currently)
> I am thinking that if both SQL Server and SQL Agent are running under
> a account with this privilege if they will conflict. Is this the case?|||If I remember correctly, the "Lock pages in memory" setting only applies to
Enterprise, not Standard edition. not sure which you are running
--
Kevin3NF
SQL Server dude
You want fries with that?
http://kevin3nf.blogspot.com/
I only check the newsgroups during work hours, M-F.
Hit my blog and the contact links if necessary...I may be available.
"Neufusion" <mikeymiller@.gmail.com> wrote in message
news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
> Microsoft recommends using the Lock Pages in Memory privilege for SQl
> Server 2005 x64 running on Windows Server 2003 R2 x64.
> If granting this privilege allows this user to Lock Pages in Memory,
> should SQL Agent be changed to use a different service account that
> does not have this privilege? (both SQL and Agent use the same account
> currently)
> I am thinking that if both SQL Server and SQL Agent are running under
> a account with this privilege if they will conflict. Is this the case?|||This was true for SQL 2000 but not SQL 2005
Regards,
Greg Linwood
SQL Server MVP
http://blogs.sqlserver.org.au/blogs/greg_linwood
Benchmark your query performance
http://www.SQLBenchmarkPro.com
"Kevin3NF" <kevin@.SPAMTRAP.3nf-inc.com> wrote in message
news:Oh8WQgnYIHA.3964@.TK2MSFTNGP03.phx.gbl...
> If I remember correctly, the "Lock pages in memory" setting only applies
> to Enterprise, not Standard edition. not sure which you are running
> --
> Kevin3NF
> SQL Server dude
> You want fries with that?
> http://kevin3nf.blogspot.com/
> I only check the newsgroups during work hours, M-F.
> Hit my blog and the contact links if necessary...I may be available.
>
> "Neufusion" <mikeymiller@.gmail.com> wrote in message
> news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
>> Microsoft recommends using the Lock Pages in Memory privilege for SQl
>> Server 2005 x64 running on Windows Server 2003 R2 x64.
>> If granting this privilege allows this user to Lock Pages in Memory,
>> should SQL Agent be changed to use a different service account that
>> does not have this privilege? (both SQL and Agent use the same account
>> currently)
>> I am thinking that if both SQL Server and SQL Agent are running under
>> a account with this privilege if they will conflict. Is this the case?
>|||http://support.microsoft.com/kb/918483/en-us
Note For 64-bit systems, SQL Server 2005 Enterprise Edition is the only
edition that is designed to use lock pages in memory.
Am I misreading? I have a 3 node, 2 instance cluster my customer is about
to upgrade for this very reason...
--
Kevin3NF
SQL Server dude
You want fries with that?
http://kevin3nf.blogspot.com/
I only check the newsgroups during work hours, M-F.
Hit my blog and the contact links if necessary...I may be available.
"Greg Linwood" <g_linwood@.hotmail.com> wrote in message
news:utExsLrYIHA.4196@.TK2MSFTNGP04.phx.gbl...
> This was true for SQL 2000 but not SQL 2005
> Regards,
> Greg Linwood
> SQL Server MVP
> http://blogs.sqlserver.org.au/blogs/greg_linwood
> Benchmark your query performance
> http://www.SQLBenchmarkPro.com
> "Kevin3NF" <kevin@.SPAMTRAP.3nf-inc.com> wrote in message
> news:Oh8WQgnYIHA.3964@.TK2MSFTNGP03.phx.gbl...
>> If I remember correctly, the "Lock pages in memory" setting only applies
>> to Enterprise, not Standard edition. not sure which you are running
>> --
>> Kevin3NF
>> SQL Server dude
>> You want fries with that?
>> http://kevin3nf.blogspot.com/
>> I only check the newsgroups during work hours, M-F.
>> Hit my blog and the contact links if necessary...I may be available.
>>
>> "Neufusion" <mikeymiller@.gmail.com> wrote in message
>> news:9a4a6b46-f949-4c38-a277-9757134c0714@.d21g2000prg.googlegroups.com...
>> Microsoft recommends using the Lock Pages in Memory privilege for SQl
>> Server 2005 x64 running on Windows Server 2003 R2 x64.
>> If granting this privilege allows this user to Lock Pages in Memory,
>> should SQL Agent be changed to use a different service account that
>> does not have this privilege? (both SQL and Agent use the same account
>> currently)
>> I am thinking that if both SQL Server and SQL Agent are running under
>> a account with this privilege if they will conflict. Is this the case?
>>
>
Subscribe to:
Posts (Atom)
