BEST RECOMMENDATION FOR A TESTING SCENARIO

guys:
I would like to have your best advise.
We am planning to install Passive/Active SQL server Clustering in the
production environment that includes two identical Dell PowerEdge 6650 dual
processor servers with a External Disk Storage PoweVault 220S. We have
bought two copies of Windows 2003 enterprise (for each one of the servers)
and one only copy of SQL Server 200 enterprise Edition licensed per
processor (I was told that only one copy of this software ins needed in an
Active/Passive mode)
On the other hand, since the configuration above would be in production at
all times, we would like to have similar scenario for development and
testing purposes.I was advised to replicate the same hardware and software
scenario described above, however, as you can see, it would be a costly
endeavor. Each Dell 6650 costs approximately $20,000 (two processors, 8 GB
RAM, 2 MB cache) the External Raid $8,000, the Windows 2003 Enterprise
server software $3,000 (for the two servers), and the SQL Server 200
enterprise software about $24,000 (license for two processor, for just one
server)
Could you please if you see any issue in the production scenario? Are we Ok
using only one copy of SQL server there?
Secondly, do we have any other choice for a development and testing
scenario? Most people recommend that a development and testing scenario
would be, if not identical, at least very similar to the production
scenario. I was planning to get those Dell 6650 server but with a single
processor, only 1 GB of RAM, and 1 MB cache (or even 512 KB). In terms of
software I was also told that one economical approach would be to acquire
the MSDN Universal subscription that allows use software for testing
(Windows and SQL server)
Thirdly, do you have any other (most economical recommendation in terms of
hardware and software for our development and testing scenario? How critical
is that this has to be very similar (or identical) to the production
scenario?
Thanks for all your answers
White
First off, what you are implementing is a single instance cluster, not an
active/passive cluster. It may just look like a term, but there is a very
dramatic difference between the two.
As for licensing SQL Server in a cluster, you have exactly what you need.
The easiest way to tally up licensing for a cluster is to ask how many SQL
Servers you can connect to from an application. In your case, it would be
1.
For the dev/testing environments, you do not need to purchase the Enterprise
Edition of SQL Server. You can use the Developer Edition which gives you
the full functionality of Enterprise Edition without all of the cost and
hardware requirements. This even allows you to simulate a cluster, you just
don't get full clustering functionality. But, you do NOT need to stuff
clusters into your dev/test environments. There is no case that I'm aware
of where a clustered SQL Server behaves differently with respect to an
application than a standalone SQL Server.
My recommendation would be to purchase a Dell 6650 with the external RAID
array. Depending on your testing and development scenario, you can very
easily place BOTH dev and test on the same machine in different SQL Server
instances without collisions. The only real reason to have completely
different systems for the two would be if you are doing a lot of very heavy
performance related work. If not, you can get away with a single machine
with external array + Windows 2003 Server + SQL Server 2000 Developer
Edition.
I can send you my address so you can send a check for the ~$54,000 that I
just saved you.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com

Best Protocol between linked servers

Hi All,
I'm setting up an environment with two SQLServer2005 instances (on two
different servers).
They're connected thru a linked server (server B to Server A).
Whenever I set the linked server up (in server B), it allows me to choose
between:
1) write the name of the linked server but it must be the same as the real
network name of the server
2) Allow me to choose several parameters but it doesn't use the SQLServer
protocol (faster than any other choice).
As the Stored Procedures (in server B) contains a reference to A's Tables
and it's kinda not possible to change all of them, how do I make the
communication between those server the best ?
Moreover, which protocol priority do I choose in the client network
configuration (Named Pipes is better than TCPIP) ?
Thanks
Igor.Hi Igor,
Take a look at this:
What to use Named Pipes or TCP/IP:
http://www.sqlcommunity.com/Default.aspx?grm2id=55&tabid=77
HTH
Thank you,
Saleem Hakani
HTTP://WWW.SQLCOMMUNITY.COM (World Wide SQL Server Community)
SQLTips, Scripts, Discussions, Blogs, Articles, Radio and a lot of SQL
Server Fun.
"Igor" wrote:
> Hi All,
> I'm setting up an environment with two SQLServer2005 instances (on two
> different servers).
> They're connected thru a linked server (server B to Server A).
> Whenever I set the linked server up (in server B), it allows me to choose
> between:
> 1) write the name of the linked server but it must be the same as the real
> network name of the server
> 2) Allow me to choose several parameters but it doesn't use the SQLServer
> protocol (faster than any other choice).
> As the Stored Procedures (in server B) contains a reference to A's Tables
> and it's kinda not possible to change all of them, how do I make the
> communication between those server the best ?
> Moreover, which protocol priority do I choose in the client network
> configuration (Named Pipes is better than TCPIP) ?
> Thanks
> Igor.

Best Practices Question

Environment is SQL Server 2005 x64 Enterprise running under Windows Server 2003 x64 Enterprise with four processors and 16GB of ram.

I have 28 data copy routines I would like to add to a SSIS package. They use the Data Reader Source to an ODBC database (InterSystems Cache) and copy the table contents to a SQL2005 database for reporting needs. The data rows in these 28 routines range from only 100 rows to over 6 million rows depending on the table. I have tested these individually and they work fine. My question is, is it a good practice to have all of these routines in a single package or can I expect performance degragation?

A single package is fine, but multiple packages are more supportable.|||

Thanks Phil. I should note that in this package, all 28 copy routines are in the same data flow object. Would it be better to have them in separate data flow objects? Also, when you say more supportable, are you referring to making it easier to troubleshoot?

|||

windthorstking wrote:

Thanks Phil. I should note that in this package, all 28 copy routines are in the same data flow object. Would it be better to have them in separate data flow objects? Also, when you say more supportable, are you referring to making it easier to troubleshoot?

I'd probably put the distinct "copy routines" into their own data flows, at the very least.

And yes, I mean it will be easier to troubleshoot.sql

Best Practice to deploy reports

I'm a DBA and need to deploy the reports our developers made in a test
environment on the production servers.
What is the best way of doing this.
Are there some how to's, white papers or best practices?
Regards"Zekske" <Zekske@.discussions.microsoft.com> schrieb im Newsbeitrag
news:2291B63E-7BC4-432B-A871-B0903C7E5179@.microsoft.com
> I'm a DBA and need to deploy the reports our developers made in a test
> environment on the production servers.
> What is the best way of doing this.
> Are there some how to's, white papers or best practices?
perhaps the tool could help:
Reporting Services Scripter
http://www.sqldbatips.com/showarticle.asp?ID=62
Gruß Olaf
Ich unterstütze PASS Deutschland e.V. (http://www.sqlpass.de)|||If you are allowed to use Visual Source Safe, I would:..
Create Configurations for each of your environments in BIDS.
Save all in Source Safe.
Then use BIDS to deploy using the configurations...
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
I support the Professional Association for SQL Server ( PASS) and it''s
community of SQL Professionals.
"Zekske" wrote:
> I'm a DBA and need to deploy the reports our developers made in a test
> environment on the production servers.
> What is the best way of doing this.
> Are there some how to's, white papers or best practices?
> Regards

Best Practice Analyzer & Custom Best Practices

Hi All,
The BPA is a great tool that can be used to audit an environment for
adherenace to proper configuration and basic T-SQL coding best practices.
Does anyone know if the BPA tool can be customized to include custom
best-practice rules that are in-addition to the standard best practices
included with the tool? For example, say for example if an orgainzation
would like to add custom rules that look for the existance of specific
UserID, specific SQLAgent Jobs, etc.
Thanks in advance for your assistance.
Dave
This is a feature request that the SQL team are well aware of but as you can
imagine with SQL2005 nearing the end of a long road (near being a relative
term!) it might be a while before a version of SQLBPA is released that
supports user defined rules.
HTH
Jasper Smith (SQL Server MVP)
http://www.sqldbatips.com
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"DBADave" <DBADave@.discussions.microsoft.com> wrote in message
news:405E1559-6CB7-4371-822B-CE4C523A5EF3@.microsoft.com...
> Hi All,
> The BPA is a great tool that can be used to audit an environment for
> adherenace to proper configuration and basic T-SQL coding best practices.
> Does anyone know if the BPA tool can be customized to include custom
> best-practice rules that are in-addition to the standard best practices
> included with the tool? For example, say for example if an orgainzation
> would like to add custom rules that look for the existance of specific
> UserID, specific SQLAgent Jobs, etc.
> Thanks in advance for your assistance.
> Dave

Best Practice

Can someone tell me what the best practice for managing a sql environment
is? Is it best to have a second user account besides your everyday user
account that has elevated permissions required to manage sql?Hi
http://vyaskn.tripod.com/sql_server_administration_best_practices.htm#Step1
--administaiting best practices
http://vyaskn.tripod.com/sql_server_security_best_practices.htm --security
best practices
"Bad Beagle" <maxwelli@.nospam.postalias> wrote in message
news:OnorAbVIIHA.5208@.TK2MSFTNGP04.phx.gbl...
> Can someone tell me what the best practice for managing a sql environment
> is? Is it best to have a second user account besides your everyday user
> account that has elevated permissions required to manage sql?
>

Best Performance?

Assume a heavy transaction environment.
Let's say we have the same database model,
same hardware, file usage, type of data, queries etc. on two servers.
Server A is configured with a RAID 5 on all the data disks (9 of them),
and Server B is configured with RAID 5 on the data disks (5 of them) but
transaction log and tempdb is separated to its own mirrored disks (4 of
them - 2 each).
Which SQL server will run faster in terms of query response time AND write
performance? Database in Server A or Server B?Assumimng disc io is the limiting factor then I would say B would be =most likely to outperform A. But even better would be lose the raid 5 =and use 0+1 on 4 discs. or possibly on 6 and lose the separation of =tempdb. Of course this will lose you some space over the raid 5, but =will perform better. Hardware raid vs S/W will alo make a difference. =How much separating tempdb gives you totally depends on the number of =queries generating large temporary results.
Opinions are likely to vary a lot and you haven't given much info to go =on.
Mike John
"Rick" <bob@.bob.net> wrote in message =news:3f858779$0$103$8f4e7992@.newsreader.goldengate.net...
> Assume a heavy transaction environment.
> > Let's say we have the same database model,
> same hardware, file usage, type of data, queries etc. on two servers.
> Server A is configured with a RAID 5 on all the data disks (9 of =them),
> and Server B is configured with RAID 5 on the data disks (5 of them) =but
> transaction log and tempdb is separated to its own mirrored disks (4 =of
> them - 2 each).
> > Which SQL server will run faster in terms of query response time AND =write
> performance? Database in Server A or Server B?
> >|||I completely agree with Mike John's remark to drop RAID5 completely,
certainly for a 'heavy transaction environment' as you describe. Check out
this link for some reasons why
http://www.miracleas.dk/BAARF/BAARF2.html
(OK it's Oracle/Unix, but it is as tru for the SQLServer/Win world too..)
"Mike John" <Mike.John@.knowledgepool.com> wrote in message
news:uRds7fpjDHA.2676@.TK2MSFTNGP11.phx.gbl...
Assumimng disc io is the limiting factor then I would say B would be most
likely to outperform A. But even better would be lose the raid 5 and use 0+1
on 4 discs. or possibly on 6 and lose the separation of tempdb. Of course
this will lose you some space over the raid 5, but will perform better.
Hardware raid vs S/W will alo make a difference. How much separating tempdb
gives you totally depends on the number of queries generating large
temporary results.
Opinions are likely to vary a lot and you haven't given much info to go on.
Mike John
"Rick" <bob@.bob.net> wrote in message
news:3f858779$0$103$8f4e7992@.newsreader.goldengate.net...
> Assume a heavy transaction environment.
> Let's say we have the same database model,
> same hardware, file usage, type of data, queries etc. on two servers.
> Server A is configured with a RAID 5 on all the data disks (9 of them),
> and Server B is configured with RAID 5 on the data disks (5 of them) but
> transaction log and tempdb is separated to its own mirrored disks (4 of
> them - 2 each).
> Which SQL server will run faster in terms of query response time AND write
> performance? Database in Server A or Server B?
>|||On Thu, 9 Oct 2003 11:06:17 -0500, "Rick" <bob@.bob.net> wrote:
>Assume a heavy transaction environment.
> Let's say we have the same database model,
>same hardware, file usage, type of data, queries etc. on two servers.
>Server A is configured with a RAID 5 on all the data disks (9 of them),
>and Server B is configured with RAID 5 on the data disks (5 of them) but
>transaction log and tempdb is separated to its own mirrored disks (4 of
>them - 2 each).
>Which SQL server will run faster in terms of query response time AND write
>performance? Database in Server A or Server B?
Well, like the other guys said, one would probably anticipate B
running a bit faster, but it's also going to depend on how much data
is cached, that is, on RAM size, and just how heavily tempdb gets
used, and for that matter, how heavily the log gets used. If it were
100% simple queries, A might even win, for a more usual mix of 90%
simple queries, 5% complex queries, and 5% highly localized updates,
you're probably close to the break-even point, assuming you're not
running short of disk IO bandwidth or CPU in either case A or case B.
J.

Benefits of 64 bit

I understand that the 64 environment allows more addressable memory.
Are there any additional performance benefits other than possibly those
gained by increased memory addressability?
Assuming the same database running on a 32 bit environment and a 64 bit
environment and applications hitting both environments with the same
work load. Can the 64 bit environment have a higher throughput. For
this hypothetical case let us assume that advantages of having a bigger
proc cache does not help.
cheers
KenHere is an MS enumeration of the advantages:
http://www.microsoft.com/sql/techinfo/whitepapers/advantages-64bit-environment.mspx
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
We've seen a roughly 40% reduction in query times on a 64bit server vs.
its 32bit equivalent (sql2k5 on both). We're using Intel with 64bit
extensions rather than Itanium.
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput.
This does seem to be the case, though you still have to consider disk
IO limitations (assuming you're not storing your entire database in the
increased RAM on your 64bit server).
Although the performance increases are notable, and MS claims the 64bit
version is fully functional and supported, we have had a few trouble
areas with the 64bit version. SSIS seems quirky, along with
OPENDATASOURCE between 64bit and 32bit servers (not that you'd
necessarily want to use that a lot :))
All-in-all, we're not disappointed.
Have fun!
KenJ|||Proc Cache isn't the main consumer of memory which benefits being on 64 bit.
The main beneficiary is the increased data caching capability & this is by
far the most significant single reason for upgrading to 64 bit, at least
from a performance perspective.
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156990437.923057.219500@.i42g2000cwa.googlegroups.com...
>I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||I agree that the main beneficiary of increased memory is the buffer
cache. Even with 32 bit a large amounts of memory could be addresses
through AWE. Which brings up another question, does 64 bit give a
substantial performance boost by eliminating the need for AWE?
KenJ, you mentioned that query performance increased by 40%, was your
32 bit database memory bound? Do u attribute the improvement to higher
buffer hit rate, reduced IO queue length? I would be very interested in
discussing this further if you are willing.
cheers,
ken|||It appears that you are expecting to gain performance going to 64 bit. That
may very well be the case, but it may just turn out not to be case. The
outcome really depends on your workloads. I have seen the same app coming out
with lower throughput on 64 bit than on 32 bit with the same hardware. You
need to test your app to be sure.
Linchi
"raidken@.yahoo.com" wrote:
> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||using 64b instead of AWE provide a small boost.
if you take a look at the TPC.org web site, you'll see some benchmarks.
a 4CPU server provides 206000tpmC using SQL2005 x64 (128Gb of RAM) and
188000 tpmc with SQL 2000 (64Gb of RAM)
so with having 2times the memory on the server provides only a few advantage
and the x64 version is not so helpfull in this case.
in fact, the difference is also at the disk level, to compensate the lack of
memory the SQL 2000 benchmark use 2 time more disks (total of 30TB versus
15TB)
The advantage for small and mid sizebusiness is the ability to share the
server with multiple applications and let SQL Server to manage more memory
without locking this memory.
the AWE option lock the memory and this memory is not available for other
applications, its good for high performance and dedicated servers. But in a
real world 1 server support more then 1 application (the company install RS,
SQL and AS on the same server to reduce the license cost) locking the memory
is not good. In these conditions the x64bits version is really good, all the
server memory is used but not locked and regarding which application is more
on demand then the server balance the memory usage between them.
But for dedicated servers like intensive transactionnal systems the
advantage is small.
but the big changes are in AS2005 and SSIS where the x64bit platform provide
a huge advantage.
and to finish, because there is no difference in the price and for future
compatibility, use x64 version. There is no disadvantage of the x64 platform
versus the x32, so if you have the choice, use it!!!
also 32bits CPUs will quickly disappeared from the market with the price war
between Intel and AMD.
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||There is some degree of overhead associated with AWE infrastructure, but
it's a relatively small part of the picture.
There's also more to compare than simply whether you can address 32Gb via 32
bit AWE or via 64 bit without AWE. For example, the 64 bit version of SQL
Server 2005 Standard Edition 2005 is limited to 32Gb RAM (on Win 2003 EE 64
bit), whilst the 32 bit version of SQL Server 2005 Standard Edition can't
get anywhere near that amount (I'm not sure what the actual amount is, but I
think it might be 4Gb)
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||Hi Linchi
Any chance you can share what type of workload you've identified that
exhibits these characteristics & how this has been measured?
Regards,
Greg Linwood
SQL Server MVP
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...
> It appears that you are expecting to gain performance going to 64 bit.
> That
> may very well be the case, but it may just turn out not to be case. The
> outcome really depends on your workloads. I have seen the same app coming
> out
> with lower throughput on 64 bit than on 32 bit with the same hardware. You
> need to test your app to be sure.
> Linchi
> "raidken@.yahoo.com" wrote:
>> I understand that the 64 environment allows more addressable memory.
>> Are there any additional performance benefits other than possibly those
>> gained by increased memory addressability?
>> Assuming the same database running on a 32 bit environment and a 64 bit
>> environment and applications hitting both environments with the same
>> work load. Can the 64 bit environment have a higher throughput. For
>> this hypothetical case let us assume that advantages of having a bigger
>> proc cache does not help.
>> cheers
>> Ken
>>|||raidken@.yahoo.com wrote:
> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
Putting aside the benefits for a moment, I'd strongly advise checking
for 64-bit availability of components where necessary. I recently got
dragged in to the later stages of a project where this hadn't been done
and had real trouble getting a 64-bit SQL 2005 installation to link
through to an old Informix box. In the end they had to roll it back to
32-bit.|||Greg;
I can't share it publicly. But if you drop me an email.
Linchi
"Greg Linwood" wrote:
> Hi Linchi
> Any chance you can share what type of workload you've identified that
> exhibits these characteristics & how this has been measured?
> Regards,
> Greg Linwood
> SQL Server MVP
> "Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
> news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...
> > It appears that you are expecting to gain performance going to 64 bit.
> > That
> > may very well be the case, but it may just turn out not to be case. The
> > outcome really depends on your workloads. I have seen the same app coming
> > out
> > with lower throughput on 64 bit than on 32 bit with the same hardware. You
> > need to test your app to be sure.
> >
> > Linchi
> >
> > "raidken@.yahoo.com" wrote:
> >
> >> I understand that the 64 environment allows more addressable memory.
> >> Are there any additional performance benefits other than possibly those
> >> gained by increased memory addressability?
> >>
> >> Assuming the same database running on a 32 bit environment and a 64 bit
> >> environment and applications hitting both environments with the same
> >> work load. Can the 64 bit environment have a higher throughput. For
> >> this hypothetical case let us assume that advantages of having a bigger
> >> proc cache does not help.
> >>
> >> cheers
> >>
> >> Ken
> >>
> >>
>
>

Benefits of 64 bit

I understand that the 64 environment allows more addressable memory.
Are there any additional performance benefits other than possibly those
gained by increased memory addressability?
Assuming the same database running on a 32 bit environment and a 64 bit
environment and applications hitting both environments with the same
work load. Can the 64 bit environment have a higher throughput. For
this hypothetical case let us assume that advantages of having a bigger
proc cache does not help.
cheers
KenHere is an MS enumeration of the advantages:
http://www.microsoft.com/sql/techin...nt.msp
x

> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
We've seen a roughly 40% reduction in query times on a 64bit server vs.
its 32bit equivalent (sql2k5 on both). We're using Intel with 64bit
extensions rather than Itanium.

> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput.
This does seem to be the case, though you still have to consider disk
IO limitations (assuming you're not storing your entire database in the
increased RAM on your 64bit server).
Although the performance increases are notable, and MS claims the 64bit
version is fully functional and supported, we have had a few trouble
areas with the 64bit version. SSIS seems quirky, along with
OPENDATASOURCE between 64bit and 32bit servers (not that you'd
necessarily want to use that a lot )
All-in-all, we're not disappointed.
Have fun!
KenJ|||Proc Cache isn't the main consumer of memory which benefits being on 64 bit.
The main beneficiary is the increased data caching capability & this is by
far the most significant single reason for upgrading to 64 bit, at least
from a performance perspective.
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156990437.923057.219500@.i42g2000cwa.googlegroups.com...
>I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||I agree that the main beneficiary of increased memory is the buffer
cache. Even with 32 bit a large amounts of memory could be addresses
through AWE. Which brings up another question, does 64 bit give a
substantial performance boost by eliminating the need for AWE?
KenJ, you mentioned that query performance increased by 40%, was your
32 bit database memory bound? Do u attribute the improvement to higher
buffer hit rate, reduced IO queue length? I would be very interested in
discussing this further if you are willing.
cheers,
ken|||It appears that you are expecting to gain performance going to 64 bit. That
may very well be the case, but it may just turn out not to be case. The
outcome really depends on your workloads. I have seen the same app coming ou
t
with lower throughput on 64 bit than on 32 bit with the same hardware. You
need to test your app to be sure.
Linchi
"raidken@.yahoo.com" wrote:

> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||using 64b instead of AWE provide a small boost.
if you take a look at the TPC.org web site, you'll see some benchmarks.
a 4CPU server provides 206000tpmC using SQL2005 x64 (128Gb of RAM) and
188000 tpmc with SQL 2000 (64Gb of RAM)
so with having 2times the memory on the server provides only a few advantage
and the x64 version is not so helpfull in this case.
in fact, the difference is also at the disk level, to compensate the lack of
memory the SQL 2000 benchmark use 2 time more disks (total of 30TB versus
15TB)
The advantage for small and mid sizebusiness is the ability to share the
server with multiple applications and let SQL Server to manage more memory
without locking this memory.
the AWE option lock the memory and this memory is not available for other
applications, its good for high performance and dedicated servers. But in a
real world 1 server support more then 1 application (the company install RS,
SQL and AS on the same server to reduce the license cost) locking the memory
is not good. In these conditions the x64bits version is really good, all the
server memory is used but not locked and regarding which application is more
on demand then the server balance the memory usage between them.
But for dedicated servers like intensive transactionnal systems the
advantage is small.
but the big changes are in AS2005 and SSIS where the x64bit platform provide
a huge advantage.
and to finish, because there is no difference in the price and for future
compatibility, use x64 version. There is no disadvantage of the x64 platform
versus the x32, so if you have the choice, use it!!!
also 32bits CPUs will quickly disappeared from the market with the price war
between Intel and AMD.
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||There is some degree of overhead associated with AWE infrastructure, but
it's a relatively small part of the picture.
There's also more to compare than simply whether you can address 32Gb via 32
bit AWE or via 64 bit without AWE. For example, the 64 bit version of SQL
Server 2005 Standard Edition 2005 is limited to 32Gb RAM (on Win 2003 EE 64
bit), whilst the 32 bit version of SQL Server 2005 Standard Edition can't
get anywhere near that amount (I'm not sure what the actual amount is, but I
think it might be 4Gb)
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||Hi Linchi
Any chance you can share what type of workload you've identified that
exhibits these characteristics & how this has been measured?
Regards,
Greg Linwood
SQL Server MVP
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...[vbcol=seagreen]
> It appears that you are expecting to gain performance going to 64 bit.
> That
> may very well be the case, but it may just turn out not to be case. The
> outcome really depends on your workloads. I have seen the same app coming
> out
> with lower throughput on 64 bit than on 32 bit with the same hardware. You
> need to test your app to be sure.
> Linchi
> "raidken@.yahoo.com" wrote:
>|||raidken@.yahoo.com wrote:

> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
Putting aside the benefits for a moment, I'd strongly advise checking
for 64-bit availability of components where necessary. I recently got
dragged in to the later stages of a project where this hadn't been done
and had real trouble getting a 64-bit SQL 2005 installation to link
through to an old Informix box. In the end they had to roll it back to
32-bit.|||Greg;
I can't share it publicly. But if you drop me an email.
Linchi
"Greg Linwood" wrote:

> Hi Linchi
> Any chance you can share what type of workload you've identified that
> exhibits these characteristics & how this has been measured?
> Regards,
> Greg Linwood
> SQL Server MVP
> "Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
> news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...
>
>

BEGIN STACK DUMP error in log viewer

Hi

We are having problems with our application that uses SQL Server 2005 in a cluster environment. Sometimes the system stops answering and registers in the log viewer the following error:

=====================================================================

BugCheck Dump

=====================================================================

This file is generated by Microsoft SQL Server

version 9.00.1399.06

upon detection of fatal unexpected error. Please return this file, the query or program that produced the bugcheck, the database and the error log, and any other pertinent information with a Service Request.

Computer type is AT/AT COMPATIBLE.

Bios Version is IBM- 1001

Current time is 16:48:36 12/05/06.

2 Intel x86 level 15, 3600 Mhz processor (s).

Windows NT 5.2 Build 3790 CSD Service Pack 1.

Memory

MemoryLoad = 74%

Total Physical = 3327 MB

Available Physical = 858 MB

Total Page File = 9318 MB

Available Page File = 7058 MB

Total Virtual = 2047 MB

Available Virtual = 274 MB

**Dump thread - spid = 132, PSS = 0x71E09588, EC = 0x71E09590

***Stack Dump being sent to E:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump0178.txt

* *******************************************************************************

*

* BEGIN STACK DUMP:

*12/05/06 16:48:36 spid 132

*

* Location:lckmgr.cpp:10820

* Expression:GetLocalLockPartition () == xactLockInfo->GetLocalLockPartition ()

* SPID:132

* Process ID:2436

*

* Input Buffer 255 bytes -

*?16 00 00 00 12 00 00 00 02 00 01 00 00 00 84 00 00 00

*???dD 01 00 00 00 ff ff 0a 00 02 00 00 00 e7 64 09 09 04 d0

*4dS E L E C T00 34 64 09 20 00 53 00 45 00 4c 00 45 00 43 00 54 00

*TAbleA (*) 20 00 54 00 48 00 69 00 73 00 74 00 6f 00 72 00 69 00

(*) There is a query here that I have excluded in the message

*

*MODULEBASEENDSIZE

* sqlservr0100000002BA7FFF01ba8000

* ntdll7C9100007C9D3FFF000c4000

* kernel327C8000007C90BFFF0010c000

* MSVCR8078130000781CAFFF0009b000

* msvcrt77B9000077BE9FFF0005a000

* MSVCP807C4200007C4A6FFF00087000

* ADVAPI3277D9000077E3DFFF000ae000

* RPCRT477C4000077CDEFFF0009f000

* USER3277F4000077FD1FFF00092000

* GDI3277BF000077C37FFF00048000

* CRYPT32760D000076164FFF00095000

* MSASN1760B0000760C1FFF00012000

* Secur3276E7000076E82FFF00013000

* MSWSOCK71970000719B1FFF00042000

* WS2_3271A5000071A66FFF00017000

* WS2HELP71A4000071A47FFF00008000

* USERENV7684000076904FFF000c5000

* opends60333E0000333E6FFF00007000

* NETAPI3271A9000071AE7FFF00058000

* SHELL327C9E00007D1EAFFF0080b000

* SHLWAPI77EE000077F31FFF00052000

* comctl327736000077462FFF00103000

* EntApi3700000037012FFF00013000

* PSAPI76A9000076A9AFFF0000b000

* WININET779D000077A78FFF000a9000

* OLEAUT3277CF000077D7BFFF0008c000

* ole327751000077643FFF00134000

* instapi4806000048069FFF 0000a000

* CLUSAPI74CF000074D01FFF00012000

* RESUTILS74E0000074E12FFF00013000

* sqlevn704F6100004F7A0FFF00191000

* SQLOS344D0000344D4FFF00005000

* rsaenh680000006802EFFF0002f000

* AUTHZ76B6000076B73FFF00014000

* MSCOREE340C000034104FFF00045000

* msv1_076BB000076BD6FFF00027000

* iphlpapi76C1000076C29FFF0001a000

* kerberos3433000034387FFF00058000

* cryptdll766000007660BFFF0000c000

* schannel7667000076696FFF00027000

* COMRES76F30000770BCFFF0018d000

* XOLEHLP343F0000343F5FFF00006000

* MSDTCPRX3440000034477FFF00078000

* msvcp60780C000078120FFF00061000

* MTXCLU74E5000074E68FFF00019000

* VERSION77B8000077B87FFF00008000

* WSOCK3271A0000071A09FFF0000a000

* DNSAPI76DF000076E1EFFF0002f000

* winrnr76E9000076E96FFF00007000

* WLDAP3276E3000076E5EFFF0002f000

* rasadhlp76EA000076EA7FFF00008000

* hnetcfg36190000361E8FFF00059000

* wshtcpip7193000071937FFF00008000

* security3634000036343FFF00004000

* msfte36A6000036CB7FFF00258000

* dbghelp36D0000036E17FFF00118000

* WINTRUST76AD000076AFAFFF 0002b000

* imagehlp76B3000076B58FFF00029000

* dssenh6810000068123FFF00024000

* NTMARTA777B0000777D1FFF00022000

* SAMLIB36FE000036FEEFFF0000f000

* ntdsapi7661000076624FFF00015000

* xpsp2res61BF000061EBFFFF002d0000

* CLBCatQ77650000776D2FFF00083000

* sqlncli61EC0000620E1FFF00222000

* COMCTL3277E4000077ED6FFF00097000

* comdlg32761D000076218FFF00049000

* SQLNCLIR007C0000007F2FFF00033000

* msftepxy621F000062204FFF00015000

* xpsqlbot6286000062865FFF00006000

* xpstar9062880000628C4FFF00045000

* SQLSCM90628E0000628E8FFF00009000

* ODBC32629000006293CFFF0003d000

* BatchParser90629400006295DFFF0001e000

* SQLSVC906297000062989FFF0001a000

* SqlResourceLoader629A0000629A5FFF00006000

* ATL807C6300007C64AFFF0001b000

* odbcint62B0000062B17FFF00018000

* SQLSVC9062B2000062B22FFF00003000

* xpstar9062B3000062B55FFF00026000

* xplog7062B6000062B6BFFF0000c000

* xplog7062B8000062B82FFF00003000

* oledb32631B000063228FFF00079000

* MSDART6323000063249FFF0001a000

* OLEDB32R634D0000634E1FFF00012000

* activeds76D1000076D42FFF 00033000

* adsldpc76CE000076D06FFF00027000

* credui76AA000076ACDFFF0002e000

* ATL769A0000769B7FFF00018000

* adsldp711100007113DFFF0002e000

* SXS75CB000075D6BFFF000bc000

* dbghelp65D4000065E52FFF00113000

*

*Edi: 6610BCB8:636A19003E3A604062F1A0406610D8AD0279E9003E3A63D8

*Esi: 00000000:

*Eax: 6610BB9C:000042AC00000000000000007C815E02000000007C931B34

*Ebx: 0000003F:

*Ecx: 6610C20C:00000000000100070000000000740072636A19046610BBCC

*Edx: 0000003D:

*Eip: 7C815E02:10C2C95E90909000A164909000000018C334408B891C428B

*Ebp: 6610BBEC:6610BC3002172CE4000042AC000000000000000000000000

*SegCs: 0000001B:

*EFlags: 00000246:

*Esp: 6610BB98:71E09588000042AC00000000000000007C815E0200000000

*SegSs: 78130023:000000000000000000000000000000000000000000000000

* *******************************************************************************

* -

* Short Stack Dump

7C815E02 Module(kernel32+00015E02)

02172CE4 Module(sqlservr+01172CE4)

02176BA0 Module(sqlservr+01176BA0)

02019506 Module(sqlservr+01019506)

015738EE Module(sqlservr+005738EE)

021B15B6 Module(sqlservr+011B15B6)

0163DD36 Module(sqlservr+0063DD36)

010E9FA3 Module(sqlservr+000E9FA3)

010B0F5F Module(sqlservr+000B0F5F)

0102C5F8 Module(sqlservr+0002C5F8)

01BEE12B Module(sqlservr+00BEE12B)

01BF2BCB Module(sqlservr+00BF2BCB)

01BF353D Module(sqlservr+00BF353D)

010438E5 Module(sqlservr+000438E5)

01041C35 Module(sqlservr+00041C35)

0100889F Module(sqlservr+0000889F)

010089C5 Module(sqlservr+000089C5)

010086E7 Module(sqlservr+000086E7)

010D764A Module(sqlservr+000D764A)

010D7B71 Module(sqlservr+000D7B71)

010D746E Module(sqlservr+000D746E)

010D83F0 Module(sqlservr+000D83F0)

781329AA Module(MSVCR80+000029AA)

78132A36 Module(MSVCR80+00002A36)

PSS @.0x71E09588

CSession @.0x71E08278

--

m_spid = 132m_cRef = 12m_rgcRefType[0] = 1

m_rgcRefType[1] = 1m_rgcRefType[2] = 9m_rgcRefType[3] = 1

m_rgcRefType[4] = 0m_rgcRefType[5] = 0m_pmo = 0x71E08040

m_pstackBhfPool = 0x00000000m_dwLoginFlags = 0x03e0m_fBackground = 0

m_fClientRequestConnReset = 0m_fUserProc = -1m_fConnReset = 0

m_fIsConnReset = 0m_fInLogin = 0m_fReplRelease = 0

m_fKill = 0m_ulLoginStamp = 3105683m_eclClient = 5

m_protType = 5m_hHttpToken = FFFFFFFF

m_pV7LoginRec

00000000:18010000 02000972 401f0000 00000006 400c0000 ?.......r@........@....

00000014:00000000 e0030000 00000000 00000000 5e000400 ?................^...

00000028:66000200 6a000000 7a001c00 b2000c00 ca000000 ?f...j...z...........

0000003C:ca001c00 02010000 02010b00 60f120db ad481801 ?............`. ..H..

00000050:00001801 00001801 00000000 0000???????????????..............

CPhysicalConnection @.0x71E08188

-

m_pPhyConn->m_pmo = 0x71E08040m_pPhyConn->m_pNetConn = 0x71E08788m_pPhyConn->m_pConnList = 0x71E08260

m_pPhyConn->m_pSess = 0x71E08278m_pPhyConn->m_fTracked = -1m_pPhyConn->m_cbPacketsize = 8000

m_pPhyConn->m_fMars = 0m_pPhyConn->m_fKill = 0

CBatch @.0x71E08A90

m_pSess = 0x71E08278m_pConn = 0x71E089F0m_cRef = 3

m_rgcRefType[0] = 1m_rgcRefType[1] = 1m_rgcRefType[2] = 1

m_rgcRefType[3] = 0m_rgcRefType[4] = 0m_pTask = 0x006F9D38

EXCEPT (null) @.0x6610B4AC

-

exc_number = 0exc_severity = 0exc_func = 0x023D96B0

Task @.0x006F9D38

-

CPU Ticks used (ms) = 1Task State = 2

WAITINFO_INTERNAL: WaitResource = 0x00000000WAITINFO_INTERNAL: WaitType = 0x0

WAITINFO_INTERNAL: WaitSpinlock = 0x00000000SchedulerId = 0x0

ThreadId = 0x444m_state = 0m_eAbortSev = 0

EC @.0x71E09590

--

spid = 132ecid = 0ec_stat = 0x0

ec_stat2 = 0x40ec_atomic = 0x4__fSubProc = 1

ec_dbccContext = 0x00000000__pSETLS = 0x71E08A30__pSEParams = 0x71E08CD0

__pDbLocks = 0x71E09878

SEInternalTLS @.0x71E08A30

-

m_flags = 0m_TLSstatus = 3m_owningTask = 0x006F9D38

m_activeHeapDatasetList = 0x71E08A30m_activeIndexDatasetList = 0x71E08A38

SEParams @.0x71E08CD0

--

m_lockTimeout = -1m_isoLevel = 1048576m_logDontReplicate = 0

m_neverReplicate = 0m_XactWorkspace = 0x03F78940m_pSessionLocks = 0x71E09A88

m_pDbLocks = 0x71E09878m_execStats = 0x3F867018m_pAllocFileLimit = 0x00000000

Does anybody know what’s going on?

I will be very appreciate if someone can help me to solve this problem. Thank you!

Hi,

We would like to investigate this issue. Can you please file a bug via http://connect.microsoft.com/sql. Please upload SqlDump0178.mdmp and SqlDump0178.txt there as well.

Thanks, Ron D.

|||any luck on this one. We are seeing the same error.

Thanks,
Siva|||

Make sure the table being accessed have proper CLUSTERED index.

BEGIN STACK DUMP error in log viewer

Hi

We are having problems with our application that uses SQL Server 2005 in a cluster environment. Sometimes the system stops answering and registers in the log viewer the following error:

=====================================================================

BugCheck Dump

=====================================================================

This file is generated by Microsoft SQL Server

version 9.00.1399.06

upon detection of fatal unexpected error. Please return this file, the query or program that produced the bugcheck, the database and the error log, and any other pertinent information with a Service Request.

Computer type is AT/AT COMPATIBLE.

Bios Version is IBM- 1001

Current time is 16:48:36 12/05/06.

2 Intel x86 level 15, 3600 Mhz processor (s).

Windows NT 5.2 Build 3790 CSD Service Pack 1.

Memory

MemoryLoad = 74%

Total Physical = 3327 MB

Available Physical = 858 MB

Total Page File = 9318 MB

Available Page File = 7058 MB

Total Virtual = 2047 MB

Available Virtual = 274 MB

**Dump thread - spid = 132, PSS = 0x71E09588, EC = 0x71E09590

***Stack Dump being sent to E:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump0178.txt

* *******************************************************************************

*

* BEGIN STACK DUMP:

*12/05/06 16:48:36 spid 132

*

* Location:lckmgr.cpp:10820

* Expression:GetLocalLockPartition () == xactLockInfo->GetLocalLockPartition ()

* SPID:132

* Process ID:2436

*

* Input Buffer 255 bytes -

*?16 00 00 00 12 00 00 00 02 00 01 00 00 00 84 00 00 00

*???dD 01 00 00 00 ff ff 0a 00 02 00 00 00 e7 64 09 09 04 d0

*4dS E L E C T00 34 64 09 20 00 53 00 45 00 4c 00 45 00 43 00 54 00

*TAbleA (*) 20 00 54 00 48 00 69 00 73 00 74 00 6f 00 72 00 69 00

(*) There is a query here that I have excluded in the message

*

*MODULEBASEENDSIZE

* sqlservr0100000002BA7FFF01ba8000

* ntdll7C9100007C9D3FFF000c4000

* kernel327C8000007C90BFFF0010c000

* MSVCR8078130000781CAFFF0009b000

* msvcrt77B9000077BE9FFF0005a000

* MSVCP807C4200007C4A6FFF00087000

* ADVAPI3277D9000077E3DFFF000ae000

* RPCRT477C4000077CDEFFF0009f000

* USER3277F4000077FD1FFF00092000

* GDI3277BF000077C37FFF00048000

* CRYPT32760D000076164FFF00095000

* MSASN1760B0000760C1FFF00012000

* Secur3276E7000076E82FFF00013000

* MSWSOCK71970000719B1FFF00042000

* WS2_3271A5000071A66FFF00017000

* WS2HELP71A4000071A47FFF00008000

* USERENV7684000076904FFF000c5000

* opends60333E0000333E6FFF00007000

* NETAPI3271A9000071AE7FFF00058000

* SHELL327C9E00007D1EAFFF0080b000

* SHLWAPI77EE000077F31FFF00052000

* comctl327736000077462FFF00103000

* EntApi3700000037012FFF00013000

* PSAPI76A9000076A9AFFF0000b000

* WININET779D000077A78FFF000a9000

* OLEAUT3277CF000077D7BFFF0008c000

* ole327751000077643FFF00134000

* instapi4806000048069FFF 0000a000

* CLUSAPI74CF000074D01FFF00012000

* RESUTILS74E0000074E12FFF00013000

* sqlevn704F6100004F7A0FFF00191000

* SQLOS344D0000344D4FFF00005000

* rsaenh680000006802EFFF0002f000

* AUTHZ76B6000076B73FFF00014000

* MSCOREE340C000034104FFF00045000

* msv1_076BB000076BD6FFF00027000

* iphlpapi76C1000076C29FFF0001a000

* kerberos3433000034387FFF00058000

* cryptdll766000007660BFFF0000c000

* schannel7667000076696FFF00027000

* COMRES76F30000770BCFFF0018d000

* XOLEHLP343F0000343F5FFF00006000

* MSDTCPRX3440000034477FFF00078000

* msvcp60780C000078120FFF00061000

* MTXCLU74E5000074E68FFF00019000

* VERSION77B8000077B87FFF00008000

* WSOCK3271A0000071A09FFF0000a000

* DNSAPI76DF000076E1EFFF0002f000

* winrnr76E9000076E96FFF00007000

* WLDAP3276E3000076E5EFFF0002f000

* rasadhlp76EA000076EA7FFF00008000

* hnetcfg36190000361E8FFF00059000

* wshtcpip7193000071937FFF00008000

* security3634000036343FFF00004000

* msfte36A6000036CB7FFF00258000

* dbghelp36D0000036E17FFF00118000

* WINTRUST76AD000076AFAFFF 0002b000

* imagehlp76B3000076B58FFF00029000

* dssenh6810000068123FFF00024000

* NTMARTA777B0000777D1FFF00022000

* SAMLIB36FE000036FEEFFF0000f000

* ntdsapi7661000076624FFF00015000

* xpsp2res61BF000061EBFFFF002d0000

* CLBCatQ77650000776D2FFF00083000

* sqlncli61EC0000620E1FFF00222000

* COMCTL3277E4000077ED6FFF00097000

* comdlg32761D000076218FFF00049000

* SQLNCLIR007C0000007F2FFF00033000

* msftepxy621F000062204FFF00015000

* xpsqlbot6286000062865FFF00006000

* xpstar9062880000628C4FFF00045000

* SQLSCM90628E0000628E8FFF00009000

* ODBC32629000006293CFFF0003d000

* BatchParser90629400006295DFFF0001e000

* SQLSVC906297000062989FFF0001a000

* SqlResourceLoader629A0000629A5FFF00006000

* ATL807C6300007C64AFFF0001b000

* odbcint62B0000062B17FFF00018000

* SQLSVC9062B2000062B22FFF00003000

* xpstar9062B3000062B55FFF00026000

* xplog7062B6000062B6BFFF0000c000

* xplog7062B8000062B82FFF00003000

* oledb32631B000063228FFF00079000

* MSDART6323000063249FFF0001a000

* OLEDB32R634D0000634E1FFF00012000

* activeds76D1000076D42FFF 00033000

* adsldpc76CE000076D06FFF00027000

* credui76AA000076ACDFFF0002e000

* ATL769A0000769B7FFF00018000

* adsldp711100007113DFFF0002e000

* SXS75CB000075D6BFFF000bc000

* dbghelp65D4000065E52FFF00113000

*

*Edi: 6610BCB8:636A19003E3A604062F1A0406610D8AD0279E9003E3A63D8

*Esi: 00000000:

*Eax: 6610BB9C:000042AC00000000000000007C815E02000000007C931B34

*Ebx: 0000003F:

*Ecx: 6610C20C:00000000000100070000000000740072636A19046610BBCC

*Edx: 0000003D:

*Eip: 7C815E02:10C2C95E90909000A164909000000018C334408B891C428B

*Ebp: 6610BBEC:6610BC3002172CE4000042AC000000000000000000000000

*SegCs: 0000001B:

*EFlags: 00000246:

*Esp: 6610BB98:71E09588000042AC00000000000000007C815E0200000000

*SegSs: 78130023:000000000000000000000000000000000000000000000000

* *******************************************************************************

* -

* Short Stack Dump

7C815E02 Module(kernel32+00015E02)

02172CE4 Module(sqlservr+01172CE4)

02176BA0 Module(sqlservr+01176BA0)

02019506 Module(sqlservr+01019506)

015738EE Module(sqlservr+005738EE)

021B15B6 Module(sqlservr+011B15B6)

0163DD36 Module(sqlservr+0063DD36)

010E9FA3 Module(sqlservr+000E9FA3)

010B0F5F Module(sqlservr+000B0F5F)

0102C5F8 Module(sqlservr+0002C5F8)

01BEE12B Module(sqlservr+00BEE12B)

01BF2BCB Module(sqlservr+00BF2BCB)

01BF353D Module(sqlservr+00BF353D)

010438E5 Module(sqlservr+000438E5)

01041C35 Module(sqlservr+00041C35)

0100889F Module(sqlservr+0000889F)

010089C5 Module(sqlservr+000089C5)

010086E7 Module(sqlservr+000086E7)

010D764A Module(sqlservr+000D764A)

010D7B71 Module(sqlservr+000D7B71)

010D746E Module(sqlservr+000D746E)

010D83F0 Module(sqlservr+000D83F0)

781329AA Module(MSVCR80+000029AA)

78132A36 Module(MSVCR80+00002A36)

PSS @.0x71E09588

CSession @.0x71E08278

--

m_spid = 132m_cRef = 12m_rgcRefType[0] = 1

m_rgcRefType[1] = 1m_rgcRefType[2] = 9m_rgcRefType[3] = 1

m_rgcRefType[4] = 0m_rgcRefType[5] = 0m_pmo = 0x71E08040

m_pstackBhfPool = 0x00000000m_dwLoginFlags = 0x03e0m_fBackground = 0

m_fClientRequestConnReset = 0m_fUserProc = -1m_fConnReset = 0

m_fIsConnReset = 0m_fInLogin = 0m_fReplRelease = 0

m_fKill = 0m_ulLoginStamp = 3105683m_eclClient = 5

m_protType = 5m_hHttpToken = FFFFFFFF

m_pV7LoginRec

00000000:18010000 02000972 401f0000 00000006 400c0000 ?.......r@........@....

00000014:00000000 e0030000 00000000 00000000 5e000400 ?................^...

00000028:66000200 6a000000 7a001c00 b2000c00 ca000000 ?f...j...z...........

0000003C:ca001c00 02010000 02010b00 60f120db ad481801 ?............`. ..H..

00000050:00001801 00001801 00000000 0000???????????????..............

CPhysicalConnection @.0x71E08188

-

m_pPhyConn->m_pmo = 0x71E08040m_pPhyConn->m_pNetConn = 0x71E08788m_pPhyConn->m_pConnList = 0x71E08260

m_pPhyConn->m_pSess = 0x71E08278m_pPhyConn->m_fTracked = -1m_pPhyConn->m_cbPacketsize = 8000

m_pPhyConn->m_fMars = 0m_pPhyConn->m_fKill = 0

CBatch @.0x71E08A90

m_pSess = 0x71E08278m_pConn = 0x71E089F0m_cRef = 3

m_rgcRefType[0] = 1m_rgcRefType[1] = 1m_rgcRefType[2] = 1

m_rgcRefType[3] = 0m_rgcRefType[4] = 0m_pTask = 0x006F9D38

EXCEPT (null) @.0x6610B4AC

-

exc_number = 0exc_severity = 0exc_func = 0x023D96B0

Task @.0x006F9D38

-

CPU Ticks used (ms) = 1Task State = 2

WAITINFO_INTERNAL: WaitResource = 0x00000000WAITINFO_INTERNAL: WaitType = 0x0

WAITINFO_INTERNAL: WaitSpinlock = 0x00000000SchedulerId = 0x0

ThreadId = 0x444m_state = 0m_eAbortSev = 0

EC @.0x71E09590

--

spid = 132ecid = 0ec_stat = 0x0

ec_stat2 = 0x40ec_atomic = 0x4__fSubProc = 1

ec_dbccContext = 0x00000000__pSETLS = 0x71E08A30__pSEParams = 0x71E08CD0

__pDbLocks = 0x71E09878

SEInternalTLS @.0x71E08A30

-

m_flags = 0m_TLSstatus = 3m_owningTask = 0x006F9D38

m_activeHeapDatasetList = 0x71E08A30m_activeIndexDatasetList = 0x71E08A38

SEParams @.0x71E08CD0

--

m_lockTimeout = -1m_isoLevel = 1048576m_logDontReplicate = 0

m_neverReplicate = 0m_XactWorkspace = 0x03F78940m_pSessionLocks = 0x71E09A88

m_pDbLocks = 0x71E09878m_execStats = 0x3F867018m_pAllocFileLimit = 0x00000000

Does anybody know what’s going on?

I will be very appreciate if someone can help me to solve this problem. Thank you!

Hi,

We would like to investigate this issue. Can you please file a bug via http://connect.microsoft.com/sql. Please upload SqlDump0178.mdmp and SqlDump0178.txt there as well.

Thanks, Ron D.

|||any luck on this one. We are seeing the same error.

Thanks,
Siva|||

Make sure the table being accessed have proper CLUSTERED index.

BEGIN STACK DUMP error in log viewer

Hi

We are having problems with our application that uses SQL Server 2005 in a cluster environment. Sometimes the system stops answering and registers in the log viewer the following error:

=====================================================================

BugCheck Dump

=====================================================================

This file is generated by Microsoft SQL Server

version 9.00.1399.06

upon detection of fatal unexpected error. Please return this file, the query or program that produced the bugcheck, the database and the error log, and any other pertinent information with a Service Request.

Computer type is AT/AT COMPATIBLE.

Bios Version is IBM- 1001

Current time is 16:48:36 12/05/06.

2 Intel x86 level 15, 3600 Mhz processor (s).

Windows NT 5.2 Build 3790 CSD Service Pack 1.

Memory

MemoryLoad = 74%

Total Physical = 3327 MB

Available Physical = 858 MB

Total Page File = 9318 MB

Available Page File = 7058 MB

Total Virtual = 2047 MB

Available Virtual = 274 MB

**Dump thread - spid = 132, PSS = 0x71E09588, EC = 0x71E09590

***Stack Dump being sent to E:\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\SQLDump0178.txt

* *******************************************************************************

*

* BEGIN STACK DUMP:

*12/05/06 16:48:36 spid 132

*

* Location:lckmgr.cpp:10820

* Expression:GetLocalLockPartition () == xactLockInfo->GetLocalLockPartition ()

* SPID:132

* Process ID:2436

*

* Input Buffer 255 bytes -

*?16 00 00 00 12 00 00 00 02 00 01 00 00 00 84 00 00 00

*???dD 01 00 00 00 ff ff 0a 00 02 00 00 00 e7 64 09 09 04 d0

*4dS E L E C T00 34 64 09 20 00 53 00 45 00 4c 00 45 00 43 00 54 00

*TAbleA (*) 20 00 54 00 48 00 69 00 73 00 74 00 6f 00 72 00 69 00

(*) There is a query here that I have excluded in the message

*

*MODULEBASEENDSIZE

* sqlservr0100000002BA7FFF01ba8000

* ntdll7C9100007C9D3FFF000c4000

* kernel327C8000007C90BFFF0010c000

* MSVCR8078130000781CAFFF0009b000

* msvcrt77B9000077BE9FFF0005a000

* MSVCP807C4200007C4A6FFF00087000

* ADVAPI3277D9000077E3DFFF000ae000

* RPCRT477C4000077CDEFFF0009f000

* USER3277F4000077FD1FFF00092000

* GDI3277BF000077C37FFF00048000

* CRYPT32760D000076164FFF00095000

* MSASN1760B0000760C1FFF00012000

* Secur3276E7000076E82FFF00013000

* MSWSOCK71970000719B1FFF00042000

* WS2_3271A5000071A66FFF00017000

* WS2HELP71A4000071A47FFF00008000

* USERENV7684000076904FFF000c5000

* opends60333E0000333E6FFF00007000

* NETAPI3271A9000071AE7FFF00058000

* SHELL327C9E00007D1EAFFF0080b000

* SHLWAPI77EE000077F31FFF00052000

* comctl327736000077462FFF00103000

* EntApi3700000037012FFF00013000

* PSAPI76A9000076A9AFFF0000b000

* WININET779D000077A78FFF000a9000

* OLEAUT3277CF000077D7BFFF0008c000

* ole327751000077643FFF00134000

* instapi4806000048069FFF 0000a000

* CLUSAPI74CF000074D01FFF00012000

* RESUTILS74E0000074E12FFF00013000

* sqlevn704F6100004F7A0FFF00191000

* SQLOS344D0000344D4FFF00005000

* rsaenh680000006802EFFF0002f000

* AUTHZ76B6000076B73FFF00014000

* MSCOREE340C000034104FFF00045000

* msv1_076BB000076BD6FFF00027000

* iphlpapi76C1000076C29FFF0001a000

* kerberos3433000034387FFF00058000

* cryptdll766000007660BFFF0000c000

* schannel7667000076696FFF00027000

* COMRES76F30000770BCFFF0018d000

* XOLEHLP343F0000343F5FFF00006000

* MSDTCPRX3440000034477FFF00078000

* msvcp60780C000078120FFF00061000

* MTXCLU74E5000074E68FFF00019000

* VERSION77B8000077B87FFF00008000

* WSOCK3271A0000071A09FFF0000a000

* DNSAPI76DF000076E1EFFF0002f000

* winrnr76E9000076E96FFF00007000

* WLDAP3276E3000076E5EFFF0002f000

* rasadhlp76EA000076EA7FFF00008000

* hnetcfg36190000361E8FFF00059000

* wshtcpip7193000071937FFF00008000

* security3634000036343FFF00004000

* msfte36A6000036CB7FFF00258000

* dbghelp36D0000036E17FFF00118000

* WINTRUST76AD000076AFAFFF 0002b000

* imagehlp76B3000076B58FFF00029000

* dssenh6810000068123FFF00024000

* NTMARTA777B0000777D1FFF00022000

* SAMLIB36FE000036FEEFFF0000f000

* ntdsapi7661000076624FFF00015000

* xpsp2res61BF000061EBFFFF002d0000

* CLBCatQ77650000776D2FFF00083000

* sqlncli61EC0000620E1FFF00222000

* COMCTL3277E4000077ED6FFF00097000

* comdlg32761D000076218FFF00049000

* SQLNCLIR007C0000007F2FFF00033000

* msftepxy621F000062204FFF00015000

* xpsqlbot6286000062865FFF00006000

* xpstar9062880000628C4FFF00045000

* SQLSCM90628E0000628E8FFF00009000

* ODBC32629000006293CFFF0003d000

* BatchParser90629400006295DFFF0001e000

* SQLSVC906297000062989FFF0001a000

* SqlResourceLoader629A0000629A5FFF00006000

* ATL807C6300007C64AFFF0001b000

* odbcint62B0000062B17FFF00018000

* SQLSVC9062B2000062B22FFF00003000

* xpstar9062B3000062B55FFF00026000

* xplog7062B6000062B6BFFF0000c000

* xplog7062B8000062B82FFF00003000

* oledb32631B000063228FFF00079000

* MSDART6323000063249FFF0001a000

* OLEDB32R634D0000634E1FFF00012000

* activeds76D1000076D42FFF 00033000

* adsldpc76CE000076D06FFF00027000

* credui76AA000076ACDFFF0002e000

* ATL769A0000769B7FFF00018000

* adsldp711100007113DFFF0002e000

* SXS75CB000075D6BFFF000bc000

* dbghelp65D4000065E52FFF00113000

*

*Edi: 6610BCB8:636A19003E3A604062F1A0406610D8AD0279E9003E3A63D8

*Esi: 00000000:

*Eax: 6610BB9C:000042AC00000000000000007C815E02000000007C931B34

*Ebx: 0000003F:

*Ecx: 6610C20C:00000000000100070000000000740072636A19046610BBCC

*Edx: 0000003D:

*Eip: 7C815E02:10C2C95E90909000A164909000000018C334408B891C428B

*Ebp: 6610BBEC:6610BC3002172CE4000042AC000000000000000000000000

*SegCs: 0000001B:

*EFlags: 00000246:

*Esp: 6610BB98:71E09588000042AC00000000000000007C815E0200000000

*SegSs: 78130023:000000000000000000000000000000000000000000000000

* *******************************************************************************

* -

* Short Stack Dump

7C815E02 Module(kernel32+00015E02)

02172CE4 Module(sqlservr+01172CE4)

02176BA0 Module(sqlservr+01176BA0)

02019506 Module(sqlservr+01019506)

015738EE Module(sqlservr+005738EE)

021B15B6 Module(sqlservr+011B15B6)

0163DD36 Module(sqlservr+0063DD36)

010E9FA3 Module(sqlservr+000E9FA3)

010B0F5F Module(sqlservr+000B0F5F)

0102C5F8 Module(sqlservr+0002C5F8)

01BEE12B Module(sqlservr+00BEE12B)

01BF2BCB Module(sqlservr+00BF2BCB)

01BF353D Module(sqlservr+00BF353D)

010438E5 Module(sqlservr+000438E5)

01041C35 Module(sqlservr+00041C35)

0100889F Module(sqlservr+0000889F)

010089C5 Module(sqlservr+000089C5)

010086E7 Module(sqlservr+000086E7)

010D764A Module(sqlservr+000D764A)

010D7B71 Module(sqlservr+000D7B71)

010D746E Module(sqlservr+000D746E)

010D83F0 Module(sqlservr+000D83F0)

781329AA Module(MSVCR80+000029AA)

78132A36 Module(MSVCR80+00002A36)

PSS @.0x71E09588

CSession @.0x71E08278

--

m_spid = 132m_cRef = 12m_rgcRefType[0] = 1

m_rgcRefType[1] = 1m_rgcRefType[2] = 9m_rgcRefType[3] = 1

m_rgcRefType[4] = 0m_rgcRefType[5] = 0m_pmo = 0x71E08040

m_pstackBhfPool = 0x00000000m_dwLoginFlags = 0x03e0m_fBackground = 0

m_fClientRequestConnReset = 0m_fUserProc = -1m_fConnReset = 0

m_fIsConnReset = 0m_fInLogin = 0m_fReplRelease = 0

m_fKill = 0m_ulLoginStamp = 3105683m_eclClient = 5

m_protType = 5m_hHttpToken = FFFFFFFF

m_pV7LoginRec

00000000:18010000 02000972 401f0000 00000006 400c0000 ?.......r@........@....

00000014:00000000 e0030000 00000000 00000000 5e000400 ?................^...

00000028:66000200 6a000000 7a001c00 b2000c00 ca000000 ?f...j...z...........

0000003C:ca001c00 02010000 02010b00 60f120db ad481801 ?............`. ..H..

00000050:00001801 00001801 00000000 0000???????????????..............

CPhysicalConnection @.0x71E08188

-

m_pPhyConn->m_pmo = 0x71E08040m_pPhyConn->m_pNetConn = 0x71E08788m_pPhyConn->m_pConnList = 0x71E08260

m_pPhyConn->m_pSess = 0x71E08278m_pPhyConn->m_fTracked = -1m_pPhyConn->m_cbPacketsize = 8000

m_pPhyConn->m_fMars = 0m_pPhyConn->m_fKill = 0

CBatch @.0x71E08A90

m_pSess = 0x71E08278m_pConn = 0x71E089F0m_cRef = 3

m_rgcRefType[0] = 1m_rgcRefType[1] = 1m_rgcRefType[2] = 1

m_rgcRefType[3] = 0m_rgcRefType[4] = 0m_pTask = 0x006F9D38

EXCEPT (null) @.0x6610B4AC

-

exc_number = 0exc_severity = 0exc_func = 0x023D96B0

Task @.0x006F9D38

-

CPU Ticks used (ms) = 1Task State = 2

WAITINFO_INTERNAL: WaitResource = 0x00000000WAITINFO_INTERNAL: WaitType = 0x0

WAITINFO_INTERNAL: WaitSpinlock = 0x00000000SchedulerId = 0x0

ThreadId = 0x444m_state = 0m_eAbortSev = 0

EC @.0x71E09590

--

spid = 132ecid = 0ec_stat = 0x0

ec_stat2 = 0x40ec_atomic = 0x4__fSubProc = 1

ec_dbccContext = 0x00000000__pSETLS = 0x71E08A30__pSEParams = 0x71E08CD0

__pDbLocks = 0x71E09878

SEInternalTLS @.0x71E08A30

-

m_flags = 0m_TLSstatus = 3m_owningTask = 0x006F9D38

m_activeHeapDatasetList = 0x71E08A30m_activeIndexDatasetList = 0x71E08A38

SEParams @.0x71E08CD0

--

m_lockTimeout = -1m_isoLevel = 1048576m_logDontReplicate = 0

m_neverReplicate = 0m_XactWorkspace = 0x03F78940m_pSessionLocks = 0x71E09A88

m_pDbLocks = 0x71E09878m_execStats = 0x3F867018m_pAllocFileLimit = 0x00000000

Does anybody know what’s going on?

I will be very appreciate if someone can help me to solve this problem. Thank you!

Hi,

We would like to investigate this issue. Can you please file a bug via http://connect.microsoft.com/sql. Please upload SqlDump0178.mdmp and SqlDump0178.txt there as well.

Thanks, Ron D.

|||any luck on this one. We are seeing the same error.

Thanks,
Siva

|||Make sure the table being accessed have proper CLUSTERED index.