3G ram for SQL server: February 2012

Saturday, February 25, 2012

64-bit linked server to Sybase

Hi,
From my research, it appears that it is not possible to have a linked server
created in SQL Server 2005 x64 use a 32-bit DSN (i.e. created with a 32 bit
driver). The answer is that I need to create a 64-bit DSN in order to
create a linked server in SQL Server 2005 x64. The problem is that many
vendors (i.e. Sybase) do not have a 64-bit driver.
Looks like our migration is SQL Server 2005 x64 will have to wait unless we
can get this to work with perhaps a third party vendore such as Data Direct.
Any one using Data Direct to connect to Sybase from SQL Server 2005 x64?
Thanks,
Rocco M.
(posted in microsoft.public.sqlserver.odbc,
microsoft.public.sqlserver.clients and microsoft.public.sqlserver.connect)Hi,
I've just ran into the same problem linking to Oracle 8i.
MSDAORA, OraOLEDB.Oracle and ODBC drivers do not work.
64 bit drivers have not been released yet... Any workaround except returning
to sqlserver 32bit?
Davide
"Rocco M" <rocco.mastrangelo@.hp.com> ha scritto nel messaggio
news:AHYeg.1209$cY3.584@.news.cpqcorp.net...
> Hi,
> From my research, it appears that it is not possible to have a linked
> server created in SQL Server 2005 x64 use a 32-bit DSN (i.e. created with
> a 32 bit driver). The answer is that I need to create a 64-bit DSN in
> order to create a linked server in SQL Server 2005 x64. The problem is
> that many vendors (i.e. Sybase) do not have a 64-bit driver.
> Looks like our migration is SQL Server 2005 x64 will have to wait unless
> we can get this to work with perhaps a third party vendore such as Data
> Direct. Any one using Data Direct to connect to Sybase from SQL Server
> 2005 x64?
> Thanks,
> Rocco M.
> (posted in microsoft.public.sqlserver.odbc,
> microsoft.public.sqlserver.clients and microsoft.public.sqlserver.connect)
>

64-bit JET drivers or alternative?

> Running SQL Server 2005 x64 on Windows Server 2003, and I can't use a
> Data Flow Task in SSIS where the destination in an Excel spreadsheet
> because there is no 64-bit JET driver for Excel.
> Is anyone aware of a 64-bit driver now available or any 3rd party
> options? Running the entire package in 32-bit mode is not a
> possibility, so I can't use the DTExec workaround.
You can vote here:
Microsoft Connect > SQL Server: x64 Jet provider
http://connect.microsoft.com/SQLSer...=12511
7

64-bit JET drivers or alternative?

Hi all -
I'm enountering the same problem many have previously reported.
Running SQL Server 2005 x64 on Windows Server 2003, and I can't use a
Data Flow Task in SSIS where the destination in an Excel spreadsheet
because there is no 64-bit JET driver for Excel.
Is anyone aware of a 64-bit driver now available or any 3rd party
options? Running the entire package in 32-bit mode is not a
possibility, so I can't use the DTExec workaround.
Any assistance would be appreciated --
Jamie :)> Running SQL Server 2005 x64 on Windows Server 2003, and I can't use a
> Data Flow Task in SSIS where the destination in an Excel spreadsheet
> because there is no 64-bit JET driver for Excel.
> Is anyone aware of a 64-bit driver now available or any 3rd party
> options? Running the entire package in 32-bit mode is not a
> possibility, so I can't use the DTExec workaround.
You can vote here:
Microsoft Connect > SQL Server: x64 Jet provider
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=125117

64-bit issue

I am running into a strange problem when trying to run my package against 64-bit version of SQL Server 2005.

The package was initially developed with a CTP 2 version of SSIS. It has been running fine against a 32-bit bersion of SQL Server 2000.

I created a new SSIS project, with the release version, and added the package mentioned above. Things still work fine against a 32-bit version of SQL Server 2000. However when I run the same exact package against a 64-bit version it doesn't work correctly.

I am using a flat file connector - to pull data from a text file - and loading the data into a database table. Each time I run against the 64-bit version of SQL Server 2005 the number of nulls - for a particular colum - changes.

In other words, the following query returns different counts each time the package is run - even when the underlying flat file data hasn't changed:

select count(*) from some_table where email_address is null

Any help would be much appreciated!

Scott

I now have more information about the above problem. It appears that this is *not* a 64-bit issue. If I run the package using the CTP 2 version of SSIS, everything is correct on 32 or 64 bit versions of SQL Server.

However, if I take the same package and run it within the RTM version of SSIS, the numbers are not only incorrect...the numbers change with each run of the package!

Note that the flat file data source remains the same.

Is there some issue with taking a package built with CTP 2 and runnig it directly with the RTM version of SSIS?

Thanks,

Scott

|||

Wouldn't do it. I would create the package from scratch. There was no supported upgrade from CTP to Beta (that I am aware of) and that includes the packages.

Based on experience, not only remove any signs of the CTPs, but rebuild any machine that any component of a non RTM version on it. It just removes the possibility of error, and I would suspect if not done invalidate any support.

64-Bit Installation of SQL Server 2005 on AMD Server

I have an 8-Processor AMD CPU box with Windows Server 2003 Enterprise (x64) R2 with SP1 installed.

How do I verify that I am installing the 64-Bit version of SQL Server 2005? I don't see any installer 'options' and when I view the list of SQL Server 2005 components in the Add/Remove program list there is nothing mentioned.

The source of my SQL Server 2005 installation code is the 'Ready Set Launch' DVD that Microsoft handed out when SQL Server 2005 was launched in 11/2005.

I haven't found any documentation to specifically details 64-bit installations.

Thank you.

...cordell...

The media itself must be the 64-bit version of SQL 2005. Since your AMD box will support both 32-bit and 64-bit versions, it's tough to tell what you're installing. After installing, the 64-bit versions have a "(64-bit)" tag on the end of them in Add/Remove Programs. My guess is that you have a copy of the 32-bit version.

Thanks,
Sam Lester (MSFT)

|||

Sam...

From what I can see I am installing the 32-bit versions of the SQL Server 2005 software on the AMD box.

I apologize for being pedantic here.....but I wanted to confirm that I will need to follow back up with my software vendor and order a 64-bit version of SQL Server 2005. (This is what I am concluding from your statements.)

After searching around the SKU I have is 228-05237 for this version...but I couldn't find anything in the SQL Server section of the MS website to confirm it. While I realize you are not in sales...what would the URL be for confirming the SKU on the media.

Thank you.

...cordell...

|||

No problem at all. You will need to contact your software vendor and specifically request the 64-bit version. I don't fully understand the licensing options for every situation, but I think this page will help you find the SKU/item number you are looking for. I have linked the Enterprise SKU's, but you can search for the others as well.

http://www.microsoft.com/PRODUCTS/info/product.aspx?view=22&pcid=d635228e-6aed-404b-9af1-7c27819c24e4&crumb=srch&qu=sql+server&gpid=c419977d-7963-4c38-8caf-95d3f779bed1

Example (make sure you pick the one that applies to you):

Full Version
Microsoft? SQL Server Enterprise Edition 2005 x64 English CD/DVD 25 Client
Item: 810-05188

Let me know if this is what you're looking for.

Thanks,
Sam

|||

Thank you Sam for the confirmation and assistance. That is what I was looking for.

...cordell...

64bit i/o Performance

Hoping someone has some experience with this. I am in the middle of
attempting to migrate over to a 64bit SQL cluster, however have found a
major problem with i/o requests being painfully slow. Slower in fact than
on a 32bit system with less than half the power of the Itanium.
Below is the output from the sp_configure, I'm not seeing anything.
Server info: HP rx7620, 4x1.6GHZ Itanium2 CPU, 32GB RAM, 120GB local
disk, 500GB (multiple luns) XP1024 SAN, running secure path (autopath set
to SQR).
Any thoughts?
Thanks,
Nic
affinity mask-2147483648214748364700
affinity64 mask-2147483648214748364700
allow updates0100
awe enabled0100
c2 audit mode0100
cost threshold for parallelism03276755
Cross DB Ownership Chaining0100
cursor threshold-12147483647-1-1
default full-text language0214748364710331033
default language0999900
fill factor (%)010000
index create memory (KB)704214748364700
lightweight pooling0100
locks5000214748364700
max degree of parallelism03211
max server memory (MB)4214748364721474836472147483647
max text repl size (B)021474836476553665536
max worker threads3232767255255
media retention036500
min memory per query (KB)512214748364710241024
min server memory (MB)0214748364700
nested triggers0111
network packet size (B)5123276740964096
open objects0214748364700
priority boost0100
query governor cost limit0214748364700
query wait (s)-12147483647-1-1
recovery interval (min)03276700
remote access0111
remote login timeout (s)021474836472020
remote proc trans0100
remote query timeout (s)02147483647600600
scan for startup procs0100
set working set size0100
show advanced options0111
two digit year cutoff1753999920492049
user connections03276700
user options0327676464
Nicholas,
We run systems of the this size and larger. Mainly HP as well. When we've
moved from 32 bit to 64bit we've seen large increases in IO throughput.
Average Queue Lengths drop and throughput on the SAN increases.
Do you have a base line of IO on the 32bit system that you can compare to
the 64bit?
The first thing to look at would be are there any hot spots on your disk?
Check for a high average queue length.
What SQL build are you running? The same build numbers in 32bit and 64bit
can have different issues.
It's difficult without more information about your processes but here are a
few suggestions for you to try on your config.
Set the min a min and max memory to about 28GB. More or less depending on
what else you have running.
max DOP is 1? If you don't get blocked schedulers up this or set it to 0.
max worker threads may need to be higher but that depends on the number and
size of the processes.
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96A646766DD6Cnicholascainnospamtm@.207.46.2 48.16...
> Hoping someone has some experience with this. I am in the middle of
> attempting to migrate over to a 64bit SQL cluster, however have found a
> major problem with i/o requests being painfully slow. Slower in fact than
> on a 32bit system with less than half the power of the Itanium.
> Below is the output from the sp_configure, I'm not seeing anything.
> Server info: HP rx7620, 4x1.6GHZ Itanium2 CPU, 32GB RAM, 120GB local
> disk, 500GB (multiple luns) XP1024 SAN, running secure path (autopath set
> to SQR).
>
> Any thoughts?
> Thanks,
> Nic
>
> affinity mask -2147483648 2147483647 0 0
> affinity64 mask -2147483648 2147483647 0 0
> allow updates 0 1 0 0
> awe enabled 0 1 0 0
> c2 audit mode 0 1 0 0
> cost threshold for parallelism 0 32767 5 5
> Cross DB Ownership Chaining 0 1 0 0
> cursor threshold -1 2147483647 -1 -1
> default full-text language 0 2147483647 1033 1033
> default language 0 9999 0 0
> fill factor (%) 0 100 0 0
> index create memory (KB) 704 2147483647 0 0
> lightweight pooling 0 1 0 0
> locks 5000 2147483647 0 0
> max degree of parallelism 0 32 1 1
> max server memory (MB) 4 2147483647 2147483647 2147483647
> max text repl size (B) 0 2147483647 65536 65536
> max worker threads 32 32767 255 255
> media retention 0 365 0 0
> min memory per query (KB) 512 2147483647 1024 1024
> min server memory (MB) 0 2147483647 0 0
> nested triggers 0 1 1 1
> network packet size (B) 512 32767 4096 4096
> open objects 0 2147483647 0 0
> priority boost 0 1 0 0
> query governor cost limit 0 2147483647 0 0
> query wait (s) -1 2147483647 -1 -1
> recovery interval (min) 0 32767 0 0
> remote access 0 1 1 1
> remote login timeout (s) 0 2147483647 20 20
> remote proc trans 0 1 0 0
> remote query timeout (s) 0 2147483647 600 600
> scan for startup procs 0 1 0 0
> set working set size 0 1 0 0
> show advanced options 0 1 1 1
> two digit year cutoff 1753 9999 2049 2049
> user connections 0 32767 0 0
> user options 0 32767 64 64
|||I actually ran some i/o stats outside of SQL and got great performance
(over 6300 io/sec), however when running through SQL this drops off
massively to something around 600 io/sec.
I changed the DOP to 1 to see if that would improve things any (testing a
bulk insert), however it didn't do anything and I was going to change it
back.
As a comparison from the SQL standpoint, I have a 32bit system with 4GB
RAM connected to the same SAN. I'm running a bulk insert with exactly the
same parameters into a database, logically and physically layed out the
same way and it's taking 3.5 minutes to complete the insert on the 32bit
system and well over 5 minutes on the 64bit.
Just doesn't seem right to me, especially when the raw i/o figures (using
iometer) show that we have at least twice the i/o throughput on the 64bit
system.
Nic
"Danny" <someone@.nowhere.com> wrote in
news:c0KHe.9971$Bx5.7552@.trnddc09:

> Nicholas,
> We run systems of the this size and larger. Mainly HP as well. When
> we've moved from 32 bit to 64bit we've seen large increases in IO
> throughput. Average Queue Lengths drop and throughput on the SAN
> increases.
> Do you have a base line of IO on the 32bit system that you can compare
> to the 64bit?
> The first thing to look at would be are there any hot spots on your
> disk? Check for a high average queue length.
> What SQL build are you running? The same build numbers in 32bit and
> 64bit can have different issues.
> It's difficult without more information about your processes but here
> are a few suggestions for you to try on your config.
> Set the min a min and max memory to about 28GB. More or less
> depending on what else you have running.
> max DOP is 1? If you don't get blocked schedulers up this or set it
> to 0. max worker threads may need to be higher but that depends on the
> number and size of the processes.
>

64bit i/o Performance

Hoping someone has some experience with this. I am in the middle of
attempting to migrate over to a 64bit SQL cluster, however have found a
major problem with i/o requests being painfully slow. Slower in fact than
on a 32bit system with less than half the power of the Itanium.
Below is the output from the sp_configure, I'm not seeing anything.
Server info: HP rx7620, 4x1.6GHZ Itanium2 CPU, 32GB RAM, 120GB local
disk, 500GB (multiple luns) XP1024 SAN, running secure path (autopath set
to SQR).
Any thoughts?
Thanks,
Nic
affinity mask -2147483648 2147483647 0 0
affinity64 mask -2147483648 2147483647 0 0
allow updates 0 1 0 0
awe enabled 0 1 0 0
c2 audit mode 0 1 0 0
cost threshold for parallelism 0 32767 5 5
Cross DB Ownership Chaining 0 1 0 0
cursor threshold -1 2147483647 -1 -1
default full-text language 0 2147483647 1033 1033
default language 0 9999 0 0
fill factor (%) 0 100 0 0
index create memory (KB) 704 2147483647 0 0
lightweight pooling 0 1 0 0
locks 5000 2147483647 0 0
max degree of parallelism 0 32 1 1
max server memory (MB) 4 2147483647 2147483647 2147483647
max text repl size (B) 0 2147483647 65536 65536
max worker threads 32 32767 255 255
media retention 0 365 0 0
min memory per query (KB) 512 2147483647 1024 1024
min server memory (MB) 0 2147483647 0 0
nested triggers 0 1 1 1
network packet size (B) 512 32767 4096 4096
open objects 0 2147483647 0 0
priority boost 0 1 0 0
query governor cost limit 0 2147483647 0 0
query wait (s) -1 2147483647 -1 -1
recovery interval (min) 0 32767 0 0
remote access 0 1 1 1
remote login timeout (s) 0 2147483647 20 20
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 600 600
scan for startup procs 0 1 0 0
set working set size 0 1 0 0
show advanced options 0 1 1 1
two digit year cutoff 1753 9999 2049 2049
user connections 0 32767 0 0
user options 0 32767 64 64Nicholas,
We run systems of the this size and larger. Mainly HP as well. When we've
moved from 32 bit to 64bit we've seen large increases in IO throughput.
Average Queue Lengths drop and throughput on the SAN increases.
Do you have a base line of IO on the 32bit system that you can compare to
the 64bit?
The first thing to look at would be are there any hot spots on your disk?
Check for a high average queue length.
What SQL build are you running? The same build numbers in 32bit and 64bit
can have different issues.
It's difficult without more information about your processes but here are a
few suggestions for you to try on your config.
Set the min a min and max memory to about 28GB. More or less depending on
what else you have running.
max DOP is 1? If you don't get blocked schedulers up this or set it to 0.
max worker threads may need to be higher but that depends on the number and
size of the processes.
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96A646766DD6Cnicholascainnospamtm@.207.46.248.16...
> Hoping someone has some experience with this. I am in the middle of
> attempting to migrate over to a 64bit SQL cluster, however have found a
> major problem with i/o requests being painfully slow. Slower in fact than
> on a 32bit system with less than half the power of the Itanium.
> Below is the output from the sp_configure, I'm not seeing anything.
> Server info: HP rx7620, 4x1.6GHZ Itanium2 CPU, 32GB RAM, 120GB local
> disk, 500GB (multiple luns) XP1024 SAN, running secure path (autopath set
> to SQR).
>
> Any thoughts?
> Thanks,
> Nic
>
> affinity mask -2147483648 2147483647 0 0
> affinity64 mask -2147483648 2147483647 0 0
> allow updates 0 1 0 0
> awe enabled 0 1 0 0
> c2 audit mode 0 1 0 0
> cost threshold for parallelism 0 32767 5 5
> Cross DB Ownership Chaining 0 1 0 0
> cursor threshold -1 2147483647 -1 -1
> default full-text language 0 2147483647 1033 1033
> default language 0 9999 0 0
> fill factor (%) 0 100 0 0
> index create memory (KB) 704 2147483647 0 0
> lightweight pooling 0 1 0 0
> locks 5000 2147483647 0 0
> max degree of parallelism 0 32 1 1
> max server memory (MB) 4 2147483647 2147483647 2147483647
> max text repl size (B) 0 2147483647 65536 65536
> max worker threads 32 32767 255 255
> media retention 0 365 0 0
> min memory per query (KB) 512 2147483647 1024 1024
> min server memory (MB) 0 2147483647 0 0
> nested triggers 0 1 1 1
> network packet size (B) 512 32767 4096 4096
> open objects 0 2147483647 0 0
> priority boost 0 1 0 0
> query governor cost limit 0 2147483647 0 0
> query wait (s) -1 2147483647 -1 -1
> recovery interval (min) 0 32767 0 0
> remote access 0 1 1 1
> remote login timeout (s) 0 2147483647 20 20
> remote proc trans 0 1 0 0
> remote query timeout (s) 0 2147483647 600 600
> scan for startup procs 0 1 0 0
> set working set size 0 1 0 0
> show advanced options 0 1 1 1
> two digit year cutoff 1753 9999 2049 2049
> user connections 0 32767 0 0
> user options 0 32767 64 64|||I actually ran some i/o stats outside of SQL and got great performance
(over 6300 io/sec), however when running through SQL this drops off
massively to something around 600 io/sec.
I changed the DOP to 1 to see if that would improve things any (testing a
bulk insert), however it didn't do anything and I was going to change it
back.
As a comparison from the SQL standpoint, I have a 32bit system with 4GB
RAM connected to the same SAN. I'm running a bulk insert with exactly the
same parameters into a database, logically and physically layed out the
same way and it's taking 3.5 minutes to complete the insert on the 32bit
system and well over 5 minutes on the 64bit.
Just doesn't seem right to me, especially when the raw i/o figures (using
iometer) show that we have at least twice the i/o throughput on the 64bit
system.
Nic
"Danny" <someone@.nowhere.com> wrote in
news:c0KHe.9971$Bx5.7552@.trnddc09:
> Nicholas,
> We run systems of the this size and larger. Mainly HP as well. When
> we've moved from 32 bit to 64bit we've seen large increases in IO
> throughput. Average Queue Lengths drop and throughput on the SAN
> increases.
> Do you have a base line of IO on the 32bit system that you can compare
> to the 64bit?
> The first thing to look at would be are there any hot spots on your
> disk? Check for a high average queue length.
> What SQL build are you running? The same build numbers in 32bit and
> 64bit can have different issues.
> It's difficult without more information about your processes but here
> are a few suggestions for you to try on your config.
> Set the min a min and max memory to about 28GB. More or less
> depending on what else you have running.
> max DOP is 1? If you don't get blocked schedulers up this or set it
> to 0. max worker threads may need to be higher but that depends on the
> number and size of the processes.
>

64bit i/o Performance

Hoping someone has some experience with this. I am in the middle of
attempting to migrate over to a 64bit SQL cluster, however have found a
major problem with i/o requests being painfully slow. Slower in fact than
on a 32bit system with less than half the power of the Itanium.
Below is the output from the sp_configure, I'm not seeing anything.
Server info: HP rx7620, 4x1.6GHZ Itanium2 CPU, 32GB RAM, 120GB local
disk, 500GB (multiple luns) XP1024 SAN, running secure path (autopath set
to SQR).
Any thoughts?
Thanks,
Nic
affinity mask -2147483648 2147483647 0 0
affinity64 mask -2147483648 2147483647 0 0
allow updates 0 1 0 0
awe enabled 0 1 0 0
c2 audit mode 0 1 0 0
cost threshold for parallelism 0 32767 5 5
Cross DB Ownership Chaining 0 1 0 0
cursor threshold -1 2147483647 -1 -1
default full-text language 0 2147483647 1033 1033
default language 0 9999 0 0
fill factor (%) 0 100 0 0
index create memory (KB) 704 2147483647 0 0
lightweight pooling 0 1 0 0
locks 5000 2147483647 0 0
max degree of parallelism 0 32 1 1
max server memory (MB) 4 2147483647 2147483647 2147483647
max text repl size (B) 0 2147483647 65536 65536
max worker threads 32 32767 255 255
media retention 0 365 0 0
min memory per query (KB) 512 2147483647 1024 1024
min server memory (MB) 0 2147483647 0 0
nested triggers 0 1 1 1
network packet size (B) 512 32767 4096 4096
open objects 0 2147483647 0 0
priority boost 0 1 0 0
query governor cost limit 0 2147483647 0 0
query wait (s) -1 2147483647 -1 -1
recovery interval (min) 0 32767 0 0
remote access 0 1 1 1
remote login timeout (s) 0 2147483647 20 20
remote proc trans 0 1 0 0
remote query timeout (s) 0 2147483647 600 600
scan for startup procs 0 1 0 0
set working set size 0 1 0 0
show advanced options 0 1 1 1
two digit year cutoff 1753 9999 2049 2049
user connections 0 32767 0 0
user options 0 32767 64 64Nicholas,
We run systems of the this size and larger. Mainly HP as well. When we've
moved from 32 bit to 64bit we've seen large increases in IO throughput.
Average Queue Lengths drop and throughput on the SAN increases.
Do you have a base line of IO on the 32bit system that you can compare to
the 64bit?
The first thing to look at would be are there any hot spots on your disk?
Check for a high average queue length.
What SQL build are you running? The same build numbers in 32bit and 64bit
can have different issues.
It's difficult without more information about your processes but here are a
few suggestions for you to try on your config.
Set the min a min and max memory to about 28GB. More or less depending on
what else you have running.
max DOP is 1? If you don't get blocked schedulers up this or set it to 0.
max worker threads may need to be higher but that depends on the number and
size of the processes.
"Nicholas Cain" <nicholas.cain@.nospam.t-mobile.com> wrote in message
news:Xns96A646766DD6Cnicholascainnospamt
m@.207.46.248.16...
> Hoping someone has some experience with this. I am in the middle of
> attempting to migrate over to a 64bit SQL cluster, however have found a
> major problem with i/o requests being painfully slow. Slower in fact than
> on a 32bit system with less than half the power of the Itanium.
> Below is the output from the sp_configure, I'm not seeing anything.
> Server info: HP rx7620, 4x1.6GHZ Itanium2 CPU, 32GB RAM, 120GB local
> disk, 500GB (multiple luns) XP1024 SAN, running secure path (autopath set
> to SQR).
>
> Any thoughts?
> Thanks,
> Nic
>
> affinity mask -2147483648 2147483647 0 0
> affinity64 mask -2147483648 2147483647 0 0
> allow updates 0 1 0 0
> awe enabled 0 1 0 0
> c2 audit mode 0 1 0 0
> cost threshold for parallelism 0 32767 5 5
> Cross DB Ownership Chaining 0 1 0 0
> cursor threshold -1 2147483647 -1 -1
> default full-text language 0 2147483647 1033 1033
> default language 0 9999 0 0
> fill factor (%) 0 100 0 0
> index create memory (KB) 704 2147483647 0 0
> lightweight pooling 0 1 0 0
> locks 5000 2147483647 0 0
> max degree of parallelism 0 32 1 1
> max server memory (MB) 4 2147483647 2147483647 2147483647
> max text repl size (B) 0 2147483647 65536 65536
> max worker threads 32 32767 255 255
> media retention 0 365 0 0
> min memory per query (KB) 512 2147483647 1024 1024
> min server memory (MB) 0 2147483647 0 0
> nested triggers 0 1 1 1
> network packet size (B) 512 32767 4096 4096
> open objects 0 2147483647 0 0
> priority boost 0 1 0 0
> query governor cost limit 0 2147483647 0 0
> query wait (s) -1 2147483647 -1 -1
> recovery interval (min) 0 32767 0 0
> remote access 0 1 1 1
> remote login timeout (s) 0 2147483647 20 20
> remote proc trans 0 1 0 0
> remote query timeout (s) 0 2147483647 600 600
> scan for startup procs 0 1 0 0
> set working set size 0 1 0 0
> show advanced options 0 1 1 1
> two digit year cutoff 1753 9999 2049 2049
> user connections 0 32767 0 0
> user options 0 32767 64 64|||I actually ran some i/o stats outside of SQL and got great performance
(over 6300 io/sec), however when running through SQL this drops off
massively to something around 600 io/sec.
I changed the DOP to 1 to see if that would improve things any (testing a
bulk insert), however it didn't do anything and I was going to change it
back.
As a comparison from the SQL standpoint, I have a 32bit system with 4GB
RAM connected to the same SAN. I'm running a bulk insert with exactly the
same parameters into a database, logically and physically layed out the
same way and it's taking 3.5 minutes to complete the insert on the 32bit
system and well over 5 minutes on the 64bit.
Just doesn't seem right to me, especially when the raw i/o figures (using
iometer) show that we have at least twice the i/o throughput on the 64bit
system.
Nic
"Danny" <someone@.nowhere.com> wrote in
news:c0KHe.9971$Bx5.7552@.trnddc09:

> Nicholas,
> We run systems of the this size and larger. Mainly HP as well. When
> we've moved from 32 bit to 64bit we've seen large increases in IO
> throughput. Average Queue Lengths drop and throughput on the SAN
> increases.
> Do you have a base line of IO on the 32bit system that you can compare
> to the 64bit?
> The first thing to look at would be are there any hot spots on your
> disk? Check for a high average queue length.
> What SQL build are you running? The same build numbers in 32bit and
> 64bit can have different issues.
> It's difficult without more information about your processes but here
> are a few suggestions for you to try on your config.
> Set the min a min and max memory to about 28GB. More or less
> depending on what else you have running.
> max DOP is 1? If you don't get blocked schedulers up this or set it
> to 0. max worker threads may need to be higher but that depends on the
> number and size of the processes.
>

64-Bit Edition for RS Database

I am attempting to install Reporting Services on a 32-bit application server
with the database on another box running SQL Server 2000 "Enterprise Edition
(64-bit)" . I am receiving the following error:
"This edition of the Report Server Database is not supported on the edition
of SQL Server 2000 you have chosen. Please choose ..."
The version I am attempting to install is "Reporting Services Enterprise
Edition". I've verified in the install window that it is the Enterprise
Edition of Reporting Services that I am trying to install. I have verified
that I can connect to the 64-bit server from my application server and my SQL
Login Account has SysAdmin permissions. I ran the SELECT
SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'),
SERVERPROPERTY ('edition') command that I read in another thread and it
returned the following information:
8.00.760 SP3 Enterprise Edition (64-bit)
I'm suspect that the "Enterprise Edition (64-bit)" is the culprit. Has
anyone installed Reporting Services using 64-bit SQL Server 2000 for the
database repository?
Thanks in advance...Setup will not allow you to install using a 64 bit version of SQL. There
are manual steps you can perform to get this to work, but it would require a
32 bit version of SQL.
1) Install RS pointing to the 32 bit version of SQL.
2) move both the ReportServer DB and the ReportServerTemp DB to the 64 bit
version (I don't know what the exact steps are to move a database from a 32
bit to a 64 bit sql, you would have to investigate this)
3) use rsconfig.exe to point RS to the 64 bit version of the catalog
-Daniel
This posting is provided "AS IS" with no warranties, and confers no rights.
"Malinda Jepsen" <Malinda Jepsen@.discussions.microsoft.com> wrote in message
news:E3DE691A-4A16-46CD-BE89-9964EE0FDCBA@.microsoft.com...
> I am attempting to install Reporting Services on a 32-bit application
server
> with the database on another box running SQL Server 2000 "Enterprise
Edition
> (64-bit)" . I am receiving the following error:
> "This edition of the Report Server Database is not supported on the
edition
> of SQL Server 2000 you have chosen. Please choose ..."
> The version I am attempting to install is "Reporting Services Enterprise
> Edition". I've verified in the install window that it is the Enterprise
> Edition of Reporting Services that I am trying to install. I have
verified
> that I can connect to the 64-bit server from my application server and my
SQL
> Login Account has SysAdmin permissions. I ran the SELECT
> SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'),
> SERVERPROPERTY ('edition') command that I read in another thread and it
> returned the following information:
> 8.00.760 SP3 Enterprise Edition (64-bit)
> I'm suspect that the "Enterprise Edition (64-bit)" is the culprit. Has
> anyone installed Reporting Services using 64-bit SQL Server 2000 for the
> database repository?
> Thanks in advance...|||Finally success!
What I found was that I couldn't pull a database from another install of
Reporting Services. Since I had already installed it in our lab environment
on a 32-bit server, I first tried to attach that database. But when I did
that, Reporting Services thought I wanted to join a web farm. Then when I
tried to install it with the .ini file with SQL authentication to create the
database (RSSETUPACCOUNT/RSSETUPPASSWORD), it was not creating the database
(even though the SQL user I was using had SysAdmin permissions). I finally
gave my NT account SysAdmin rights and then it would create the database
(using the default install without an .ini file). Once that was complete,
sure enough, I could just move it to the 64-bit server (using standard
detach/attach). One final step was to give the SQL (or NT) user permissions
in the database (I started with datareader and datawriter).
"Daniel Reib [MSFT]" wrote:
> Setup will not allow you to install using a 64 bit version of SQL. There
> are manual steps you can perform to get this to work, but it would require a
> 32 bit version of SQL.
> 1) Install RS pointing to the 32 bit version of SQL.
> 2) move both the ReportServer DB and the ReportServerTemp DB to the 64 bit
> version (I don't know what the exact steps are to move a database from a 32
> bit to a 64 bit sql, you would have to investigate this)
> 3) use rsconfig.exe to point RS to the 64 bit version of the catalog
>
> --
> -Daniel
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "Malinda Jepsen" <Malinda Jepsen@.discussions.microsoft.com> wrote in message
> news:E3DE691A-4A16-46CD-BE89-9964EE0FDCBA@.microsoft.com...
> > I am attempting to install Reporting Services on a 32-bit application
> server
> > with the database on another box running SQL Server 2000 "Enterprise
> Edition
> > (64-bit)" . I am receiving the following error:
> > "This edition of the Report Server Database is not supported on the
> edition
> > of SQL Server 2000 you have chosen. Please choose ..."
> >
> > The version I am attempting to install is "Reporting Services Enterprise
> > Edition". I've verified in the install window that it is the Enterprise
> > Edition of Reporting Services that I am trying to install. I have
> verified
> > that I can connect to the 64-bit server from my application server and my
> SQL
> > Login Account has SysAdmin permissions. I ran the SELECT
> > SERVERPROPERTY('productversion'), SERVERPROPERTY ('productlevel'),
> > SERVERPROPERTY ('edition') command that I read in another thread and it
> > returned the following information:
> > 8.00.760 SP3 Enterprise Edition (64-bit)
> >
> > I'm suspect that the "Enterprise Edition (64-bit)" is the culprit. Has
> > anyone installed Reporting Services using 64-bit SQL Server 2000 for the
> > database repository?
> >
> > Thanks in advance...
>
>

64-Bit Connectivity Issues

We are migrating from a botched 64-bit SQL Server setup to a new 64-bit SQL Server Setup (One instance versus 2). Things that worked on the first server, don't work on the new. My speculation is that the AS400 drivers installation is botched, but asking for feedback.

Am running a scheduled job that simply executes an SSIS package. There is a package configuration for the connection strings to AS400 and SQL Server. The package runs fine when you run it from DTEXECUI (obviously adding configuration file to run). The job is setup exactly the same as on the original server but gets the following errors:

Side question: Why does the job history errors conflict with the SQL Server logging from the package? Very frustrating.

Job History Error (I found these to be very inaccurate in the past):

Executed as user: bfusa\mfgsql. ...rsion 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:45:06 AM Error: 2007-04-11 09:45:06.76 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2007-04-11 09:45:06.78 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Progress: 2007-04-11 09:45:16.34 Source: DFT_PESGRVSL Validating: 0% complete En... The package execution fa... The step failed.

SQL Server Package Logging:

System.InvalidOperationException: The 'IBMDA400.DataSource.1' provider is not registered on the local machine.

BTW, I tried using a cmdexec step to force it run in 32-bit mode, and still received errors. If it is in fact a driver error, why does it run fine in DTEXECUI? I know that always runs in 32-bit mode, but I tried to force a 32-bit mode also.

This might not be the answer but for that error "The system cannot find the file specified." on 64-bit I've opened the package, recompiled all my scripts, saved and ran again and it fixed it. This seems to happen less often in SP2 (or at least in SP2 you will get a warning in 32-bit mode that it is missing a binary for a script).

Based on the rest of your error message its probably not the correct answer but it can't hurt

|||

Two issues here.

1. 32 bit vs. 64 bit package execution

The job history pasted in the message shows that the job is /was running under 64 bit. But even when that is fixed to run under 32 bit (as you apparently did in a cmdexec step) , the execution would still not initiate because of the Package Protection level property setting, which is the second issue. As to the 32 vs 64 bit package execution via dtexec, here's what is displayed when running the two versions of dtexec.exe on the x64 platform (and you can see that the job history shows a 64 bit execution attempt).

"%ProgramFiles(x86)%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 32-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

At least one of the DTS, SQL, or File options must be specified.

"%ProgramFiles%\Microsoft SQL Server\90\DTS\Binn\dtexec.exe"
Microsoft (R) SQL Server Execute Package Utility
Version 9.00.3042.00 for 64-bit
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

At least one of the DTS, SQL, or File options must be specified.

That history shows it is running under 64 bit.

2. Package protection level

Even though you modified it to run in 32 bit mode, there are still errors. These have nothing to do with that platform, but rather, the PackageProtectionLevel. This issue is discussed ( with resolutions) in the following article: http://support.microsoft.com/kb/918760

|||A reinstallation of the DB2 drivers was done and this fixed the issue.

64-Bit Connectivity Issues

Side question: Why does the job history errors conflict with the SQL Server logging from the package? Very frustrating.

Job History Error (I found these to be very inaccurate in the past):

Executed as user: bfusa\mfgsql. ...rsion 9.00.3042.00 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 9:45:06 AM Error: 2007-04-11 09:45:06.76 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Error: 2007-04-11 09:45:06.78 Code: 0xC0016016 Source: Description: Failed to decrypt protected XML node "DTSassword" with error 0x80070002 "The system cannot find the file specified.". You may not be authorized to access this information. This error occurs when there is a cryptographic error. Verify that the correct key is available. End Error Progress: 2007-04-11 09:45:16.34 Source: DFT_PESGRVSL Validating: 0% complete En... The package execution fa... The step failed.

SQL Server Package Logging:

System.InvalidOperationException: The 'IBMDA400.DataSource.1' provider is not registered on the local machine.

Based on the rest of your error message its probably not the correct answer but it can't hurt

|||

Two issues here.

1. 32 bit vs. 64 bit package execution

At least one of the DTS, SQL, or File options must be specified.

That history shows it is running under 64 bit.

2. Package protection level

|||A reinstallation of the DB2 drivers was done and this fixed the issue.

64-bit and SQL Server

If I want to use SQL Server and 64-bit, do I need
Enterprise Edition or can I use it ony SQL Server SE?AFAIK, then you buy 64 bit, the only edition available is 64 bit.
--
Tibor Karaszi
"Paul Z" <paulz_ibm@.msn.com> wrote in message
news:0f3301c3a3ac$fa1b9580$a401280a@.phx.gbl...
> If I want to use SQL Server and 64-bit, do I need
> Enterprise Edition or can I use it ony SQL Server SE?|||That should have been:
AFAIK, then you buy 64 bit, the only edition available is Enterprise
Edition.
Tibor Karaszi
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:ij8qb.36638$dP1.122710@.newsc.telia.net...
> AFAIK, then you buy 64 bit, the only edition available is 64 bit.
> --
> Tibor Karaszi
>
> "Paul Z" <paulz_ibm@.msn.com> wrote in message
> news:0f3301c3a3ac$fa1b9580$a401280a@.phx.gbl...
> > If I want to use SQL Server and 64-bit, do I need
> > Enterprise Edition or can I use it ony SQL Server SE?
>

64bit and performance counters

Based on my knowledge, it will be suitable for your 64bit SQL Server as you
could find the following information in the KB
The information in this article applies to:
Microsoft SQL Server 2000 (all editions) SP3
You could contact PSS as KB told to ask for a hotfix

If the hotfix
doesn't resolve your issue, your issue may be not share the same root cause
as fixed in KB: 812915. In this way, I will be glad to continue our
troubleshooting until it is resolved

Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Are you sure that the Hotfix will work for 64bit?
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:YhgxzlmWEHA.3484@.cpmsftngxa10.phx.gbl...
> Hi Frankm,
> From your descriptions, I understood that you would like to the fix in
> KB:812915 will be possible for your performance counter issue. Have I
> understood you? If there is anything I misunderstood, please feel free to
> let me know

> Based on my knowledge, it will be suitable for your 64bit SQL Server as
you
> could find the following information in the KB
> ----
> The information in this article applies to:
> Microsoft SQL Server 2000 (all editions) SP3
> ----
> You could contact PSS as KB told to ask for a hotfix

If the hotfix
> doesn't resolve your issue, your issue may be not share the same root
cause
> as fixed in KB: 812915. In this way, I will be glad to continue our
> troubleshooting until it is resolved

>
> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi frankm,
I am sure that hotfix will work for 64bit SQL Server

Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!
|||Thank you - I will attempt to apply the patch.
Thank you again ...
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:XE7dHSYXEHA.308@.cpmsftngxa10.phx.gbl...
> Hi frankm,
> I am sure that hotfix will work for 64bit SQL Server

> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Thank you - I will attempt to apply the patch.
Thank you again ...
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:XE7dHSYXEHA.308@.cpmsftngxa10.phx.gbl...
> Hi frankm,
> I am sure that hotfix will work for 64bit SQL Server

> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>
|||Hi Frankm,
Thanks for your prompt updates!
You could post back the result after applying the patches to Re-Open this
thread if the patch doesn't work for you. In this case, you issue might be
another root causes that has no relationship with KB: 812915 and it is
highly appreciated if you could create a new thread so that we could
troubleshooting this issue for you

Anyway, thanks for using MSDN Newsgroup! We are here to be of assistance
whenever you have problems!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

64bit and performance counters

Does anyone know if the hotfix mentioned in KB article 812915
[FIX: "Performance Monitor Shared Memory Setup Failed: -1" Error Message
When You Start SQL Server]
is the same for 64bit as for 32bit, my first guess is no - but I have to
ask.
We just installed 64bit SQL Server 2 weeks ago and now the performace
counters are gone and the above "-1" message shows up in the SQL Server
errolog. This looks exactly like the same problem we encountered with 32
bit.
Thanks,
FrankmHi Frankm,
From your descriptions, I understood that you would like to the fix in
KB:812915 will be possible for your performance counter issue. Have I
understood you? If there is anything I misunderstood, please feel free to
let me know:)
Based on my knowledge, it will be suitable for your 64bit SQL Server as you
could find the following information in the KB
----
The information in this article applies to:
Microsoft SQL Server 2000 (all editions) SP3
----
You could contact PSS as KB told to ask for a hotfix :) If the hotfix
doesn't resolve your issue, your issue may be not share the same root cause
as fixed in KB: 812915. In this way, I will be glad to continue our
troubleshooting until it is resolved :)
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!|||Are you sure that the Hotfix will work for 64bit?
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:YhgxzlmWEHA.3484@.cpmsftngxa10.phx.gbl...
> Hi Frankm,
> From your descriptions, I understood that you would like to the fix in
> KB:812915 will be possible for your performance counter issue. Have I
> understood you? If there is anything I misunderstood, please feel free to
> let me know:)
> Based on my knowledge, it will be suitable for your 64bit SQL Server as
you
> could find the following information in the KB
> ----
> The information in this article applies to:
> Microsoft SQL Server 2000 (all editions) SP3
> ----
> You could contact PSS as KB told to ask for a hotfix :) If the hotfix
> doesn't resolve your issue, your issue may be not share the same root
cause
> as fixed in KB: 812915. In this way, I will be glad to continue our
> troubleshooting until it is resolved :)
>
> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> ---
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>|||Hi frankm,
I am sure that hotfix will work for 64bit SQL Server :)
Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!|||Thank you - I will attempt to apply the patch.
Thank you again ...
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in message
news:XE7dHSYXEHA.308@.cpmsftngxa10.phx.gbl...
> Hi frankm,
> I am sure that hotfix will work for 64bit SQL Server :)
> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> ---
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>|||Hi Frankm,
Thanks for your prompt updates!
You could post back the result after applying the patches to Re-Open this
thread if the patch doesn't work for you. In this case, you issue might be
another root causes that has no relationship with KB: 812915 and it is
highly appreciated if you could create a new thread so that we could
troubleshooting this issue for you :)
Anyway, thanks for using MSDN Newsgroup! We are here to be of assistance
whenever you have problems!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

64bit and performance counters

Based on my knowledge, it will be suitable for your 64bit SQL Server as you
could find the following information in the KB
----
The information in this article applies to:
Microsoft SQL Server 2000 (all editions) SP3
----
You could contact PSS as KB told to ask for a hotfix

If the hotfix
doesn't resolve your issue, your issue may be not share the same root cause
as fixed in KB: 812915. In this way, I will be glad to continue our
troubleshooting until it is resolved

Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!|||Are you sure that the Hotfix will work for 64bit?
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in messa
ge
news:YhgxzlmWEHA.3484@.cpmsftngxa10.phx.gbl...
> Hi Frankm,
> From your descriptions, I understood that you would like to the fix in
> KB:812915 will be possible for your performance counter issue. Have I
> understood you? If there is anything I misunderstood, please feel free to
> let me know

>
> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> ---
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>|||Hi frankm,
I am sure that hotfix will work for 64bit SQL Server

Thank you for your patience and cooperation. If you have any questions or
concerns, don't hesitate to let me know. We are here to be of assistance!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!|||Thank you - I will attempt to apply the patch.
Thank you again ...
""Mingqing Cheng [MSFT]"" <v-mingqc@.online.microsoft.com> wrote in messa
ge
news:XE7dHSYXEHA.308@.cpmsftngxa10.phx.gbl...
> Hi frankm,
> I am sure that hotfix will work for 64bit SQL Server

> Thank you for your patience and cooperation. If you have any questions or
> concerns, don't hesitate to let me know. We are here to be of assistance!
>
> Sincerely yours,
> Mingqing Cheng
> Microsoft Developer Community Support
> ---
> Introduction to Yukon! - http://www.microsoft.com/sql/yukon
> This posting is provided "as is" with no warranties and confers no rights.
> Please reply to newsgroups only, many thanks!
>|||Hi Frankm,
Thanks for your prompt updates!
You could post back the result after applying the patches to Re-Open this
thread if the patch doesn't work for you. In this case, you issue might be
another root causes that has no relationship with KB: 812915 and it is
highly appreciated if you could create a new thread so that we could
troubleshooting this issue for you

Anyway, thanks for using MSDN Newsgroup! We are here to be of assistance
whenever you have problems!
Sincerely yours,
Mingqing Cheng
Microsoft Developer Community Support
---
Introduction to Yukon! - http://www.microsoft.com/sql/yukon
This posting is provided "as is" with no warranties and confers no rights.
Please reply to newsgroups only, many thanks!

64bit and compatability mode

Is it possible to run SQL 2005 64bit in compatability mode?
We have one Database that will only run under SQL2000, but we want to know
whwther we can put it on a 64bit SQL2005 server
Thanks!
--
Ulli Patzer
Systems Administrator
NYCAbsolutely, there is not difference in that regard between 32 and 64 bit.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"Ulli" <ulli_patzer.msn.com@.youknowhowtochangethis> wrote in message
news:BCB6604F-7DB4-4976-B832-EAA181FCDD67@.microsoft.com...
> Is it possible to run SQL 2005 64bit in compatability mode?
> We have one Database that will only run under SQL2000, but we want to know
> whwther we can put it on a 64bit SQL2005 server
> Thanks!
> --
> Ulli Patzer
> Systems Administrator
> NYC|||Thank you very much!
--
Ulli Patzer
Systems Administrator
NYC
"Andrew J. Kelly" wrote:
> Absolutely, there is not difference in that regard between 32 and 64 bit.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "Ulli" <ulli_patzer.msn.com@.youknowhowtochangethis> wrote in message
> news:BCB6604F-7DB4-4976-B832-EAA181FCDD67@.microsoft.com...
> > Is it possible to run SQL 2005 64bit in compatability mode?
> >
> > We have one Database that will only run under SQL2000, but we want to know
> > whwther we can put it on a 64bit SQL2005 server
> >
> > Thanks!
> > --
> > Ulli Patzer
> > Systems Administrator
> > NYC
>

64-bit

Hello,
I was wondering what kind of performance increase can I expect if i change
to a 64 bit system running sql server? What kind of problems can i run into
changing to sql 64 bit or only advantages... Are there benchmark tables
available on the internet?
thanks,
Tune-a
> I was wondering what kind of performance increase can I expect if i change
> to a 64 bit system running sql server?
Really depends on what you are doing... not everything is able to take
advantage of the advanced CPUs...
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
|||Which feautures of sql server 2000 are not capable of taking advantage of a
64 bit system?
At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
seconds of inserts (replication) and roundabout 2000 webusers querying both
databases.. We expect a groth of 50% on data inserts and also (at least) 50%
growth of webusers the next 4 months.
We have to make a decision about 'the new solution':
1. buy 2 big machines (32 or 64 bit), one for redundancy
2. buy more 'less expensive' machines and put loadbalancers in front of them
The easiest way is buying the big machines... If we go for that it's
important to know the pro's and con's about 64-bit machines in combination
with sql server...
"Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
news:ONpBx6HMEHA.268@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
change
> Really depends on what you are doing... not everything is able to take
> advantage of the advanced CPUs...
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
|||Tuna
I have been testing SQL Server performance on 64 bit in our company for over
two months
Look, try to perfom a large transactions especially if you are going to
deal with lots of INSERT's.To make the story shorten,
personally I did not get a feeeling that we should go with it. Almost the
same response time on the client site,
aslo when I backuped a database (15 gb) i was expected at least to speed up
the procsess on 64-bit but it was really the time. So as Aaaron says
:"Really depends on what you are doing... not everything is able to take
advantage of the advanced CPUs..."
"Tuna" <hier@.onetwotres.123> wrote in message
news:#bEiFJIMEHA.2500@.TK2MSFTNGP12.phx.gbl...
> Which feautures of sql server 2000 are not capable of taking advantage of
a
> 64 bit system?
> At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
> seconds of inserts (replication) and roundabout 2000 webusers querying
both
> databases.. We expect a groth of 50% on data inserts and also (at least)
50%
> growth of webusers the next 4 months.
> We have to make a decision about 'the new solution':
> 1. buy 2 big machines (32 or 64 bit), one for redundancy
> 2. buy more 'less expensive' machines and put loadbalancers in front of
them
> The easiest way is buying the big machines... If we go for that it's
> important to know the pro's and con's about 64-bit machines in combination
> with sql server...
>
> "Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
> news:ONpBx6HMEHA.268@.TK2MSFTNGP11.phx.gbl...
> change
>
|||"Tuna" <hier@.onetwotres.123> wrote in message
news:#bEiFJIMEHA.2500@.TK2MSFTNGP12.phx.gbl...

> Which feautures of sql server 2000 are not capable of taking advantage of
a
> 64 bit system?
> At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
> seconds of inserts (replication) and roundabout 2000 webusers querying
both
> databases.. We expect a groth of 50% on data inserts and also (at least)
50%
> growth of webusers the next 4 months.
> We have to make a decision about 'the new solution':
> 1. buy 2 big machines (32 or 64 bit), one for redundancy
> 2. buy more 'less expensive' machines and put loadbalancers in front of
them
> The easiest way is buying the big machines... If we go for that it's
> important to know the pro's and con's about 64-bit machines in combination
> with sql server...
you've made a few comments about what's going though the pipe but you
haven't said if there's a problem with it and, assuming there is a problem,
what you have found about where the problem may lie
the short story is there is not enough information here to consider the need
for 64 bit ... fwiw, my nose tells me that you probably do not need it ...
read the TPC benchmarks, flesh out the analysis; it's a completely empirical
problem
|||"Tuna" <hier@.onetwotres.123> wrote in message
news:OTNlD0HMEHA.3332@.TK2MSFTNGP10.phx.gbl...
> I was wondering what kind of performance increase can I expect if i change
> to a 64 bit system running sql server?
The main difference with 64bit is that SQL Server can directly access more
than 4GB of RAM.
So if you need more than 4GB of RAM then go for 64bit, otherwise consider
carefully where you should go for 64bit processors or would improving some
other aspect of your server spec be of more benefit, e.g. faster disks

64-bit

Hello,
I was wondering what kind of performance increase can I expect if i change
to a 64 bit system running sql server? What kind of problems can i run into
changing to sql 64 bit or only advantages... Are there benchmark tables
available on the internet?
thanks,
Tune-a> I was wondering what kind of performance increase can I expect if i change
> to a 64 bit system running sql server?
Really depends on what you are doing... not everything is able to take
advantage of the advanced CPUs...
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/|||Which feautures of sql server 2000 are not capable of taking advantage of a
64 bit system?
At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
seconds of inserts (replication) and roundabout 2000 webusers querying both
databases.. We expect a groth of 50% on data inserts and also (at least) 50%
growth of webusers the next 4 months.
We have to make a decision about 'the new solution':
1. buy 2 big machines (32 or 64 bit), one for redundancy
2. buy more 'less expensive' machines and put loadbalancers in front of them
The easiest way is buying the big machines... If we go for that it's
important to know the pro's and con's about 64-bit machines in combination
with sql server...
"Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
news:ONpBx6HMEHA.268@.TK2MSFTNGP11.phx.gbl...
> > I was wondering what kind of performance increase can I expect if i
change
> > to a 64 bit system running sql server?
> Really depends on what you are doing... not everything is able to take
> advantage of the advanced CPUs...
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>|||Tuna
I have been testing SQL Server performance on 64 bit in our company for over
two months
Look, try to perfom a large transactions especially if you are going to
deal with lots of INSERT's.To make the story shorten,
personally I did not get a feeeling that we should go with it. Almost the
same response time on the client site,
aslo when I backuped a database (15 gb) i was expected at least to speed up
the procsess on 64-bit but it was really the time. So as Aaaron says
:"Really depends on what you are doing... not everything is able to take
advantage of the advanced CPUs..."
"Tuna" <hier@.onetwotres.123> wrote in message
news:#bEiFJIMEHA.2500@.TK2MSFTNGP12.phx.gbl...
> Which feautures of sql server 2000 are not capable of taking advantage of
a
> 64 bit system?
> At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
> seconds of inserts (replication) and roundabout 2000 webusers querying
both
> databases.. We expect a groth of 50% on data inserts and also (at least)
50%
> growth of webusers the next 4 months.
> We have to make a decision about 'the new solution':
> 1. buy 2 big machines (32 or 64 bit), one for redundancy
> 2. buy more 'less expensive' machines and put loadbalancers in front of
them
> The easiest way is buying the big machines... If we go for that it's
> important to know the pro's and con's about 64-bit machines in combination
> with sql server...
>
> "Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
> news:ONpBx6HMEHA.268@.TK2MSFTNGP11.phx.gbl...
> > > I was wondering what kind of performance increase can I expect if i
> change
> > > to a 64 bit system running sql server?
> >
> > Really depends on what you are doing... not everything is able to take
> > advantage of the advanced CPUs...
> >
> > --
> > Aaron Bertrand
> > SQL Server MVP
> > http://www.aspfaq.com/
> >
> >
>|||"Tuna" <hier@.onetwotres.123> wrote in message
news:#bEiFJIMEHA.2500@.TK2MSFTNGP12.phx.gbl...
> Which feautures of sql server 2000 are not capable of taking advantage of
a
> 64 bit system?
> At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
> seconds of inserts (replication) and roundabout 2000 webusers querying
both
> databases.. We expect a groth of 50% on data inserts and also (at least)
50%
> growth of webusers the next 4 months.
> We have to make a decision about 'the new solution':
> 1. buy 2 big machines (32 or 64 bit), one for redundancy
> 2. buy more 'less expensive' machines and put loadbalancers in front of
them
> The easiest way is buying the big machines... If we go for that it's
> important to know the pro's and con's about 64-bit machines in combination
> with sql server...
you've made a few comments about what's going though the pipe but you
haven't said if there's a problem with it and, assuming there is a problem,
what you have found about where the problem may lie
the short story is there is not enough information here to consider the need
for 64 bit ... fwiw, my nose tells me that you probably do not need it ...
read the TPC benchmarks, flesh out the analysis; it's a completely empirical
problem|||"Tuna" <hier@.onetwotres.123> wrote in message
news:OTNlD0HMEHA.3332@.TK2MSFTNGP10.phx.gbl...
> I was wondering what kind of performance increase can I expect if i change
> to a 64 bit system running sql server?
The main difference with 64bit is that SQL Server can directly access more
than 4GB of RAM.
So if you need more than 4GB of RAM then go for 64bit, otherwise consider
carefully where you should go for 64bit processors or would improving some
other aspect of your server spec be of more benefit, e.g. faster disks

64-bit

Hello,
I was wondering what kind of performance increase can I expect if i change
to a 64 bit system running sql server? What kind of problems can i run into
changing to sql 64 bit or only advantages... Are there benchmark tables
available on the internet?
thanks,
Tune-a> I was wondering what kind of performance increase can I expect if i change
> to a 64 bit system running sql server?
Really depends on what you are doing... not everything is able to take
advantage of the advanced CPUs...
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/|||Which feautures of sql server 2000 are not capable of taking advantage of a
64 bit system?
At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
seconds of inserts (replication) and roundabout 2000 webusers querying both
databases.. We expect a groth of 50% on data inserts and also (at least) 50%
growth of webusers the next 4 months.
We have to make a decision about 'the new solution':
1. buy 2 big machines (32 or 64 bit), one for redundancy
2. buy more 'less expensive' machines and put loadbalancers in front of them
The easiest way is buying the big machines... If we go for that it's
important to know the pro's and con's about 64-bit machines in combination
with sql server...
"Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
news:ONpBx6HMEHA.268@.TK2MSFTNGP11.phx.gbl...
change[vbcol=seagreen]
> Really depends on what you are doing... not everything is able to take
> advantage of the advanced CPUs...
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>|||Tuna
I have been testing SQL Server performance on 64 bit in our company for over
two months
Look, try to perfom a large transactions especially if you are going to
deal with lots of INSERT's.To make the story shorten,
personally I did not get a feeeling that we should go with it. Almost the
same response time on the client site,
aslo when I backuped a database (15 gb) i was expected at least to speed up
the procsess on 64-bit but it was really the time. So as Aaaron says
:"Really depends on what you are doing... not everything is able to take
advantage of the advanced CPUs..."
"Tuna" <hier@.onetwotres.123> wrote in message
news:#bEiFJIMEHA.2500@.TK2MSFTNGP12.phx.gbl...
> Which feautures of sql server 2000 are not capable of taking advantage of
a
> 64 bit system?
> At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
> seconds of inserts (replication) and roundabout 2000 webusers querying
both
> databases.. We expect a groth of 50% on data inserts and also (at least)
50%
> growth of webusers the next 4 months.
> We have to make a decision about 'the new solution':
> 1. buy 2 big machines (32 or 64 bit), one for redundancy
> 2. buy more 'less expensive' machines and put loadbalancers in front of
them
> The easiest way is buying the big machines... If we go for that it's
> important to know the pro's and con's about 64-bit machines in combination
> with sql server...
>
> "Aaron Bertrand [MVP]" <aaron@.TRASHaspfaq.com> wrote in message
> news:ONpBx6HMEHA.268@.TK2MSFTNGP11.phx.gbl...
> change
>|||"Tuna" <hier@.onetwotres.123> wrote in message
news:#bEiFJIMEHA.2500@.TK2MSFTNGP12.phx.gbl...

> Which feautures of sql server 2000 are not capable of taking advantage of
a
> 64 bit system?
> At this moment 2 dual 3.2 Ghz (1.5 ram) xeons are handeling 800 kbits per
> seconds of inserts (replication) and roundabout 2000 webusers querying
both
> databases.. We expect a groth of 50% on data inserts and also (at least)
50%
> growth of webusers the next 4 months.
> We have to make a decision about 'the new solution':
> 1. buy 2 big machines (32 or 64 bit), one for redundancy
> 2. buy more 'less expensive' machines and put loadbalancers in front of
them
> The easiest way is buying the big machines... If we go for that it's
> important to know the pro's and con's about 64-bit machines in combination
> with sql server...
you've made a few comments about what's going though the pipe but you
haven't said if there's a problem with it and, assuming there is a problem,
what you have found about where the problem may lie
the short story is there is not enough information here to consider the need
for 64 bit ... fwiw, my nose tells me that you probably do not need it ...
read the TPC benchmarks, flesh out the analysis; it's a completely empirical
problem|||"Tuna" <hier@.onetwotres.123> wrote in message
news:OTNlD0HMEHA.3332@.TK2MSFTNGP10.phx.gbl...
> I was wondering what kind of performance increase can I expect if i change
> to a 64 bit system running sql server?
The main difference with 64bit is that SQL Server can directly access more
than 4GB of RAM.
So if you need more than 4GB of RAM then go for 64bit, otherwise consider
carefully where you should go for 64bit processors or would improving some
other aspect of your server spec be of more benefit, e.g. faster disks

64000 dimension members limit?

I get an error populating a dimension that says that there are over 64000
members.
The dimension only has one level.
Is that a limit, bug or am I doing something wrong?
Thanks in advance,
Philip
Analysis Services has a 64K limit on the number of children that any one
parent can have. Since you have only one level, there is only one parent
(i.e. the ALL member); thus you are running into this problem. You can
either add a level which makes sense to your structure, for example taking
the first 3 characters of the customer name and using it as an intermediate
level, or selecting another field which makes sense, e.g. adding State to
the level above Customer, or you can turn on the Analysis Services automatic
grouping level feature where AS will automatically create a level for you.
BTW: In SQL Server 2005 (Yukon), this limitation is lifted.
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
This posting is provided "AS IS" with no warranties, and confers no rights.
"Philip McComish" <philvmc@.yahoo.com.br> wrote in message
news:u700f4mJFHA.3332@.TK2MSFTNGP15.phx.gbl...
> I get an error populating a dimension that says that there are over 64000
> members.
> The dimension only has one level.
> Is that a limit, bug or am I doing something wrong?
> Thanks in advance,
> Philip
>
|||Dave,
Thanks for the tips. They solved my problem.
Good news about Yukon.
Best regards,
Philip
"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> escreveu na mensagem
news:exZFrPpJFHA.2604@.TK2MSFTNGP15.phx.gbl...
> Analysis Services has a 64K limit on the number of children that any one
> parent can have. Since you have only one level, there is only one parent
> (i.e. the ALL member); thus you are running into this problem. You can
> either add a level which makes sense to your structure, for example taking
> the first 3 characters of the customer name and using it as an
> intermediate
> level, or selecting another field which makes sense, e.g. adding State to
> the level above Customer, or you can turn on the Analysis Services
> automatic
> grouping level feature where AS will automatically create a level for you.
> BTW: In SQL Server 2005 (Yukon), this limitation is lifted.
> --
> Dave Wickert [MSFT]
> dwickert@.online.microsoft.com
> Program Manager
> BI SystemsTeam
> SQL BI Product Unit (Analysis Services)
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Philip McComish" <philvmc@.yahoo.com.br> wrote in message
> news:u700f4mJFHA.3332@.TK2MSFTNGP15.phx.gbl...
>

64000 dimension members limit?

I get an error populating a dimension that says that there are over 64000
members.
The dimension only has one level.
Is that a limit, bug or am I doing something wrong?
Thanks in advance,
PhilipAnalysis Services has a 64K limit on the number of children that any one
parent can have. Since you have only one level, there is only one parent
(i.e. the ALL member); thus you are running into this problem. You can
either add a level which makes sense to your structure, for example taking
the first 3 characters of the customer name and using it as an intermediate
level, or selecting another field which makes sense, e.g. adding State to
the level above Customer, or you can turn on the Analysis Services automatic
grouping level feature where AS will automatically create a level for you.
BTW: In SQL Server 2005 (Yukon), this limitation is lifted.
Dave Wickert [MSFT]
dwickert@.online.microsoft.com
Program Manager
BI SystemsTeam
SQL BI Product Unit (Analysis Services)
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Philip McComish" <philvmc@.yahoo.com.br> wrote in message
news:u700f4mJFHA.3332@.TK2MSFTNGP15.phx.gbl...
> I get an error populating a dimension that says that there are over 64000
> members.
> The dimension only has one level.
> Is that a limit, bug or am I doing something wrong?
> Thanks in advance,
> Philip
>|||Dave,
Thanks for the tips. They solved my problem.
Good news about Yukon.
Best regards,
Philip
"Dave Wickert [MSFT]" <dwickert@.online.microsoft.com> escreveu na mensag
em
news:exZFrPpJFHA.2604@.TK2MSFTNGP15.phx.gbl...
> Analysis Services has a 64K limit on the number of children that any one
> parent can have. Since you have only one level, there is only one parent
> (i.e. the ALL member); thus you are running into this problem. You can
> either add a level which makes sense to your structure, for example taking
> the first 3 characters of the customer name and using it as an
> intermediate
> level, or selecting another field which makes sense, e.g. adding State to
> the level above Customer, or you can turn on the Analysis Services
> automatic
> grouping level feature where AS will automatically create a level for you.
> BTW: In SQL Server 2005 (Yukon), this limitation is lifted.
> --
> Dave Wickert [MSFT]
> dwickert@.online.microsoft.com
> Program Manager
> BI SystemsTeam
> SQL BI Product Unit (Analysis Services)
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "Philip McComish" <philvmc@.yahoo.com.br> wrote in message
> news:u700f4mJFHA.3332@.TK2MSFTNGP15.phx.gbl...
>

64 bits version of SQL Server 2000

Did anyone use the 64 bit version in production with large databases?
Is it a better price/performance than the 32 bits version?
Any information if highly appreciated.
Thanks a lot!> Is it a better price/performance than the 32 bits version?
Sorry, there are far too many variables here for anyone to give a realistic
yes/no answer.
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/|||Let me be more specific:
- it is used for running some stored procedures and calculate bills based on
some algorithm.
- it needs to process over 500,000,000 records from about 5-10 tables.
- the data will be imported/DTSed from files into the tables
- there will not be more than 2-3 users accesing the data
- the output of the process will be 1-2 tables with the result of the
calculation. These two tables will have about 1,000,000 recods together (or
each of them?)
- we need to be able to run the process in less than 1-2 hours
Unfortunately I do not have more than that. The project did not start yet so
we do not know all the details.
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
> > Is it a better price/performance than the 32 bits version?
> Sorry, there are far too many variables here for anyone to give a
realistic
> yes/no answer.
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>|||If your budget is good, you can buy the developer edition of 64 bit, $49 I
believe but you still need a 64 bit server (hence the budget comment). But
basically you would have to test 32 and 64 side by side. Not having seen
the "algorithm" though, this doesn't _seem_ to be somehting a 32 bit
multiprocessor box with good memory can't handle. Good table design, good
indexes, good statistics, and good queries go a LONG WAY.
hth
Eric
"Daniel P." <danutzp1@.hotmail.comU> wrote in message
news:ecWuIi0uDHA.3532@.TK2MSFTNGP11.phx.gbl...
> Let me be more specific:
> - it is used for running some stored procedures and calculate bills based
on
> some algorithm.
> - it needs to process over 500,000,000 records from about 5-10 tables.
> - the data will be imported/DTSed from files into the tables
> - there will not be more than 2-3 users accesing the data
> - the output of the process will be 1-2 tables with the result of the
> calculation. These two tables will have about 1,000,000 recods together
(or
> each of them?)
> - we need to be able to run the process in less than 1-2 hours
> Unfortunately I do not have more than that. The project did not start yet
so
> we do not know all the details.
>
> "Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
> news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
> > > Is it a better price/performance than the 32 bits version?
> >
> > Sorry, there are far too many variables here for anyone to give a
> realistic
> > yes/no answer.
> >
> > --
> > Aaron Bertrand
> > SQL Server MVP
> > http://www.aspfaq.com/
> >
> >
>|||a load and then summary of 500M rows is not something I would characterize
as something a commodity 32-bit server would be able to do in 1-2 hours, but
it does boil down to requirements and design.
"Eric Sabine" <mopar41@.hyottmail.com> wrote in message
news:eKN4Gz0uDHA.1876@.TK2MSFTNGP09.phx.gbl...
> If your budget is good, you can buy the developer edition of 64 bit, $49 I
> believe but you still need a 64 bit server (hence the budget comment).
But
> basically you would have to test 32 and 64 side by side. Not having seen
> the "algorithm" though, this doesn't _seem_ to be somehting a 32 bit
> multiprocessor box with good memory can't handle. Good table design, good
> indexes, good statistics, and good queries go a LONG WAY.
> hth
> Eric
>
> "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> news:ecWuIi0uDHA.3532@.TK2MSFTNGP11.phx.gbl...
> > Let me be more specific:
> > - it is used for running some stored procedures and calculate bills
based
> on
> > some algorithm.
> > - it needs to process over 500,000,000 records from about 5-10 tables.
> > - the data will be imported/DTSed from files into the tables
> > - there will not be more than 2-3 users accesing the data
> > - the output of the process will be 1-2 tables with the result of the
> > calculation. These two tables will have about 1,000,000 recods together
> (or
> > each of them?)
> > - we need to be able to run the process in less than 1-2 hours
> >
> > Unfortunately I do not have more than that. The project did not start
yet
> so
> > we do not know all the details.
> >
> >
> > "Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
> > news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
> > > > Is it a better price/performance than the 32 bits version?
> > >
> > > Sorry, there are far too many variables here for anyone to give a
> > realistic
> > > yes/no answer.
> > >
> > > --
> > > Aaron Bertrand
> > > SQL Server MVP
> > > http://www.aspfaq.com/
> > >
> > >
> >
> >
>|||Thanks everybody for help!
Unfortunately the project is in the inception phase. I only have some pieces
of requirements but no design and of course no code.
I'm pretty good at writing good SQL code and database tuning.
I need to send to my managers a proposal for hardware and software so they
can make the budget for the next year.
"joe chang" <anonymous@.discussions.microsoft.com> wrote in message
news:0b5001c3bb4b$eb1ec730$a501280a@.phx.gbl...
> in a equal # of CPU configuration, Itanium2 should give
> better performance in most applications
> I suspect that Xeon has better table scan performance, but
> have not been able to verify this in a clean test
> environment.
> Itanium2 will also have better performance in high-end
> systems (>4 CPUs)
> also, look at your SQL Server memory utilization, if a
> large chunk of the lower 2 (or 3) GB is being used for
> other than buffer cache, you may benefit from the 64-bit
> address space.
> otherwise, if the vast majority of your memory usage is
> buffer cache, then 32-bit with AWE works ok
> >--Original Message--
> >Did anyone use the 64 bit version in production with
> large databases?
> >
> >Is it a better price/performance than the 32 bits version?
> >
> >Any information if highly appreciated.
> >
> >Thanks a lot!
> >
> >
> >.
> >|||this is interesting
" I suspect that Xeon has better table scan performance"
why do you say that?
"joe chang" <anonymous@.discussions.microsoft.com> wrote in message
news:0b5001c3bb4b$eb1ec730$a501280a@.phx.gbl...
> in a equal # of CPU configuration, Itanium2 should give
> better performance in most applications
> I suspect that Xeon has better table scan performance, but
> have not been able to verify this in a clean test
> environment.
> Itanium2 will also have better performance in high-end
> systems (>4 CPUs)
> also, look at your SQL Server memory utilization, if a
> large chunk of the lower 2 (or 3) GB is being used for
> other than buffer cache, you may benefit from the 64-bit
> address space.
> otherwise, if the vast majority of your memory usage is
> buffer cache, then 32-bit with AWE works ok
> >--Original Message--
> >Did anyone use the 64 bit version in production with
> large databases?
> >
> >Is it a better price/performance than the 32 bits version?
> >
> >Any information if highly appreciated.
> >
> >Thanks a lot!
> >
> >
> >.
> >|||Hi
I believe it would violate the eula if you use the developer edition for a
production system. You should check with your supplier what edition is
needed for your system.
John
"Eric Sabine" <mopar41@.hyottmail.com> wrote in message
news:eKN4Gz0uDHA.1876@.TK2MSFTNGP09.phx.gbl...
> If your budget is good, you can buy the developer edition of 64 bit, $49 I
> believe but you still need a 64 bit server (hence the budget comment).
But
> basically you would have to test 32 and 64 side by side. Not having seen
> the "algorithm" though, this doesn't _seem_ to be somehting a 32 bit
> multiprocessor box with good memory can't handle. Good table design, good
> indexes, good statistics, and good queries go a LONG WAY.
> hth
> Eric
>
> "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> news:ecWuIi0uDHA.3532@.TK2MSFTNGP11.phx.gbl...
> > Let me be more specific:
> > - it is used for running some stored procedures and calculate bills
based
> on
> > some algorithm.
> > - it needs to process over 500,000,000 records from about 5-10 tables.
> > - the data will be imported/DTSed from files into the tables
> > - there will not be more than 2-3 users accesing the data
> > - the output of the process will be 1-2 tables with the result of the
> > calculation. These two tables will have about 1,000,000 recods together
> (or
> > each of them?)
> > - we need to be able to run the process in less than 1-2 hours
> >
> > Unfortunately I do not have more than that. The project did not start
yet
> so
> > we do not know all the details.
> >
> >
> > "Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
> > news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
> > > > Is it a better price/performance than the 32 bits version?
> > >
> > > Sorry, there are far too many variables here for anyone to give a
> > realistic
> > > yes/no answer.
> > >
> > > --
> > > Aaron Bertrand
> > > SQL Server MVP
> > > http://www.aspfaq.com/
> > >
> > >
> >
> >
>|||A quick look on TPC shows that 32 bit systems are better than 64 bits. Sould
I rely on their numbers?
http://www.tpc.org/tpch/results/tpch_price_perf_results.asp?resulttype=noncluster&version=2%
"Daniel P." <danutzp1@.hotmail.comU> wrote in message
news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
> Did anyone use the 64 bit version in production with large databases?
> Is it a better price/performance than the 32 bits version?
> Any information if highly appreciated.
> Thanks a lot!
>|||I do not want to violate any laws so I need a fully licensed-for-production
system.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:fV2Ab.20511$F95.207029457@.news-text.cableinet.net...
> Hi
> I believe it would violate the eula if you use the developer edition for a
> production system. You should check with your supplier what edition is
> needed for your system.
> John
> "Eric Sabine" <mopar41@.hyottmail.com> wrote in message
> news:eKN4Gz0uDHA.1876@.TK2MSFTNGP09.phx.gbl...
> > If your budget is good, you can buy the developer edition of 64 bit, $49
I
> > believe but you still need a 64 bit server (hence the budget comment).
> But
> > basically you would have to test 32 and 64 side by side. Not having
seen
> > the "algorithm" though, this doesn't _seem_ to be somehting a 32 bit
> > multiprocessor box with good memory can't handle. Good table design,
good
> > indexes, good statistics, and good queries go a LONG WAY.
> >
> > hth
> > Eric
> >
> >
> > "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> > news:ecWuIi0uDHA.3532@.TK2MSFTNGP11.phx.gbl...
> > > Let me be more specific:
> > > - it is used for running some stored procedures and calculate bills
> based
> > on
> > > some algorithm.
> > > - it needs to process over 500,000,000 records from about 5-10 tables.
> > > - the data will be imported/DTSed from files into the tables
> > > - there will not be more than 2-3 users accesing the data
> > > - the output of the process will be 1-2 tables with the result of the
> > > calculation. These two tables will have about 1,000,000 recods
together
> > (or
> > > each of them?)
> > > - we need to be able to run the process in less than 1-2 hours
> > >
> > > Unfortunately I do not have more than that. The project did not start
> yet
> > so
> > > we do not know all the details.
> > >
> > >
> > > "Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
> > > news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
> > > > > Is it a better price/performance than the 32 bits version?
> > > >
> > > > Sorry, there are far too many variables here for anyone to give a
> > > realistic
> > > > yes/no answer.
> > > >
> > > > --
> > > > Aaron Bertrand
> > > > SQL Server MVP
> > > > http://www.aspfaq.com/
> > > >
> > > >
> > >
> > >
> >
> >
>|||John, I think it's pretty clear I was telling him to test the 32 against the
64. There is no evaluation version of the 64 bit, you can only get it as
the developer's edition or the full retail.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:fV2Ab.20511$F95.207029457@.news-text.cableinet.net...
> Hi
> I believe it would violate the eula if you use the developer edition for a
> production system. You should check with your supplier what edition is
> needed for your system.
> John
> "Eric Sabine" <mopar41@.hyottmail.com> wrote in message
> news:eKN4Gz0uDHA.1876@.TK2MSFTNGP09.phx.gbl...
> > If your budget is good, you can buy the developer edition of 64 bit, $49
I
> > believe but you still need a 64 bit server (hence the budget comment).
> But
> > basically you would have to test 32 and 64 side by side. Not having
seen
> > the "algorithm" though, this doesn't _seem_ to be somehting a 32 bit
> > multiprocessor box with good memory can't handle. Good table design,
good
> > indexes, good statistics, and good queries go a LONG WAY.
> >
> > hth
> > Eric
> >
> >
> > "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> > news:ecWuIi0uDHA.3532@.TK2MSFTNGP11.phx.gbl...
> > > Let me be more specific:
> > > - it is used for running some stored procedures and calculate bills
> based
> > on
> > > some algorithm.
> > > - it needs to process over 500,000,000 records from about 5-10 tables.
> > > - the data will be imported/DTSed from files into the tables
> > > - there will not be more than 2-3 users accesing the data
> > > - the output of the process will be 1-2 tables with the result of the
> > > calculation. These two tables will have about 1,000,000 recods
together
> > (or
> > > each of them?)
> > > - we need to be able to run the process in less than 1-2 hours
> > >
> > > Unfortunately I do not have more than that. The project did not start
> yet
> > so
> > > we do not know all the details.
> > >
> > >
> > > "Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
> > > news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
> > > > > Is it a better price/performance than the 32 bits version?
> > > >
> > > > Sorry, there are far too many variables here for anyone to give a
> > > realistic
> > > > yes/no answer.
> > > >
> > > > --
> > > > Aaron Bertrand
> > > > SQL Server MVP
> > > > http://www.aspfaq.com/
> > > >
> > > >
> > >
> > >
> >
> >
>|||> A quick look on TPC shows that 32 bit systems are better than 64 bits.
Sould
> I rely on their numbers?
>
http://www.tpc.org/tpch/results/tpch_price_perf_results.asp?resulttype=noncluster&version=2%
Remember that the TPC benchmarks are for very specific applications running
on very specific hardware. Your mileage certainly will vary unless you are
building something similar and are spending the same kind of money on
hardware...
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/|||> I believe it would violate the eula if you use the developer edition for a
> production system.
I think he meant to kick the tires and do some benchmarking, not to save
money in production.
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/|||take a look at the execution plan for your query,
you do not need the full data size, but you should have
more the 100k rows
if the plan shows a hash join or hash match,
then i would highly recommend the 64-bit system,
the hash operator requires intermediate results to be
stored, a 32-bit system can only allocate so much address
space for the working set, after which the hash
performance will take a serious hit
64-bit systems should not be constrained on the ability to
use memory for intermediate results
>--Original Message--
>Let me be more specific:
>- it is used for running some stored procedures and
calculate bills based on
>some algorithm.
>- it needs to process over 500,000,000 records from about
5-10 tables.
>- the data will be imported/DTSed from files into the
tables
>- there will not be more than 2-3 users accesing the data
>- the output of the process will be 1-2 tables with the
result of the
>calculation. These two tables will have about 1,000,000
recods together (or
>each of them?)
>- we need to be able to run the process in less than 1-2
hours
>Unfortunately I do not have more than that. The project
did not start yet so
>we do not know all the details.
>
>"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in
message
>news:Oam%23yb0uDHA.2448@.TK2MSFTNGP12.phx.gbl...
>> > Is it a better price/performance than the 32 bits
version?
>> Sorry, there are far too many variables here for anyone
to give a
>realistic
>> yes/no answer.
>> --
>> Aaron Bertrand
>> SQL Server MVP
>> http://www.aspfaq.com/
>>
>
>.
>|||i know that there is atleast one operation that is much
slower on an Itanium2 system than on a Xeon MP, even
though overall the It2 was faster,
unfortunately, that was a production system, and i could
not get exclusive access to specifically pinpoint which
operation was performing very poorly relative to the Xeon
>--Original Message--
>this is interesting
>" I suspect that Xeon has better table scan performance"
>why do you say that?
>
>"joe chang" <anonymous@.discussions.microsoft.com> wrote
in message
>news:0b5001c3bb4b$eb1ec730$a501280a@.phx.gbl...
>> in a equal # of CPU configuration, Itanium2 should give
>> better performance in most applications
>> I suspect that Xeon has better table scan performance,
but
>> have not been able to verify this in a clean test
>> environment.
>> Itanium2 will also have better performance in high-end
>> systems (>4 CPUs)
>> also, look at your SQL Server memory utilization, if a
>> large chunk of the lower 2 (or 3) GB is being used for
>> other than buffer cache, you may benefit from the 64-bit
>> address space.
>> otherwise, if the vast majority of your memory usage is
>> buffer cache, then 32-bit with AWE works ok
>> >--Original Message--
>> >Did anyone use the 64 bit version in production with
>> large databases?
>> >
>> >Is it a better price/performance than the 32 bits
version?
>> >
>> >Any information if highly appreciated.
>> >
>> >Thanks a lot!
>> >
>> >
>> >.
>> >
>
>.
>|||I guess I will chime in. We are running a 4 way 64bit Unysis ES7000 with
16GB of memory on Windows 2003. We are currently using it for an OLAP
implementation, however the RDBMS is on the server is well. The best
benefit is memory, which we will be bumping up into the 30gigish range soon.
You can dynamically adjust memory over 8GB(do not really need AWE) without
rebooting SQL. When we are loading data into the cubes we can give SQL more
and when aggs are being built in the cube give more to OLAP Services.
Beyond that memory ease, we have not really noticed a great difference. In
alot of aspects it is a pain using SQL 64 bit, due to its lack tools and
bugs we have ran into. We have crashed our 64bit many times with the amount
of data we are trying to punch through(billion +). To give you some hard
numbers from our test using it in an OLTP environment, we traced some daily
activity and we ran the delete, insert, updates for the same anount of time
roughly --
32bit 4 way 8GB memory -- 133 Trans/sec
64bit 4 way 8GB memory -- 613 Trans/sec
32bit 8way 8GB memory -- 493 Trans/sec
"Daniel P." <danutzp1@.hotmail.comU> wrote in message
news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
> Did anyone use the 64 bit version in production with large databases?
> Is it a better price/performance than the 32 bits version?
> Any information if highly appreciated.
> Thanks a lot!
>|||i am not sure which numbers you were looking at,
the best 4P tpc-c for w2k3 + s2k:
it2 1.5G 121k
xeon mp 2.8G 90k
opteron 82k
at >4p, it gets better for It2 relative to Xeon
also, the tpc-c app uses almost all memory for buffer
cache, which works ok for AWE memory
but you will notice that 32-bit SQL Server has a tough
time in tpc-h, which probably better reflect your app
>--Original Message--
>A quick look on TPC shows that 32 bit systems are better
than 64 bits. Sould
>I rely on their numbers?
>http://www.tpc.org/tpch/results/tpch_price_perf_results.as
p?resulttype=noncluster&version=2%
>
>"Daniel P." <danutzp1@.hotmail.comU> wrote in message
>news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
>> Did anyone use the 64 bit version in production with
large databases?
>> Is it a better price/performance than the 32 bits
version?
>> Any information if highly appreciated.
>> Thanks a lot!
>>
>
>.
>|||Finally the kind of answer I was expecting: someone who uses 64 bit every
day.
Thank you very much Kevin!!!
I think I will stick with 32 bit and a lot of memory. I've also notices that
the amount of memory makes a big difference.
BTW: some MS guys came to us about two weeks ago and they said that the OS
(Windows 2000 or Windows 2003) eats up by default 1/2 of the physical
memory. So even if you have 16 GB you only have 8 GB available for the apps
like SQL Server. The rest is reserved for the OS.
This is really strange!!!
They also said this will be changed in Longhorn.
"Kevin Brooks" <jeepnreb@.yahoo.com> wrote in message
news:uISfnT2uDHA.1340@.TK2MSFTNGP09.phx.gbl...
> I guess I will chime in. We are running a 4 way 64bit Unysis ES7000 with
> 16GB of memory on Windows 2003. We are currently using it for an OLAP
> implementation, however the RDBMS is on the server is well. The best
> benefit is memory, which we will be bumping up into the 30gigish range
soon.
> You can dynamically adjust memory over 8GB(do not really need AWE) without
> rebooting SQL. When we are loading data into the cubes we can give SQL
more
> and when aggs are being built in the cube give more to OLAP Services.
> Beyond that memory ease, we have not really noticed a great difference.
In
> alot of aspects it is a pain using SQL 64 bit, due to its lack tools and
> bugs we have ran into. We have crashed our 64bit many times with the
amount
> of data we are trying to punch through(billion +). To give you some hard
> numbers from our test using it in an OLTP environment, we traced some
daily
> activity and we ran the delete, insert, updates for the same anount of
time
> roughly --
> 32bit 4 way 8GB memory -- 133 Trans/sec
> 64bit 4 way 8GB memory -- 613 Trans/sec
> 32bit 8way 8GB memory -- 493 Trans/sec
> "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
> > Did anyone use the 64 bit version in production with large databases?
> >
> > Is it a better price/performance than the 32 bits version?
> >
> > Any information if highly appreciated.
> >
> > Thanks a lot!
> >
> >
>|||Windows does not use that much memory in a typical sql installation. If you
have a 16GB system and you allocate 14 to SQL, SQL will get 14 assuming no
other memory intensive application is running on there.
"Daniel P." <danutzp1@.hotmail.comU> wrote in message
news:u$zCxb3uDHA.3116@.tk2msftngp13.phx.gbl...
> Finally the kind of answer I was expecting: someone who uses 64 bit every
> day.
> Thank you very much Kevin!!!
> I think I will stick with 32 bit and a lot of memory. I've also notices
that
> the amount of memory makes a big difference.
> BTW: some MS guys came to us about two weeks ago and they said that the OS
> (Windows 2000 or Windows 2003) eats up by default 1/2 of the physical
> memory. So even if you have 16 GB you only have 8 GB available for the
apps
> like SQL Server. The rest is reserved for the OS.
> This is really strange!!!
> They also said this will be changed in Longhorn.
>
> "Kevin Brooks" <jeepnreb@.yahoo.com> wrote in message
> news:uISfnT2uDHA.1340@.TK2MSFTNGP09.phx.gbl...
> > I guess I will chime in. We are running a 4 way 64bit Unysis ES7000
with
> > 16GB of memory on Windows 2003. We are currently using it for an OLAP
> > implementation, however the RDBMS is on the server is well. The best
> > benefit is memory, which we will be bumping up into the 30gigish range
> soon.
> > You can dynamically adjust memory over 8GB(do not really need AWE)
without
> > rebooting SQL. When we are loading data into the cubes we can give SQL
> more
> > and when aggs are being built in the cube give more to OLAP Services.
> > Beyond that memory ease, we have not really noticed a great difference.
> In
> > alot of aspects it is a pain using SQL 64 bit, due to its lack tools and
> > bugs we have ran into. We have crashed our 64bit many times with the
> amount
> > of data we are trying to punch through(billion +). To give you some
hard
> > numbers from our test using it in an OLTP environment, we traced some
> daily
> > activity and we ran the delete, insert, updates for the same anount of
> time
> > roughly --
> >
> > 32bit 4 way 8GB memory -- 133 Trans/sec
> > 64bit 4 way 8GB memory -- 613 Trans/sec
> > 32bit 8way 8GB memory -- 493 Trans/sec
> >
> > "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> > news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
> > > Did anyone use the 64 bit version in production with large databases?
> > >
> > > Is it a better price/performance than the 32 bits version?
> > >
> > > Any information if highly appreciated.
> > >
> > > Thanks a lot!
> > >
> > >
> >
> >
>|||Kevin - when you say crash you mean crashing analysis services, right, not
the RDBMS?
"Kevin Brooks" <jeepnreb@.yahoo.com> wrote in message
news:uISfnT2uDHA.1340@.TK2MSFTNGP09.phx.gbl...
> I guess I will chime in. We are running a 4 way 64bit Unysis ES7000 with
> 16GB of memory on Windows 2003. We are currently using it for an OLAP
> implementation, however the RDBMS is on the server is well. The best
> benefit is memory, which we will be bumping up into the 30gigish range
soon.
> You can dynamically adjust memory over 8GB(do not really need AWE) without
> rebooting SQL. When we are loading data into the cubes we can give SQL
more
> and when aggs are being built in the cube give more to OLAP Services.
> Beyond that memory ease, we have not really noticed a great difference.
In
> alot of aspects it is a pain using SQL 64 bit, due to its lack tools and
> bugs we have ran into. We have crashed our 64bit many times with the
amount
> of data we are trying to punch through(billion +). To give you some hard
> numbers from our test using it in an OLTP environment, we traced some
daily
> activity and we ran the delete, insert, updates for the same anount of
time
> roughly --
> 32bit 4 way 8GB memory -- 133 Trans/sec
> 64bit 4 way 8GB memory -- 613 Trans/sec
> 32bit 8way 8GB memory -- 493 Trans/sec
> "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
> > Did anyone use the 64 bit version in production with large databases?
> >
> > Is it a better price/performance than the 32 bits version?
> >
> > Any information if highly appreciated.
> >
> > Thanks a lot!
> >
> >
>|||> BTW: some MS guys came to us about two weeks ago and they said that the OS
> (Windows 2000 or Windows 2003) eats up by default 1/2 of the physical
> memory. So even if you have 16 GB you only have 8 GB available for the
apps
> like SQL Server. The rest is reserved for the OS.
Up to 4 GB, this may be true (I think the max the system will reserve is 2
GB by default). If your system has more than 4 GB of RAM, the system will
not automatically keep consuming *half.* We have systems with > 4 GB and we
have no problem allocating most of it to SQL Server.
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/|||I have crahsed both. I crashed analysis services a few times with MOLAP
dims of around 30million records being processed. I actually corrupted the
whole olap side (it would start but never respond) and tried to reinstall
it. Long story short, I still have a ticket open with Microsoft for a
reinstall bug 64 bit has. Here is the fun part, we could not get OLAP or
SQL to reinstall and they had no idea, so we had to rebuild the whole OS.
As far as crashing the RDBMS, I really should say we have not corrupted an
entire install. However we have brought our server to its knees and then
beat it into the dirt. Our server has quit responding in several different
ways and had more reboots than most servers should. I need to stop and say
that I do not consider it a bad product and I do like 64bit SQL. We really
do things that are not recommended and invent other things that Microsoft
and Industry people would shy away from. However, yes we have crashed both
sides.
"Kevin" <ReplyTo@.Newsgroups.only> wrote in message
news:ezph58BvDHA.2880@.tk2msftngp13.phx.gbl...
> Kevin - when you say crash you mean crashing analysis services, right, not
> the RDBMS?
>
> "Kevin Brooks" <jeepnreb@.yahoo.com> wrote in message
> news:uISfnT2uDHA.1340@.TK2MSFTNGP09.phx.gbl...
> > I guess I will chime in. We are running a 4 way 64bit Unysis ES7000
with
> > 16GB of memory on Windows 2003. We are currently using it for an OLAP
> > implementation, however the RDBMS is on the server is well. The best
> > benefit is memory, which we will be bumping up into the 30gigish range
> soon.
> > You can dynamically adjust memory over 8GB(do not really need AWE)
without
> > rebooting SQL. When we are loading data into the cubes we can give SQL
> more
> > and when aggs are being built in the cube give more to OLAP Services.
> > Beyond that memory ease, we have not really noticed a great difference.
> In
> > alot of aspects it is a pain using SQL 64 bit, due to its lack tools and
> > bugs we have ran into. We have crashed our 64bit many times with the
> amount
> > of data we are trying to punch through(billion +). To give you some
hard
> > numbers from our test using it in an OLTP environment, we traced some
> daily
> > activity and we ran the delete, insert, updates for the same anount of
> time
> > roughly --
> >
> > 32bit 4 way 8GB memory -- 133 Trans/sec
> > 64bit 4 way 8GB memory -- 613 Trans/sec
> > 32bit 8way 8GB memory -- 493 Trans/sec
> >
> > "Daniel P." <danutzp1@.hotmail.comU> wrote in message
> > news:ODRY0Y0uDHA.2508@.TK2MSFTNGP12.phx.gbl...
> > > Did anyone use the 64 bit version in production with large databases?
> > >
> > > Is it a better price/performance than the 32 bits version?
> > >
> > > Any information if highly appreciated.
> > >
> > > Thanks a lot!
> > >
> > >
> >
> >
>

Saturday, February 25, 2012

64-bit linked server to Sybase

64-bit JET drivers or alternative?

64-bit JET drivers or alternative?

64-bit issue

64-Bit Installation of SQL Server 2005 on AMD Server

64bit i/o Performance

64bit i/o Performance

64bit i/o Performance

64-Bit Edition for RS Database

64-Bit Connectivity Issues

64-Bit Connectivity Issues

64-bit and SQL Server

64bit and performance counters

64bit and performance counters

64bit and performance counters

64bit and compatability mode

64-bit

64-bit

64-bit

64000 dimension members limit?

64000 dimension members limit?

64 bits version of SQL Server 2000

3G ram for SQL server

Blog Archive

About Me