Dear Team,
After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
facing performance related issues....Could any one help me plz?
Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
2(IA64).
Regards,
JaisonHi
You would really have to post something more specific, but...
Have you updated the statistics and indexes?
Make sure that your configuration options have not changed (sp_configure)
e.g. check that you are using the right amount of memory, CPU affinity etc..
Check database options (sp_dboptions) to make sure that setting are
consistent (e.g Autoshrink is not on!)
Check that you have not introduced an IO bottleneck (e.g logs and data on
same disc or disc sector size has not been set correctly).
Run SQL profiler to identify what is taking a prolong time and investigate
specific queries/procedures.
Use Performance Monitor to check for other issues.
HTH
John
"Jaison Jose" wrote:
> Dear Team,
> After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> facing performance related issues....Could any one help me plz?
> Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> 2(IA64).
> Regards,
> Jaison|||Hi John,
Statistics are updated. All the options are set as it was there in the
previous environment. The data and log file are on the same disc. But john,
this all settings are quite fine with Xeon Processors, the cpu utilization
was only ranging in between 10-15%. Application was working very well.But
When it comes to itanium , suddenly the environment has changed. The cpu
starts shooting upto 90%. I just want to know one thing , If i want to move a
32 bit database to a 64 bit environment, what and all the wright steps that i
need to take before proceeding with the migration?....So that i can come to
know where i went wrong....
Regards,
Jaison Jose
"John Bell" wrote:
> Hi
> You would really have to post something more specific, but...
> Have you updated the statistics and indexes?
> Make sure that your configuration options have not changed (sp_configure)
> e.g. check that you are using the right amount of memory, CPU affinity etc..
> Check database options (sp_dboptions) to make sure that setting are
> consistent (e.g Autoshrink is not on!)
> Check that you have not introduced an IO bottleneck (e.g logs and data on
> same disc or disc sector size has not been set correctly).
> Run SQL profiler to identify what is taking a prolong time and investigate
> specific queries/procedures.
> Use Performance Monitor to check for other issues.
> HTH
> John
> "Jaison Jose" wrote:
> > Dear Team,
> >
> > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > facing performance related issues....Could any one help me plz?
> >
> > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > 2(IA64).
> >
> > Regards,
> > Jaison|||Hi Jaison
When you have
http://www.microsoft.com/sql/solutions/ssm/migratingto64bit.mspx it sounds
easy, but as this is a migration and not a in-situ upgrade you need to
consider all the factors that a migration entails.
You may want to read
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx which covers alot of the things you should check regardless of version.
You may also want to do some monitoring with performance monitor such as
http://www.sql-server-performance.com/performance_monitor_counters_sql_server.asp
http://www.sql-server-performance.com/sg_sql_server_performance_article.asp
Also if this is a new system then running SQLIOStress may be a good idea.
I assume that you have checked that the hardware is supported by the version
of SQL Server you are using
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sql64/in_preparing64_2ctv.asp and everything is service packed?
John
"Jaison Jose" wrote:
> Hi John,
> Statistics are updated. All the options are set as it was there in the
> previous environment. The data and log file are on the same disc. But john,
> this all settings are quite fine with Xeon Processors, the cpu utilization
> was only ranging in between 10-15%. Application was working very well.But
> When it comes to itanium , suddenly the environment has changed. The cpu
> starts shooting upto 90%. I just want to know one thing , If i want to move a
> 32 bit database to a 64 bit environment, what and all the wright steps that i
> need to take before proceeding with the migration?....So that i can come to
> know where i went wrong....
> Regards,
> Jaison Jose
>
> "John Bell" wrote:
> > Hi
> >
> > You would really have to post something more specific, but...
> >
> > Have you updated the statistics and indexes?
> >
> > Make sure that your configuration options have not changed (sp_configure)
> > e.g. check that you are using the right amount of memory, CPU affinity etc..
> >
> > Check database options (sp_dboptions) to make sure that setting are
> > consistent (e.g Autoshrink is not on!)
> >
> > Check that you have not introduced an IO bottleneck (e.g logs and data on
> > same disc or disc sector size has not been set correctly).
> >
> > Run SQL profiler to identify what is taking a prolong time and investigate
> > specific queries/procedures.
> >
> > Use Performance Monitor to check for other issues.
> >
> > HTH
> >
> > John
> >
> > "Jaison Jose" wrote:
> >
> > > Dear Team,
> > >
> > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > facing performance related issues....Could any one help me plz?
> > >
> > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > 2(IA64).
> > >
> > > Regards,
> > > Jaison|||Hai John,
I had created a fresh database in the 64 bit new server. Then
I had generated a complete script(database->alltask->generate script->) from
the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
the data to the newly created database. The reason why i had gone for this
way is nothing but while trying for an attach i was facing some error(Sorry,
i am not remembering exactly the error..).
Does this cause any issue?
If something had gone wrong with this, Will it be possible me to configure
it proper..?
"Jaison Jose" wrote:
> Dear Team,
> After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> facing performance related issues....Could any one help me plz?
> Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> 2(IA64).
> Regards,
> Jaison|||Hi Jaison
Check that the indexes were scripted properly. If data was pumped into the
tables after creating the indexes you would need to rebuild the indexes. If
you have auto create stats on for you database then you will have lost these.
Backup/restore should have worked fine when transferring the database as
well as detach/attach which should be significantly quicker than your method
so you may want to try it again.
John
"Jaison Jose" wrote:
> Hai John,
> I had created a fresh database in the 64 bit new server. Then
> I had generated a complete script(database->alltask->generate script->) from
> the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> the data to the newly created database. The reason why i had gone for this
> way is nothing but while trying for an attach i was facing some error(Sorry,
> i am not remembering exactly the error..).
> Does this cause any issue?
> If something had gone wrong with this, Will it be possible me to configure
> it proper..?
>
> "Jaison Jose" wrote:
> > Dear Team,
> >
> > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > facing performance related issues....Could any one help me plz?
> >
> > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > 2(IA64).
> >
> > Regards,
> > Jaison|||Hi John,
USE Database_Name
GO
EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
GO
Hope this will do. Appreciate ur comments as well.
I had already done an index defragmentation by using DBCC INDEXDEFRAG
statement , but no visible effects. In this case is there any difference
between
DBCC INDEXDEFRAG and DBCC DBREINDEX ?
Regards,
Jaison
"John Bell" wrote:
> Hi Jaison
> Check that the indexes were scripted properly. If data was pumped into the
> tables after creating the indexes you would need to rebuild the indexes. If
> you have auto create stats on for you database then you will have lost these.
> Backup/restore should have worked fine when transferring the database as
> well as detach/attach which should be significantly quicker than your method
> so you may want to try it again.
> John
> "Jaison Jose" wrote:
> > Hai John,
> >
> > I had created a fresh database in the 64 bit new server. Then
> > I had generated a complete script(database->alltask->generate script->) from
> > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > the data to the newly created database. The reason why i had gone for this
> > way is nothing but while trying for an attach i was facing some error(Sorry,
> > i am not remembering exactly the error..).
> >
> > Does this cause any issue?
> > If something had gone wrong with this, Will it be possible me to configure
> > it proper..?
> >
> >
> > "Jaison Jose" wrote:
> >
> > > Dear Team,
> > >
> > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > facing performance related issues....Could any one help me plz?
> > >
> > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > 2(IA64).
> > >
> > > Regards,
> > > Jaison|||Hi
INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
everything to be reset at 80% fill factor! Did the index creation scripts
explicitly say 80%? I would expect read-only tables or ones that don't often
get changed to have a higher fill factor.
Have you run SQL profiler to compare the duration of stored procedures on
the old system to the old and new systems?
John
"Jaison Jose" wrote:
> Hi John,
> USE Database_Name
> GO
> EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> GO
> Hope this will do. Appreciate ur comments as well.
> I had already done an index defragmentation by using DBCC INDEXDEFRAG
> statement , but no visible effects. In this case is there any difference
> between
> DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> Regards,
> Jaison
>
> "John Bell" wrote:
> > Hi Jaison
> >
> > Check that the indexes were scripted properly. If data was pumped into the
> > tables after creating the indexes you would need to rebuild the indexes. If
> > you have auto create stats on for you database then you will have lost these.
> >
> > Backup/restore should have worked fine when transferring the database as
> > well as detach/attach which should be significantly quicker than your method
> > so you may want to try it again.
> >
> > John
> >
> > "Jaison Jose" wrote:
> >
> > > Hai John,
> > >
> > > I had created a fresh database in the 64 bit new server. Then
> > > I had generated a complete script(database->alltask->generate script->) from
> > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > the data to the newly created database. The reason why i had gone for this
> > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > i am not remembering exactly the error..).
> > >
> > > Does this cause any issue?
> > > If something had gone wrong with this, Will it be possible me to configure
> > > it proper..?
> > >
> > >
> > > "Jaison Jose" wrote:
> > >
> > > > Dear Team,
> > > >
> > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > facing performance related issues....Could any one help me plz?
> > > >
> > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > 2(IA64).
> > > >
> > > > Regards,
> > > > Jaison|||Hi John,
Could you plz guide me to do the rebuilding the indexes without disturbing
the existing fill factor? Or do you have a well defined script to achieve
this?
Regards,
Jaison
"John Bell" wrote:
> Hi
> INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
> everything to be reset at 80% fill factor! Did the index creation scripts
> explicitly say 80%? I would expect read-only tables or ones that don't often
> get changed to have a higher fill factor.
> Have you run SQL profiler to compare the duration of stored procedures on
> the old system to the old and new systems?
> John
>
> "Jaison Jose" wrote:
> > Hi John,
> >
> > USE Database_Name
> > GO
> > EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> > GO
> >
> > Hope this will do. Appreciate ur comments as well.
> >
> > I had already done an index defragmentation by using DBCC INDEXDEFRAG
> > statement , but no visible effects. In this case is there any difference
> > between
> > DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> >
> > Regards,
> > Jaison
> >
> >
> >
> > "John Bell" wrote:
> >
> > > Hi Jaison
> > >
> > > Check that the indexes were scripted properly. If data was pumped into the
> > > tables after creating the indexes you would need to rebuild the indexes. If
> > > you have auto create stats on for you database then you will have lost these.
> > >
> > > Backup/restore should have worked fine when transferring the database as
> > > well as detach/attach which should be significantly quicker than your method
> > > so you may want to try it again.
> > >
> > > John
> > >
> > > "Jaison Jose" wrote:
> > >
> > > > Hai John,
> > > >
> > > > I had created a fresh database in the 64 bit new server. Then
> > > > I had generated a complete script(database->alltask->generate script->) from
> > > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > > the data to the newly created database. The reason why i had gone for this
> > > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > > i am not remembering exactly the error..).
> > > >
> > > > Does this cause any issue?
> > > > If something had gone wrong with this, Will it be possible me to configure
> > > > it proper..?
> > > >
> > > >
> > > > "Jaison Jose" wrote:
> > > >
> > > > > Dear Team,
> > > > >
> > > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > > facing performance related issues....Could any one help me plz?
> > > > >
> > > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > > 2(IA64).
> > > > >
> > > > > Regards,
> > > > > Jaison|||Hi Jaison
Using a 0 as the second parameter to DBCC DBREINDEX will use the current
fill factor. From BOL:
fillfactor
Is the percentage of space on each index page to be used for storing data
when the index is created. fillfactor replaces the original fillfactor as the
new default for the index and for any other nonclustered indexes rebuilt
because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX
uses the original fillfactor specified when the index was created.
If you have already run the DBCC DBREINDEX command with a fixed fill factor
then you would need to drop and recreate the indexes or run DBCC DBREINDEX
for each index that should have a fill factor that is not 80%
John
"Jaison Jose" wrote:
> Hi John,
> Could you plz guide me to do the rebuilding the indexes without disturbing
> the existing fill factor? Or do you have a well defined script to achieve
> this?
> Regards,
> Jaison
> "John Bell" wrote:
> > Hi
> >
> > INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
> > everything to be reset at 80% fill factor! Did the index creation scripts
> > explicitly say 80%? I would expect read-only tables or ones that don't often
> > get changed to have a higher fill factor.
> >
> > Have you run SQL profiler to compare the duration of stored procedures on
> > the old system to the old and new systems?
> >
> > John
> >
> >
> >
> > "Jaison Jose" wrote:
> >
> > > Hi John,
> > >
> > > USE Database_Name
> > > GO
> > > EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> > > GO
> > >
> > > Hope this will do. Appreciate ur comments as well.
> > >
> > > I had already done an index defragmentation by using DBCC INDEXDEFRAG
> > > statement , but no visible effects. In this case is there any difference
> > > between
> > > DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> > >
> > > Regards,
> > > Jaison
> > >
> > >
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi Jaison
> > > >
> > > > Check that the indexes were scripted properly. If data was pumped into the
> > > > tables after creating the indexes you would need to rebuild the indexes. If
> > > > you have auto create stats on for you database then you will have lost these.
> > > >
> > > > Backup/restore should have worked fine when transferring the database as
> > > > well as detach/attach which should be significantly quicker than your method
> > > > so you may want to try it again.
> > > >
> > > > John
> > > >
> > > > "Jaison Jose" wrote:
> > > >
> > > > > Hai John,
> > > > >
> > > > > I had created a fresh database in the 64 bit new server. Then
> > > > > I had generated a complete script(database->alltask->generate script->) from
> > > > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > > > the data to the newly created database. The reason why i had gone for this
> > > > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > > > i am not remembering exactly the error..).
> > > > >
> > > > > Does this cause any issue?
> > > > > If something had gone wrong with this, Will it be possible me to configure
> > > > > it proper..?
> > > > >
> > > > >
> > > > > "Jaison Jose" wrote:
> > > > >
> > > > > > Dear Team,
> > > > > >
> > > > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > > > facing performance related issues....Could any one help me plz?
> > > > > >
> > > > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > > > 2(IA64).
> > > > > >
> > > > > > Regards,
> > > > > > Jaison|||Hi John,
After rebuilding indexes the transaction logs has grown upto 3GB(initially
it was only 20MB). If i do a truncate and shrink after this to reduce the log
size, how it will affect the performance? Or i should not perform this
operation after rebuilding the indexes?
One more question.
My live database is on a 64 bit environment, having a sql server 2000 64 bit
enterprise edition with SP4.
As per the regular process ,twice in a week , we used to take the database
into the another local machine which is having a 32 bit environment with sql
server 2000 32bit enterprise edition installed. We used to restore the
database from the live server(64 bit) to the local machine(32 bit) for doing
some uploads and after completing the uploads we used to take the backup from
the local and restore it into the live server. So what i doubts is that ,
suppose if i rebuild all the indexes from the live server and as per the
regular process , restored it into local pc. So after completing the
necessary uploads i am again restore back it to the live server. Does this
opration makes any negative impact in terms of indexes? Or do i need to
perform rebuilding the indexes every time when i complete this process from
the live 64 bit server?...
Regards,
Jaison
"John Bell" wrote:
> Hi Jaison
> Using a 0 as the second parameter to DBCC DBREINDEX will use the current
> fill factor. From BOL:
> fillfactor
> Is the percentage of space on each index page to be used for storing data
> when the index is created. fillfactor replaces the original fillfactor as the
> new default for the index and for any other nonclustered indexes rebuilt
> because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX
> uses the original fillfactor specified when the index was created.
> If you have already run the DBCC DBREINDEX command with a fixed fill factor
> then you would need to drop and recreate the indexes or run DBCC DBREINDEX
> for each index that should have a fill factor that is not 80%
> John
> "Jaison Jose" wrote:
> > Hi John,
> >
> > Could you plz guide me to do the rebuilding the indexes without disturbing
> > the existing fill factor? Or do you have a well defined script to achieve
> > this?
> >
> > Regards,
> > Jaison
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
> > > everything to be reset at 80% fill factor! Did the index creation scripts
> > > explicitly say 80%? I would expect read-only tables or ones that don't often
> > > get changed to have a higher fill factor.
> > >
> > > Have you run SQL profiler to compare the duration of stored procedures on
> > > the old system to the old and new systems?
> > >
> > > John
> > >
> > >
> > >
> > > "Jaison Jose" wrote:
> > >
> > > > Hi John,
> > > >
> > > > USE Database_Name
> > > > GO
> > > > EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> > > > GO
> > > >
> > > > Hope this will do. Appreciate ur comments as well.
> > > >
> > > > I had already done an index defragmentation by using DBCC INDEXDEFRAG
> > > > statement , but no visible effects. In this case is there any difference
> > > > between
> > > > DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> > > >
> > > > Regards,
> > > > Jaison
> > > >
> > > >
> > > >
> > > > "John Bell" wrote:
> > > >
> > > > > Hi Jaison
> > > > >
> > > > > Check that the indexes were scripted properly. If data was pumped into the
> > > > > tables after creating the indexes you would need to rebuild the indexes. If
> > > > > you have auto create stats on for you database then you will have lost these.
> > > > >
> > > > > Backup/restore should have worked fine when transferring the database as
> > > > > well as detach/attach which should be significantly quicker than your method
> > > > > so you may want to try it again.
> > > > >
> > > > > John
> > > > >
> > > > > "Jaison Jose" wrote:
> > > > >
> > > > > > Hai John,
> > > > > >
> > > > > > I had created a fresh database in the 64 bit new server. Then
> > > > > > I had generated a complete script(database->alltask->generate script->) from
> > > > > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > > > > the data to the newly created database. The reason why i had gone for this
> > > > > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > > > > i am not remembering exactly the error..).
> > > > > >
> > > > > > Does this cause any issue?
> > > > > > If something had gone wrong with this, Will it be possible me to configure
> > > > > > it proper..?
> > > > > >
> > > > > >
> > > > > > "Jaison Jose" wrote:
> > > > > >
> > > > > > > Dear Team,
> > > > > > >
> > > > > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > > > > facing performance related issues....Could any one help me plz?
> > > > > > >
> > > > > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > > > > 2(IA64).
> > > > > > >
> > > > > > > Regards,
> > > > > > > Jaison|||Hi Jaison
To overcome the bloated log file whilst rebuilding indexes, you could set
your recovery mode to simple for the duration of the task and checkpoint
after each index rebuild or leave it on full recovery backup the log after
each index rebuild. If you are more selective in the way you rebuild the
indexes then you could do it less frequently.
You should set the size of the log file to a size such that during normal
use it is not going to be continually extended. Extending the log can mean it
gets fragmented on the disc and so impairs performance. During the file
extension performance may be affected. You may want to read
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
John
"Jaison Jose" wrote:
> Hi John,
> After rebuilding indexes the transaction logs has grown upto 3GB(initially
> it was only 20MB). If i do a truncate and shrink after this to reduce the log
> size, how it will affect the performance? Or i should not perform this
> operation after rebuilding the indexes?
> One more question.
> My live database is on a 64 bit environment, having a sql server 2000 64 bit
> enterprise edition with SP4.
> As per the regular process ,twice in a week , we used to take the database
> into the another local machine which is having a 32 bit environment with sql
> server 2000 32bit enterprise edition installed. We used to restore the
> database from the live server(64 bit) to the local machine(32 bit) for doing
> some uploads and after completing the uploads we used to take the backup from
> the local and restore it into the live server. So what i doubts is that ,
> suppose if i rebuild all the indexes from the live server and as per the
> regular process , restored it into local pc. So after completing the
> necessary uploads i am again restore back it to the live server. Does this
> opration makes any negative impact in terms of indexes? Or do i need to
> perform rebuilding the indexes every time when i complete this process from
> the live 64 bit server?...
> Regards,
> Jaison
> "John Bell" wrote:
> > Hi Jaison
> >
> > Using a 0 as the second parameter to DBCC DBREINDEX will use the current
> > fill factor. From BOL:
> >
> > fillfactor
> >
> > Is the percentage of space on each index page to be used for storing data
> > when the index is created. fillfactor replaces the original fillfactor as the
> > new default for the index and for any other nonclustered indexes rebuilt
> > because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX
> > uses the original fillfactor specified when the index was created.
> >
> > If you have already run the DBCC DBREINDEX command with a fixed fill factor
> > then you would need to drop and recreate the indexes or run DBCC DBREINDEX
> > for each index that should have a fill factor that is not 80%
> >
> > John
> >
> > "Jaison Jose" wrote:
> >
> > > Hi John,
> > >
> > > Could you plz guide me to do the rebuilding the indexes without disturbing
> > > the existing fill factor? Or do you have a well defined script to achieve
> > > this?
> > >
> > > Regards,
> > > Jaison
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
> > > > everything to be reset at 80% fill factor! Did the index creation scripts
> > > > explicitly say 80%? I would expect read-only tables or ones that don't often
> > > > get changed to have a higher fill factor.
> > > >
> > > > Have you run SQL profiler to compare the duration of stored procedures on
> > > > the old system to the old and new systems?
> > > >
> > > > John
> > > >
> > > >
> > > >
> > > > "Jaison Jose" wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > USE Database_Name
> > > > > GO
> > > > > EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> > > > > GO
> > > > >
> > > > > Hope this will do. Appreciate ur comments as well.
> > > > >
> > > > > I had already done an index defragmentation by using DBCC INDEXDEFRAG
> > > > > statement , but no visible effects. In this case is there any difference
> > > > > between
> > > > > DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> > > > >
> > > > > Regards,
> > > > > Jaison
> > > > >
> > > > >
> > > > >
> > > > > "John Bell" wrote:
> > > > >
> > > > > > Hi Jaison
> > > > > >
> > > > > > Check that the indexes were scripted properly. If data was pumped into the
> > > > > > tables after creating the indexes you would need to rebuild the indexes. If
> > > > > > you have auto create stats on for you database then you will have lost these.
> > > > > >
> > > > > > Backup/restore should have worked fine when transferring the database as
> > > > > > well as detach/attach which should be significantly quicker than your method
> > > > > > so you may want to try it again.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > "Jaison Jose" wrote:
> > > > > >
> > > > > > > Hai John,
> > > > > > >
> > > > > > > I had created a fresh database in the 64 bit new server. Then
> > > > > > > I had generated a complete script(database->alltask->generate script->) from
> > > > > > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > > > > > the data to the newly created database. The reason why i had gone for this
> > > > > > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > > > > > i am not remembering exactly the error..).
> > > > > > >
> > > > > > > Does this cause any issue?
> > > > > > > If something had gone wrong with this, Will it be possible me to configure
> > > > > > > it proper..?
> > > > > > >
> > > > > > >
> > > > > > > "Jaison Jose" wrote:
> > > > > > >
> > > > > > > > Dear Team,
> > > > > > > >
> > > > > > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > > > > > facing performance related issues....Could any one help me plz?
> > > > > > > >
> > > > > > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > > > > > 2(IA64).
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Jaison|||Hi John,
Thanks. That's fine.
waiting for ur valuable suggestion regarding my second question?(moving db
from 32bit to 64 bit and vise versa) Each time do i need to perform an index
rebuild after restoring the database into 64 bit?
"John Bell" wrote:
> Hi Jaison
> To overcome the bloated log file whilst rebuilding indexes, you could set
> your recovery mode to simple for the duration of the task and checkpoint
> after each index rebuild or leave it on full recovery backup the log after
> each index rebuild. If you are more selective in the way you rebuild the
> indexes then you could do it less frequently.
> You should set the size of the log file to a size such that during normal
> use it is not going to be continually extended. Extending the log can mean it
> gets fragmented on the disc and so impairs performance. During the file
> extension performance may be affected. You may want to read
> http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> John
> "Jaison Jose" wrote:
> > Hi John,
> >
> > After rebuilding indexes the transaction logs has grown upto 3GB(initially
> > it was only 20MB). If i do a truncate and shrink after this to reduce the log
> > size, how it will affect the performance? Or i should not perform this
> > operation after rebuilding the indexes?
> >
> > One more question.
> > My live database is on a 64 bit environment, having a sql server 2000 64 bit
> > enterprise edition with SP4.
> > As per the regular process ,twice in a week , we used to take the database
> > into the another local machine which is having a 32 bit environment with sql
> > server 2000 32bit enterprise edition installed. We used to restore the
> > database from the live server(64 bit) to the local machine(32 bit) for doing
> > some uploads and after completing the uploads we used to take the backup from
> > the local and restore it into the live server. So what i doubts is that ,
> > suppose if i rebuild all the indexes from the live server and as per the
> > regular process , restored it into local pc. So after completing the
> > necessary uploads i am again restore back it to the live server. Does this
> > opration makes any negative impact in terms of indexes? Or do i need to
> > perform rebuilding the indexes every time when i complete this process from
> > the live 64 bit server?...
> >
> > Regards,
> > Jaison
> >
> > "John Bell" wrote:
> >
> > > Hi Jaison
> > >
> > > Using a 0 as the second parameter to DBCC DBREINDEX will use the current
> > > fill factor. From BOL:
> > >
> > > fillfactor
> > >
> > > Is the percentage of space on each index page to be used for storing data
> > > when the index is created. fillfactor replaces the original fillfactor as the
> > > new default for the index and for any other nonclustered indexes rebuilt
> > > because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX
> > > uses the original fillfactor specified when the index was created.
> > >
> > > If you have already run the DBCC DBREINDEX command with a fixed fill factor
> > > then you would need to drop and recreate the indexes or run DBCC DBREINDEX
> > > for each index that should have a fill factor that is not 80%
> > >
> > > John
> > >
> > > "Jaison Jose" wrote:
> > >
> > > > Hi John,
> > > >
> > > > Could you plz guide me to do the rebuilding the indexes without disturbing
> > > > the existing fill factor? Or do you have a well defined script to achieve
> > > > this?
> > > >
> > > > Regards,
> > > > Jaison
> > > >
> > > > "John Bell" wrote:
> > > >
> > > > > Hi
> > > > >
> > > > > INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
> > > > > everything to be reset at 80% fill factor! Did the index creation scripts
> > > > > explicitly say 80%? I would expect read-only tables or ones that don't often
> > > > > get changed to have a higher fill factor.
> > > > >
> > > > > Have you run SQL profiler to compare the duration of stored procedures on
> > > > > the old system to the old and new systems?
> > > > >
> > > > > John
> > > > >
> > > > >
> > > > >
> > > > > "Jaison Jose" wrote:
> > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > USE Database_Name
> > > > > > GO
> > > > > > EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> > > > > > GO
> > > > > >
> > > > > > Hope this will do. Appreciate ur comments as well.
> > > > > >
> > > > > > I had already done an index defragmentation by using DBCC INDEXDEFRAG
> > > > > > statement , but no visible effects. In this case is there any difference
> > > > > > between
> > > > > > DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> > > > > >
> > > > > > Regards,
> > > > > > Jaison
> > > > > >
> > > > > >
> > > > > >
> > > > > > "John Bell" wrote:
> > > > > >
> > > > > > > Hi Jaison
> > > > > > >
> > > > > > > Check that the indexes were scripted properly. If data was pumped into the
> > > > > > > tables after creating the indexes you would need to rebuild the indexes. If
> > > > > > > you have auto create stats on for you database then you will have lost these.
> > > > > > >
> > > > > > > Backup/restore should have worked fine when transferring the database as
> > > > > > > well as detach/attach which should be significantly quicker than your method
> > > > > > > so you may want to try it again.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > "Jaison Jose" wrote:
> > > > > > >
> > > > > > > > Hai John,
> > > > > > > >
> > > > > > > > I had created a fresh database in the 64 bit new server. Then
> > > > > > > > I had generated a complete script(database->alltask->generate script->) from
> > > > > > > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > > > > > > the data to the newly created database. The reason why i had gone for this
> > > > > > > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > > > > > > i am not remembering exactly the error..).
> > > > > > > >
> > > > > > > > Does this cause any issue?
> > > > > > > > If something had gone wrong with this, Will it be possible me to configure
> > > > > > > > it proper..?
> > > > > > > >
> > > > > > > >
> > > > > > > > "Jaison Jose" wrote:
> > > > > > > >
> > > > > > > > > Dear Team,
> > > > > > > > >
> > > > > > > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > > > > > > facing performance related issues....Could any one help me plz?
> > > > > > > > >
> > > > > > > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > > > > > > 2(IA64).
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Jaison|||Hi Jaison
I don't think it is absolutely necessary to rebuild the indexes or update
the statistics, but I would say it is good practice to do so as you would
want the database to be at the maximum efficiency when you start on the new
platform. In your case as you have just uploaded or changed some data (I
assume that can be a large amount of data or you would not need this
elaborate procedure!) then you should definitely update the indexes after the
upload, and it would be better to do it before it is transferred.
If the data is only uploaded into a distinct subset of your tables then you
may want to look at federating the database, so that you hold the uploaded
data in a separate database and only have to swap that database in/out. This
would mean that the database is smaller and your downtime will be reduced (to
the time it takes to detach the old database and attach the new one). If the
data you have uploaded is not changed, then you could even make this database
read only. NB You could save space by making sure that the log on the read
only database is minimized. If the user can only add data to these tables you
may want to look at partitioning the tables so that the user data is
maintained in the main database and you can still keep the uploaded database
read only. Views in the main database corresponding to the tables that have
moved would reduce the need to change any code.
HTH
John
"Jaison Jose" wrote:
> Hi John,
> Thanks. That's fine.
> waiting for ur valuable suggestion regarding my second question?(moving db
> from 32bit to 64 bit and vise versa) Each time do i need to perform an index
> rebuild after restoring the database into 64 bit?
> "John Bell" wrote:
> > Hi Jaison
> >
> > To overcome the bloated log file whilst rebuilding indexes, you could set
> > your recovery mode to simple for the duration of the task and checkpoint
> > after each index rebuild or leave it on full recovery backup the log after
> > each index rebuild. If you are more selective in the way you rebuild the
> > indexes then you could do it less frequently.
> >
> > You should set the size of the log file to a size such that during normal
> > use it is not going to be continually extended. Extending the log can mean it
> > gets fragmented on the disc and so impairs performance. During the file
> > extension performance may be affected. You may want to read
> > http://www.karaszi.com/SQLServer/info_dont_shrink.asp
> >
> > John
> >
> > "Jaison Jose" wrote:
> >
> > > Hi John,
> > >
> > > After rebuilding indexes the transaction logs has grown upto 3GB(initially
> > > it was only 20MB). If i do a truncate and shrink after this to reduce the log
> > > size, how it will affect the performance? Or i should not perform this
> > > operation after rebuilding the indexes?
> > >
> > > One more question.
> > > My live database is on a 64 bit environment, having a sql server 2000 64 bit
> > > enterprise edition with SP4.
> > > As per the regular process ,twice in a week , we used to take the database
> > > into the another local machine which is having a 32 bit environment with sql
> > > server 2000 32bit enterprise edition installed. We used to restore the
> > > database from the live server(64 bit) to the local machine(32 bit) for doing
> > > some uploads and after completing the uploads we used to take the backup from
> > > the local and restore it into the live server. So what i doubts is that ,
> > > suppose if i rebuild all the indexes from the live server and as per the
> > > regular process , restored it into local pc. So after completing the
> > > necessary uploads i am again restore back it to the live server. Does this
> > > opration makes any negative impact in terms of indexes? Or do i need to
> > > perform rebuilding the indexes every time when i complete this process from
> > > the live 64 bit server?...
> > >
> > > Regards,
> > > Jaison
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi Jaison
> > > >
> > > > Using a 0 as the second parameter to DBCC DBREINDEX will use the current
> > > > fill factor. From BOL:
> > > >
> > > > fillfactor
> > > >
> > > > Is the percentage of space on each index page to be used for storing data
> > > > when the index is created. fillfactor replaces the original fillfactor as the
> > > > new default for the index and for any other nonclustered indexes rebuilt
> > > > because a clustered index is rebuilt. When fillfactor is 0, DBCC DBREINDEX
> > > > uses the original fillfactor specified when the index was created.
> > > >
> > > > If you have already run the DBCC DBREINDEX command with a fixed fill factor
> > > > then you would need to drop and recreate the indexes or run DBCC DBREINDEX
> > > > for each index that should have a fill factor that is not 80%
> > > >
> > > > John
> > > >
> > > > "Jaison Jose" wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > Could you plz guide me to do the rebuilding the indexes without disturbing
> > > > > the existing fill factor? Or do you have a well defined script to achieve
> > > > > this?
> > > > >
> > > > > Regards,
> > > > > Jaison
> > > > >
> > > > > "John Bell" wrote:
> > > > >
> > > > > > Hi
> > > > > >
> > > > > > INDEXDEFRAG will only defragment leaf pages, I am not sure why you want
> > > > > > everything to be reset at 80% fill factor! Did the index creation scripts
> > > > > > explicitly say 80%? I would expect read-only tables or ones that don't often
> > > > > > get changed to have a higher fill factor.
> > > > > >
> > > > > > Have you run SQL profiler to compare the duration of stored procedures on
> > > > > > the old system to the old and new systems?
> > > > > >
> > > > > > John
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Jaison Jose" wrote:
> > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > > USE Database_Name
> > > > > > > GO
> > > > > > > EXEC sp_MSforeachtable @.command1="print '?' DBCC DBREINDEX ('?', ' ', 80)"
> > > > > > > GO
> > > > > > >
> > > > > > > Hope this will do. Appreciate ur comments as well.
> > > > > > >
> > > > > > > I had already done an index defragmentation by using DBCC INDEXDEFRAG
> > > > > > > statement , but no visible effects. In this case is there any difference
> > > > > > > between
> > > > > > > DBCC INDEXDEFRAG and DBCC DBREINDEX ?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Jaison
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > "John Bell" wrote:
> > > > > > >
> > > > > > > > Hi Jaison
> > > > > > > >
> > > > > > > > Check that the indexes were scripted properly. If data was pumped into the
> > > > > > > > tables after creating the indexes you would need to rebuild the indexes. If
> > > > > > > > you have auto create stats on for you database then you will have lost these.
> > > > > > > >
> > > > > > > > Backup/restore should have worked fine when transferring the database as
> > > > > > > > well as detach/attach which should be significantly quicker than your method
> > > > > > > > so you may want to try it again.
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > > > "Jaison Jose" wrote:
> > > > > > > >
> > > > > > > > > Hai John,
> > > > > > > > >
> > > > > > > > > I had created a fresh database in the 64 bit new server. Then
> > > > > > > > > I had generated a complete script(database->alltask->generate script->) from
> > > > > > > > > the 32 bit sql server and made it run on 64 bit. And then done a DTS to move
> > > > > > > > > the data to the newly created database. The reason why i had gone for this
> > > > > > > > > way is nothing but while trying for an attach i was facing some error(Sorry,
> > > > > > > > > i am not remembering exactly the error..).
> > > > > > > > >
> > > > > > > > > Does this cause any issue?
> > > > > > > > > If something had gone wrong with this, Will it be possible me to configure
> > > > > > > > > it proper..?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > "Jaison Jose" wrote:
> > > > > > > > >
> > > > > > > > > > Dear Team,
> > > > > > > > > >
> > > > > > > > > > After migrating to sql server 2000 32 bit to sql server 2000 64 bit, we are
> > > > > > > > > > facing performance related issues....Could any one help me plz?
> > > > > > > > > >
> > > > > > > > > > Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itanium
> > > > > > > > > > 2(IA64).
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Jaisonsql
Showing posts with label bit. Show all posts
Showing posts with label bit. Show all posts
Sunday, March 25, 2012
32-bit to 64 bit migration of SQL Server 2005 (Deployment)
Hi
Do we need to perform any special checks when we deploy SQL Server application developed using 32 bit SQL 2005 Edition in 64 bit SQL 2005 Edition?
To my understanding, 64 bit SQL Server 2005 provides better memory management and provides high performance when compared to 32 bit and it should not be an issue in deploying the application developed in 32 bit SQL Server 2005 in 64 bit environment.
Any help/hints on deploying in 64 bit SQL Server (for a product[SPs, TSQL Stmts] developed using 32 bit SQL Server) is appreciated.
Thanks
Kart
Hi,
Take a look at the following Knowledge Base Article:
http://support.microsoft.com/kb/314546/
-Vikram
32bit SQL Server on Win2003 64bit server?
Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
I'm stuck downgrading to be able to access data from some appliances the use
MySQL. If I can get away with only moving to a 32bit version of SQL Server
that will save me quite a bit of time...
Regards.
If I understand your question properly then yes you can run the 32 bit
version of SQL Server on an X64 bit OS. If you are talking about true 64bit
(Itanium) then no you cant.
Andrew J. Kelly SQL MVP
"kstjohn" <kstjohn@.discussions.microsoft.com> wrote in message
news:9799848E-BFB2-4084-A196-C01FFAF4A83D@.microsoft.com...
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the
> use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
|||Hi
"kstjohn" wrote:
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
A 32 bit ODBC driver will connect to a 64 bit version of SQL 2005 but it is
not clear which machines you are connecting from! On 64 bit windows you may
find the 32 bit ODBC administrator at c:\windows\syswow64\odbcad32.exe
John
sql
I'm stuck downgrading to be able to access data from some appliances the use
MySQL. If I can get away with only moving to a 32bit version of SQL Server
that will save me quite a bit of time...
Regards.
If I understand your question properly then yes you can run the 32 bit
version of SQL Server on an X64 bit OS. If you are talking about true 64bit
(Itanium) then no you cant.
Andrew J. Kelly SQL MVP
"kstjohn" <kstjohn@.discussions.microsoft.com> wrote in message
news:9799848E-BFB2-4084-A196-C01FFAF4A83D@.microsoft.com...
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the
> use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
|||Hi
"kstjohn" wrote:
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
A 32 bit ODBC driver will connect to a 64 bit version of SQL 2005 but it is
not clear which machines you are connecting from! On 64 bit windows you may
find the 32 bit ODBC administrator at c:\windows\syswow64\odbcad32.exe
John
sql
32bit SQL Server on Win2003 64bit server?
Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
I'm stuck downgrading to be able to access data from some appliances the use
MySQL. If I can get away with only moving to a 32bit version of SQL Server
that will save me quite a bit of time...
Regards.If I understand your question properly then yes you can run the 32 bit
version of SQL Server on an X64 bit OS. If you are talking about true 64bit
(Itanium) then no you cant.
Andrew J. Kelly SQL MVP
"kstjohn" <kstjohn@.discussions.microsoft.com> wrote in message
news:9799848E-BFB2-4084-A196-C01FFAF4A83D@.microsoft.com...
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the
> use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.|||Hi
"kstjohn" wrote:
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the u
se
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
A 32 bit ODBC driver will connect to a 64 bit version of SQL 2005 but it is
not clear which machines you are connecting from! On 64 bit windows you may
find the 32 bit ODBC administrator at c:\windows\syswow64\odbcad32.exe
John
I'm stuck downgrading to be able to access data from some appliances the use
MySQL. If I can get away with only moving to a 32bit version of SQL Server
that will save me quite a bit of time...
Regards.If I understand your question properly then yes you can run the 32 bit
version of SQL Server on an X64 bit OS. If you are talking about true 64bit
(Itanium) then no you cant.
Andrew J. Kelly SQL MVP
"kstjohn" <kstjohn@.discussions.microsoft.com> wrote in message
news:9799848E-BFB2-4084-A196-C01FFAF4A83D@.microsoft.com...
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the
> use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.|||Hi
"kstjohn" wrote:
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the u
se
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
A 32 bit ODBC driver will connect to a 64 bit version of SQL 2005 but it is
not clear which machines you are connecting from! On 64 bit windows you may
find the 32 bit ODBC administrator at c:\windows\syswow64\odbcad32.exe
John
32bit SQL Server on Win2003 64bit server?
Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
I'm stuck downgrading to be able to access data from some appliances the use
MySQL. If I can get away with only moving to a 32bit version of SQL Server
that will save me quite a bit of time...
Regards.If I understand your question properly then yes you can run the 32 bit
version of SQL Server on an X64 bit OS. If you are talking about true 64bit
(Itanium) then no you cant.
--
Andrew J. Kelly SQL MVP
"kstjohn" <kstjohn@.discussions.microsoft.com> wrote in message
news:9799848E-BFB2-4084-A196-C01FFAF4A83D@.microsoft.com...
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the
> use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.|||Hi
"kstjohn" wrote:
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
A 32 bit ODBC driver will connect to a 64 bit version of SQL 2005 but it is
not clear which machines you are connecting from! On 64 bit windows you may
find the 32 bit ODBC administrator at c:\windows\syswow64\odbcad32.exe
John
I'm stuck downgrading to be able to access data from some appliances the use
MySQL. If I can get away with only moving to a 32bit version of SQL Server
that will save me quite a bit of time...
Regards.If I understand your question properly then yes you can run the 32 bit
version of SQL Server on an X64 bit OS. If you are talking about true 64bit
(Itanium) then no you cant.
--
Andrew J. Kelly SQL MVP
"kstjohn" <kstjohn@.discussions.microsoft.com> wrote in message
news:9799848E-BFB2-4084-A196-C01FFAF4A83D@.microsoft.com...
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the
> use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.|||Hi
"kstjohn" wrote:
> Does this work? Without an ODBC connector (MSDASQL) for the 64 bit version
> I'm stuck downgrading to be able to access data from some appliances the use
> MySQL. If I can get away with only moving to a 32bit version of SQL Server
> that will save me quite a bit of time...
> Regards.
A 32 bit ODBC driver will connect to a 64 bit version of SQL 2005 but it is
not clear which machines you are connecting from! On 64 bit windows you may
find the 32 bit ODBC administrator at c:\windows\syswow64\odbcad32.exe
John
32bit SQL Server on 64bit Inter Hardware
Hello,
Are there any issues with running the 32 bit version of Windows 2003 server and SQL Server Standard edition on a 64 bit Intel hardware Platform? I don't see why there would be if the OS is 32bit but just thought I'd ask.
Thanks.
No significant issues -other than the memory limit issues.|||There are no issues. As far as any of the software is conserned you will have all the memory limits and CPU limits of an x86 machine.|||Thanks for the info guys.32bit SQL 2000 to 64bit SQL 2005
We detached a 32bit 2000 db and attached it to 64 bit 2005 server.
We have an Itanium server will all the bells and whistle's, but when we run the loadrunner, the cpu max's at 100%. Even a sp_who2 spikes the CPU.
I ran the dbcc for stats and reindex, I also recompiled all procs.
I've tried it in both the 8.0 and 9.0 compatibility modes with almost no difference.
Can we attach a 32bit 2000 db on a 64 bit server?
Any other suggestions for me to take a look at?
We are suppose to have our POC by EOD, so your help would be greatly appreciated.
Thanks
Susan
Still having same issues.
|||Attaching a 32 bit database to a 64 bit server is supported. Can you look in the SQL log and see if it reports any errors?sql32bit Admin tools when the only media you have is 64 bit
We have jumped straight to 64 bit SQL 2005 with no 32 bit 2005 inbetween.
However this means the tools we have cannot be installed on windows XP/2000 32 bit.
Is there some way to get the 32 bit tools as it appears strange that 32 bit tools were not provided for remote access.
Cheers
Julian
It is not clear which media package you have, but there should be a Tools CD which can be installed on 32-Bit.
Thanks,
Peter
|||Hi Peter,
Thanks for this - I am working off an MLP disk pack which came with DVD and 2 Set CD.
Autoplaying on an XP sp2 machine via the 2 of 2 CD results in an install menu which when you select the tools/books option a message
--
Line 214
Error: %1 is not a valid Win32 application
--
Trying to run individual setup .msi's generally result in
--
The installation package is not supported by the processor type. Contact your product vendor.
--
Media Info - Build 1033.
Disks dated December 2005
End Item Part No 228-05237
Cheers
Julian
|||I dug into this a little more...An x86 installer was not package with the Intel 64-bit processor media. At this point, your best option would be to obtain SQL Express Manager from the download center -- http://msdn.microsoft.com/vstudio/express/sql/default.aspx
Thanks,
Peter
|||Thanks again Peter,
I had already done so - however this does not give me import/export functionality remotely (and probably many many tools).
I will investigate with my vendor - but is there not other way to get access to the 32 tools?
Cheers,
Julian
|||We are investigating to determine the best way to resolve.
As a short-term solution you can use the evaluation edition: http://www.microsoft.com/sql/downloads/trial-software.mspx
Thanks,
Peter
32-64 bit versions issue
I uninstalled the 32-bit Standard version but during install of the 64-bit trial version I got an error that the integration services could not install because the 32-bit version of COM+ was already registered and you can't have both. Need some help how to resolve this issue. Thanks
I suspect there is a conflict, I always format partitions and reload from a Ghost backup when trying stuff out. Might need to check to see where the 32-bit version installed some extras that did not get removed with uninstall.
I document every step when I set up a machine, so I can learn from problems and how to avoid them in the future.
|||OK, make sense. Now, how to fix it? Manually unregister? Thanks|||That might work, but I found it was more expedient making a hard disk full of backups and being able to roll back has so many advantages.
32 bit?
I know this is probably the wrong forum, but is windows
2003 64-bit or 32-bit? What about Yukon?
Windows 2003 has both 32-bit and 64-bit versions, as does SQLServer 2000.
The same will apply to Yukon.
David Portas
SQL Server MVP
|||How do you determine what version has been configured?
>--Original Message--
>Windows 2003 has both 32-bit and 64-bit versions, as
does SQLServer 2000.
>The same will apply to Yukon.
>--
>David Portas
>SQL Server MVP
>--
>
>.
>
|||Hi Marc
It's not a matter of configuration. The 64-bit versions are entirely
separate products. If you had purchased a 64-bit version, you would know it.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"marc" <anonymous@.discussions.microsoft.com> wrote in message
news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...[vbcol=seagreen]
> How do you determine what version has been configured?
> does SQLServer 2000.
|||I see, that obvious..
I know this is going to sound real stupid, but why would
one choose one over the other? We've just installed
Windows 2003 intended for SQL 2000. On what basis do you
make the call, 32 or 64?
>--Original Message--
>Hi Marc
>It's not a matter of configuration. The 64-bit versions
are entirely
>separate products. If you had purchased a 64-bit
version, you would know it.
>--
>HTH
>--
>Kalen Delaney
>SQL Server MVP
>www.SolidQualityLearning.com
>
>"marc" <anonymous@.discussions.microsoft.com> wrote in
message
>news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...
>
>.
>
|||64-bit apps require 64-bit hardware such as a server based on Intel's
Itanium processor. The benefits are performance and high-end scalability but
there is obviously significant extra cost involved too.
SQLServer 32-bit is still a very powerful, scalable database on the right
hardware, capable of supporting thousands of users and many Terabytes of
data so the chances are that it is more than capable of doing what you
require. If your operation was of a scale that you would benefit from the
64-bit version then you would know about it.
Hope this answers your question.
David Portas
SQL Server MVP
|||There are 64-bit Windows. There is a Windows XP 64-bit and a Wndows =
2003 64-bit. But there are also 32-bit for each of them as well. =
Regrettably neither are 16-bit.
As for Yukon not sure but note 64-bit will not run on 32-bit and 32-bit =
will not run on 64-bit except as an emulated application. Sort of like =
running a 16-bit application in Win32 or like running a 32-bit in Win16 =
aka Win32S.
--=20
George Hester
__________________________________
"marc" <anonymous@.discussions.microsoft.com> wrote in message =
news:215bb01c45b6e$bbc9ef00$a601280a@.phx.gbl...
> I know this is probably the wrong forum, but is windows=20
> 2003 64-bit or 32-bit? What about Yukon?
2003 64-bit or 32-bit? What about Yukon?
Windows 2003 has both 32-bit and 64-bit versions, as does SQLServer 2000.
The same will apply to Yukon.
David Portas
SQL Server MVP
|||How do you determine what version has been configured?
>--Original Message--
>Windows 2003 has both 32-bit and 64-bit versions, as
does SQLServer 2000.
>The same will apply to Yukon.
>--
>David Portas
>SQL Server MVP
>--
>
>.
>
|||Hi Marc
It's not a matter of configuration. The 64-bit versions are entirely
separate products. If you had purchased a 64-bit version, you would know it.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"marc" <anonymous@.discussions.microsoft.com> wrote in message
news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...[vbcol=seagreen]
> How do you determine what version has been configured?
> does SQLServer 2000.
|||I see, that obvious..
I know this is going to sound real stupid, but why would
one choose one over the other? We've just installed
Windows 2003 intended for SQL 2000. On what basis do you
make the call, 32 or 64?
>--Original Message--
>Hi Marc
>It's not a matter of configuration. The 64-bit versions
are entirely
>separate products. If you had purchased a 64-bit
version, you would know it.
>--
>HTH
>--
>Kalen Delaney
>SQL Server MVP
>www.SolidQualityLearning.com
>
>"marc" <anonymous@.discussions.microsoft.com> wrote in
message
>news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...
>
>.
>
|||64-bit apps require 64-bit hardware such as a server based on Intel's
Itanium processor. The benefits are performance and high-end scalability but
there is obviously significant extra cost involved too.
SQLServer 32-bit is still a very powerful, scalable database on the right
hardware, capable of supporting thousands of users and many Terabytes of
data so the chances are that it is more than capable of doing what you
require. If your operation was of a scale that you would benefit from the
64-bit version then you would know about it.
Hope this answers your question.
David Portas
SQL Server MVP
|||There are 64-bit Windows. There is a Windows XP 64-bit and a Wndows =
2003 64-bit. But there are also 32-bit for each of them as well. =
Regrettably neither are 16-bit.
As for Yukon not sure but note 64-bit will not run on 32-bit and 32-bit =
will not run on 64-bit except as an emulated application. Sort of like =
running a 16-bit application in Win32 or like running a 32-bit in Win16 =
aka Win32S.
--=20
George Hester
__________________________________
"marc" <anonymous@.discussions.microsoft.com> wrote in message =
news:215bb01c45b6e$bbc9ef00$a601280a@.phx.gbl...
> I know this is probably the wrong forum, but is windows=20
> 2003 64-bit or 32-bit? What about Yukon?
32 bit?
I know this is probably the wrong forum, but is windows
2003 64-bit or 32-bit? What about Yukon?Windows 2003 has both 32-bit and 64-bit versions, as does SQLServer 2000.
The same will apply to Yukon.
--
David Portas
SQL Server MVP
--|||How do you determine what version has been configured?
>--Original Message--
>Windows 2003 has both 32-bit and 64-bit versions, as
does SQLServer 2000.
>The same will apply to Yukon.
>--
>David Portas
>SQL Server MVP
>--
>
>.
>|||Hi Marc
It's not a matter of configuration. The 64-bit versions are entirely
separate products. If you had purchased a 64-bit version, you would know it.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"marc" <anonymous@.discussions.microsoft.com> wrote in message
news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...
> How do you determine what version has been configured?
> >--Original Message--
> >Windows 2003 has both 32-bit and 64-bit versions, as
> does SQLServer 2000.
> >The same will apply to Yukon.
> >
> >--
> >David Portas
> >SQL Server MVP
> >--
> >
> >
> >.
> >|||I see, that obvious..
I know this is going to sound real stupid, but why would
one choose one over the other? We've just installed
Windows 2003 intended for SQL 2000. On what basis do you
make the call, 32 or 64?
>--Original Message--
>Hi Marc
>It's not a matter of configuration. The 64-bit versions
are entirely
>separate products. If you had purchased a 64-bit
version, you would know it.
>--
>HTH
>--
>Kalen Delaney
>SQL Server MVP
>www.SolidQualityLearning.com
>
>"marc" <anonymous@.discussions.microsoft.com> wrote in
message
>news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...
>> How do you determine what version has been configured?
>> >--Original Message--
>> >Windows 2003 has both 32-bit and 64-bit versions, as
>> does SQLServer 2000.
>> >The same will apply to Yukon.
>> >
>> >--
>> >David Portas
>> >SQL Server MVP
>> >--
>> >
>> >
>> >.
>> >
>
>.
>|||64-bit apps require 64-bit hardware such as a server based on Intel's
Itanium processor. The benefits are performance and high-end scalability but
there is obviously significant extra cost involved too.
SQLServer 32-bit is still a very powerful, scalable database on the right
hardware, capable of supporting thousands of users and many Terabytes of
data so the chances are that it is more than capable of doing what you
require. If your operation was of a scale that you would benefit from the
64-bit version then you would know about it.
Hope this answers your question.
--
David Portas
SQL Server MVP
--|||There are 64-bit Windows. There is a Windows XP 64-bit and a Wndows =2003 64-bit. But there are also 32-bit for each of them as well. =Regrettably neither are 16-bit.
As for Yukon not sure but note 64-bit will not run on 32-bit and 32-bit =will not run on 64-bit except as an emulated application. Sort of like =running a 16-bit application in Win32 or like running a 32-bit in Win16 =aka Win32S.
-- George Hester
__________________________________
"marc" <anonymous@.discussions.microsoft.com> wrote in message =news:215bb01c45b6e$bbc9ef00$a601280a@.phx.gbl...
> I know this is probably the wrong forum, but is windows > 2003 64-bit or 32-bit? What about Yukon?sql
2003 64-bit or 32-bit? What about Yukon?Windows 2003 has both 32-bit and 64-bit versions, as does SQLServer 2000.
The same will apply to Yukon.
--
David Portas
SQL Server MVP
--|||How do you determine what version has been configured?
>--Original Message--
>Windows 2003 has both 32-bit and 64-bit versions, as
does SQLServer 2000.
>The same will apply to Yukon.
>--
>David Portas
>SQL Server MVP
>--
>
>.
>|||Hi Marc
It's not a matter of configuration. The 64-bit versions are entirely
separate products. If you had purchased a 64-bit version, you would know it.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"marc" <anonymous@.discussions.microsoft.com> wrote in message
news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...
> How do you determine what version has been configured?
> >--Original Message--
> >Windows 2003 has both 32-bit and 64-bit versions, as
> does SQLServer 2000.
> >The same will apply to Yukon.
> >
> >--
> >David Portas
> >SQL Server MVP
> >--
> >
> >
> >.
> >|||I see, that obvious..
I know this is going to sound real stupid, but why would
one choose one over the other? We've just installed
Windows 2003 intended for SQL 2000. On what basis do you
make the call, 32 or 64?
>--Original Message--
>Hi Marc
>It's not a matter of configuration. The 64-bit versions
are entirely
>separate products. If you had purchased a 64-bit
version, you would know it.
>--
>HTH
>--
>Kalen Delaney
>SQL Server MVP
>www.SolidQualityLearning.com
>
>"marc" <anonymous@.discussions.microsoft.com> wrote in
message
>news:21bed01c45b73$560ebe70$a101280a@.phx.gbl...
>> How do you determine what version has been configured?
>> >--Original Message--
>> >Windows 2003 has both 32-bit and 64-bit versions, as
>> does SQLServer 2000.
>> >The same will apply to Yukon.
>> >
>> >--
>> >David Portas
>> >SQL Server MVP
>> >--
>> >
>> >
>> >.
>> >
>
>.
>|||64-bit apps require 64-bit hardware such as a server based on Intel's
Itanium processor. The benefits are performance and high-end scalability but
there is obviously significant extra cost involved too.
SQLServer 32-bit is still a very powerful, scalable database on the right
hardware, capable of supporting thousands of users and many Terabytes of
data so the chances are that it is more than capable of doing what you
require. If your operation was of a scale that you would benefit from the
64-bit version then you would know about it.
Hope this answers your question.
--
David Portas
SQL Server MVP
--|||There are 64-bit Windows. There is a Windows XP 64-bit and a Wndows =2003 64-bit. But there are also 32-bit for each of them as well. =Regrettably neither are 16-bit.
As for Yukon not sure but note 64-bit will not run on 32-bit and 32-bit =will not run on 64-bit except as an emulated application. Sort of like =running a 16-bit application in Win32 or like running a 32-bit in Win16 =aka Win32S.
-- George Hester
__________________________________
"marc" <anonymous@.discussions.microsoft.com> wrote in message =news:215bb01c45b6e$bbc9ef00$a601280a@.phx.gbl...
> I know this is probably the wrong forum, but is windows > 2003 64-bit or 32-bit? What about Yukon?sql
32 bit?
I know this is probably the wrong forum, but is windows
2003 64-bit or 32-bit? What about Yukon?Windows 2003 has both 32-bit and 64-bit versions, as does SQLServer 2000.
The same will apply to Yukon.
David Portas
SQL Server MVP
--|||How do you determine what version has been configured?
>--Original Message--
>Windows 2003 has both 32-bit and 64-bit versions, as
does SQLServer 2000.
>The same will apply to Yukon.
>--
>David Portas
>SQL Server MVP
>--
>
>.
>|||Hi Marc
It's not a matter of configuration. The 64-bit versions are entirely
separate products. If you had purchased a 64-bit version, you would know it.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"marc" <anonymous@.discussions.microsoft.com> wrote in message
news:21bed01c45b73$560ebe70$a101280a@.phx
.gbl...[vbcol=seagreen]
> How do you determine what version has been configured?
> does SQLServer 2000.|||I see, that obvious..
I know this is going to sound real stupid, but why would
one choose one over the other? We've just installed
Windows 2003 intended for SQL 2000. On what basis do you
make the call, 32 or 64?
>--Original Message--
>Hi Marc
>It's not a matter of configuration. The 64-bit versions
are entirely
>separate products. If you had purchased a 64-bit
version, you would know it.
>--
>HTH
>--
>Kalen Delaney
>SQL Server MVP
>www.SolidQualityLearning.com
>
>"marc" <anonymous@.discussions.microsoft.com> wrote in
message
> news:21bed01c45b73$560ebe70$a101280a@.phx
.gbl...
>
>.
>|||64-bit apps require 64-bit hardware such as a server based on Intel's
Itanium processor. The benefits are performance and high-end scalability but
there is obviously significant extra cost involved too.
SQLServer 32-bit is still a very powerful, scalable database on the right
hardware, capable of supporting thousands of users and many Terabytes of
data so the chances are that it is more than capable of doing what you
require. If your operation was of a scale that you would benefit from the
64-bit version then you would know about it.
Hope this answers your question.
David Portas
SQL Server MVP
--|||There are 64-bit Windows. There is a Windows XP 64-bit and a Wndows =
2003 64-bit. But there are also 32-bit for each of them as well. =
Regrettably neither are 16-bit.
As for Yukon not sure but note 64-bit will not run on 32-bit and 32-bit =
will not run on 64-bit except as an emulated application. Sort of like =
running a 16-bit application in Win32 or like running a 32-bit in Win16 =
aka Win32S.
--=20
George Hester
__________________________________
"marc" <anonymous@.discussions.microsoft.com> wrote in message =
news:215bb01c45b6e$bbc9ef00$a601280a@.phx
.gbl...
> I know this is probably the wrong forum, but is windows=20
> 2003 64-bit or 32-bit? What about Yukon?
2003 64-bit or 32-bit? What about Yukon?Windows 2003 has both 32-bit and 64-bit versions, as does SQLServer 2000.
The same will apply to Yukon.
David Portas
SQL Server MVP
--|||How do you determine what version has been configured?
>--Original Message--
>Windows 2003 has both 32-bit and 64-bit versions, as
does SQLServer 2000.
>The same will apply to Yukon.
>--
>David Portas
>SQL Server MVP
>--
>
>.
>|||Hi Marc
It's not a matter of configuration. The 64-bit versions are entirely
separate products. If you had purchased a 64-bit version, you would know it.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"marc" <anonymous@.discussions.microsoft.com> wrote in message
news:21bed01c45b73$560ebe70$a101280a@.phx
.gbl...[vbcol=seagreen]
> How do you determine what version has been configured?
> does SQLServer 2000.|||I see, that obvious..
I know this is going to sound real stupid, but why would
one choose one over the other? We've just installed
Windows 2003 intended for SQL 2000. On what basis do you
make the call, 32 or 64?
>--Original Message--
>Hi Marc
>It's not a matter of configuration. The 64-bit versions
are entirely
>separate products. If you had purchased a 64-bit
version, you would know it.
>--
>HTH
>--
>Kalen Delaney
>SQL Server MVP
>www.SolidQualityLearning.com
>
>"marc" <anonymous@.discussions.microsoft.com> wrote in
message
> news:21bed01c45b73$560ebe70$a101280a@.phx
.gbl...
>
>.
>|||64-bit apps require 64-bit hardware such as a server based on Intel's
Itanium processor. The benefits are performance and high-end scalability but
there is obviously significant extra cost involved too.
SQLServer 32-bit is still a very powerful, scalable database on the right
hardware, capable of supporting thousands of users and many Terabytes of
data so the chances are that it is more than capable of doing what you
require. If your operation was of a scale that you would benefit from the
64-bit version then you would know about it.
Hope this answers your question.
David Portas
SQL Server MVP
--|||There are 64-bit Windows. There is a Windows XP 64-bit and a Wndows =
2003 64-bit. But there are also 32-bit for each of them as well. =
Regrettably neither are 16-bit.
As for Yukon not sure but note 64-bit will not run on 32-bit and 32-bit =
will not run on 64-bit except as an emulated application. Sort of like =
running a 16-bit application in Win32 or like running a 32-bit in Win16 =
aka Win32S.
--=20
George Hester
__________________________________
"marc" <anonymous@.discussions.microsoft.com> wrote in message =
news:215bb01c45b6e$bbc9ef00$a601280a@.phx
.gbl...
> I know this is probably the wrong forum, but is windows=20
> 2003 64-bit or 32-bit? What about Yukon?
32 bit XPs on 64bit?
We've got two Extended Proceedures that work fine on 32bit, no bugs and
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/techn...l
t.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/techn...l
t.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David
32 bit XPs on 64bit?
We've got two Extended Proceedures that work fine on 32bit, no bugs and
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!
"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/techno...q/default.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!
"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/techno...q/default.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David
32 bit XPs on 64bit?
We've got two Extended Proceedures that work fine on 32bit, no bugs and
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/technology/64bitwindows/x64faq/developmentfaq/default.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David
never AVed the server.
We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
2005 64bit.
Will these 32bit XPs work fine without change in SQL 64? Or will a simple
recompile with a 64bit compiler make it work in SQL 64bit?
Yeah Yeah Yeah, I know all about CLR in Yukon, I'm not asking that question!"Bud Y. Zer" <bud@.Gibralter.Bra> wrote in message
news:%23$8V4LzrFHA.248@.TK2MSFTNGP14.phx.gbl...
> We've got two Extended Proceedures that work fine on 32bit, no bugs and
> never AVed the server.
> We are about to move to SQL Server 2000 64 bit, and will also evaluate SQL
> 2005 64bit.
> Will these 32bit XPs work fine without change in SQL 64?
No. Extended stored procedures are dll's loaded into the SQL Server process,
and a 64bit process can only load 64bit dll's.
>Or will a simple recompile with a 64bit compiler make it work in SQL
>64bit?
It depends on how the dll's are written.
See generally,
http://msdn.microsoft.com/isv/technology/64bitwindows/x64faq/developmentfaq/default.aspx
There are things you can do in C++ which implicity rely on pointers being
32bits.
David
32 bit vs. 64 bit options
We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
Windows 2003.
We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
Server Memory set to 6144.
After a recent application upgrade, we were running into memory pressure due
to limited space in VAS. Our buffer pool remained in good shape. We increased
VAS from 256 to 512 and we are no longer having any issues.
During this troubleshooting period, we began toying with the idea of moving
from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
process of being set up. With the same 8GB RAM on the proposed 64 bit server,
is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
What is the default size of VAS in 64 bit?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
/3gb and AWE is no longer required with x64
max memory option still here.
Windows x64 is required.
and sure, x64 version is really helpful for the memory management.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
|||> What is the default size of VAS in 64 bit?
The user mode addressable space is 8TB.
Linchi
"cbrichards via droptable.com" wrote:
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure due
> to limited space in VAS. Our buffer pool remained in good shape. We increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
|||If you were running into VAS issues you must be running apps other than SQL
Server on the same server. If this is the case you should always leave
enough free memory for those other apps. The problem with 32 bit and AWE is
that it is not dynamic so when the other app or the OS needs more than the
2GB left you are forced to page. With x64 bit it can be dynamic and there is
no need for AWE or /3GB. But that still won't get around the issue that you
probably need more memory for the other apps.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
|||You are correct Andrew, the VAS issues came into play when we deployed CLR.
To clarify my understanding then, with 64 bit, when I have 8GB RAM, and Max
Server Memory = 6144:
1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic, does
it then borrow from the 6GB in the buffer pool?
2. Regarding the VAS issues, in 32 bit the resolution was to increase the
default MemToLeave from 256 to 512 using startup parameter -g. Is this
startup parameter still needed in 64 bit, or in other words, is 256 still the
default in 64 bit?
Andrew J. Kelly wrote:[vbcol=seagreen]
>If you were running into VAS issues you must be running apps other than SQL
>Server on the same server. If this is the case you should always leave
>enough free memory for those other apps. The problem with 32 bit and AWE is
>that it is not dynamic so when the other app or the OS needs more than the
>2GB left you are forced to page. With x64 bit it can be dynamic and there is
>no need for AWE or /3GB. But that still won't get around the issue that you
>probably need more memory for the other apps.
>[quoted text clipped - 19 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
|||OK you have VAS confused with MemToLeave. The - g option is for MemToLeave
and not VAS. MemToLeave is for allocations that require more than 8K of
contiguous memory. I can see where the CLR would require more MemToLeave
than the default.
See if this helps:
http://blogs.msdn.com/khen1234/archive/2005/10/12/480292.aspx
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71e09d8645e08@.uwe...
> You are correct Andrew, the VAS issues came into play when we deployed
> CLR.
> To clarify my understanding then, with 64 bit, when I have 8GB RAM, and
> Max
> Server Memory = 6144:
> 1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic,
> does
> it then borrow from the 6GB in the buffer pool?
> 2. Regarding the VAS issues, in 32 bit the resolution was to increase the
> default MemToLeave from 256 to 512 using startup parameter -g. Is this
> startup parameter still needed in 64 bit, or in other words, is 256 still
> the
> default in 64 bit?
> Andrew J. Kelly wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
sql
Windows 2003.
We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
Server Memory set to 6144.
After a recent application upgrade, we were running into memory pressure due
to limited space in VAS. Our buffer pool remained in good shape. We increased
VAS from 256 to 512 and we are no longer having any issues.
During this troubleshooting period, we began toying with the idea of moving
from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
process of being set up. With the same 8GB RAM on the proposed 64 bit server,
is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
What is the default size of VAS in 64 bit?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
/3gb and AWE is no longer required with x64
max memory option still here.
Windows x64 is required.
and sure, x64 version is really helpful for the memory management.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
|||> What is the default size of VAS in 64 bit?
The user mode addressable space is 8TB.
Linchi
"cbrichards via droptable.com" wrote:
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure due
> to limited space in VAS. Our buffer pool remained in good shape. We increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
|||If you were running into VAS issues you must be running apps other than SQL
Server on the same server. If this is the case you should always leave
enough free memory for those other apps. The problem with 32 bit and AWE is
that it is not dynamic so when the other app or the OS needs more than the
2GB left you are forced to page. With x64 bit it can be dynamic and there is
no need for AWE or /3GB. But that still won't get around the issue that you
probably need more memory for the other apps.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
|||You are correct Andrew, the VAS issues came into play when we deployed CLR.
To clarify my understanding then, with 64 bit, when I have 8GB RAM, and Max
Server Memory = 6144:
1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic, does
it then borrow from the 6GB in the buffer pool?
2. Regarding the VAS issues, in 32 bit the resolution was to increase the
default MemToLeave from 256 to 512 using startup parameter -g. Is this
startup parameter still needed in 64 bit, or in other words, is 256 still the
default in 64 bit?
Andrew J. Kelly wrote:[vbcol=seagreen]
>If you were running into VAS issues you must be running apps other than SQL
>Server on the same server. If this is the case you should always leave
>enough free memory for those other apps. The problem with 32 bit and AWE is
>that it is not dynamic so when the other app or the OS needs more than the
>2GB left you are forced to page. With x64 bit it can be dynamic and there is
>no need for AWE or /3GB. But that still won't get around the issue that you
>probably need more memory for the other apps.
>[quoted text clipped - 19 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
|||OK you have VAS confused with MemToLeave. The - g option is for MemToLeave
and not VAS. MemToLeave is for allocations that require more than 8K of
contiguous memory. I can see where the CLR would require more MemToLeave
than the default.
See if this helps:
http://blogs.msdn.com/khen1234/archive/2005/10/12/480292.aspx
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71e09d8645e08@.uwe...
> You are correct Andrew, the VAS issues came into play when we deployed
> CLR.
> To clarify my understanding then, with 64 bit, when I have 8GB RAM, and
> Max
> Server Memory = 6144:
> 1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic,
> does
> it then borrow from the 6GB in the buffer pool?
> 2. Regarding the VAS issues, in 32 bit the resolution was to increase the
> default MemToLeave from 256 to 512 using startup parameter -g. Is this
> startup parameter still needed in 64 bit, or in other words, is 256 still
> the
> default in 64 bit?
> Andrew J. Kelly wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200705/1
>
sql
32 bit vs. 64 bit options
We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
Windows 2003.
We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
Server Memory set to 6144.
After a recent application upgrade, we were running into memory pressure due
to limited space in VAS. Our buffer pool remained in good shape. We increased
VAS from 256 to 512 and we are no longer having any issues.
During this troubleshooting period, we began toying with the idea of moving
from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
process of being set up. With the same 8GB RAM on the proposed 64 bit server,
is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
What is the default size of VAS in 64 bit?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1/3gb and AWE is no longer required with x64
max memory option still here.
Windows x64 is required.
and sure, x64 version is really helpful for the memory management.
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>|||> What is the default size of VAS in 64 bit?
The user mode addressable space is 8TB.
Linchi
"cbrichards via SQLMonster.com" wrote:
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure due
> to limited space in VAS. Our buffer pool remained in good shape. We increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>|||If you were running into VAS issues you must be running apps other than SQL
Server on the same server. If this is the case you should always leave
enough free memory for those other apps. The problem with 32 bit and AWE is
that it is not dynamic so when the other app or the OS needs more than the
2GB left you are forced to page. With x64 bit it can be dynamic and there is
no need for AWE or /3GB. But that still won't get around the issue that you
probably need more memory for the other apps.
--
Andrew J. Kelly SQL MVP
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>|||You are correct Andrew, the VAS issues came into play when we deployed CLR.
To clarify my understanding then, with 64 bit, when I have 8GB RAM, and Max
Server Memory = 6144:
1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic, does
it then borrow from the 6GB in the buffer pool?
2. Regarding the VAS issues, in 32 bit the resolution was to increase the
default MemToLeave from 256 to 512 using startup parameter -g. Is this
startup parameter still needed in 64 bit, or in other words, is 256 still the
default in 64 bit?
Andrew J. Kelly wrote:
>If you were running into VAS issues you must be running apps other than SQL
>Server on the same server. If this is the case you should always leave
>enough free memory for those other apps. The problem with 32 bit and AWE is
>that it is not dynamic so when the other app or the OS needs more than the
>2GB left you are forced to page. With x64 bit it can be dynamic and there is
>no need for AWE or /3GB. But that still won't get around the issue that you
>probably need more memory for the other apps.
>> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
>> Windows 2003.
>[quoted text clipped - 19 lines]
>> necessary?
>> What is the default size of VAS in 64 bit?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1|||OK you have VAS confused with MemToLeave. The - g option is for MemToLeave
and not VAS. MemToLeave is for allocations that require more than 8K of
contiguous memory. I can see where the CLR would require more MemToLeave
than the default.
See if this helps:
http://blogs.msdn.com/khen1234/archive/2005/10/12/480292.aspx
Andrew J. Kelly SQL MVP
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:71e09d8645e08@.uwe...
> You are correct Andrew, the VAS issues came into play when we deployed
> CLR.
> To clarify my understanding then, with 64 bit, when I have 8GB RAM, and
> Max
> Server Memory = 6144:
> 1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic,
> does
> it then borrow from the 6GB in the buffer pool?
> 2. Regarding the VAS issues, in 32 bit the resolution was to increase the
> default MemToLeave from 256 to 512 using startup parameter -g. Is this
> startup parameter still needed in 64 bit, or in other words, is 256 still
> the
> default in 64 bit?
> Andrew J. Kelly wrote:
>>If you were running into VAS issues you must be running apps other than
>>SQL
>>Server on the same server. If this is the case you should always leave
>>enough free memory for those other apps. The problem with 32 bit and AWE
>>is
>>that it is not dynamic so when the other app or the OS needs more than the
>>2GB left you are forced to page. With x64 bit it can be dynamic and there
>>is
>>no need for AWE or /3GB. But that still won't get around the issue that
>>you
>>probably need more memory for the other apps.
>> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2,
>> on
>> Windows 2003.
>>[quoted text clipped - 19 lines]
>> necessary?
>> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>
Windows 2003.
We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
Server Memory set to 6144.
After a recent application upgrade, we were running into memory pressure due
to limited space in VAS. Our buffer pool remained in good shape. We increased
VAS from 256 to 512 and we are no longer having any issues.
During this troubleshooting period, we began toying with the idea of moving
from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
process of being set up. With the same 8GB RAM on the proposed 64 bit server,
is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
What is the default size of VAS in 64 bit?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1/3gb and AWE is no longer required with x64
max memory option still here.
Windows x64 is required.
and sure, x64 version is really helpful for the memory management.
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>|||> What is the default size of VAS in 64 bit?
The user mode addressable space is 8TB.
Linchi
"cbrichards via SQLMonster.com" wrote:
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure due
> to limited space in VAS. Our buffer pool remained in good shape. We increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>|||If you were running into VAS issues you must be running apps other than SQL
Server on the same server. If this is the case you should always leave
enough free memory for those other apps. The problem with 32 bit and AWE is
that it is not dynamic so when the other app or the OS needs more than the
2GB left you are forced to page. With x64 bit it can be dynamic and there is
no need for AWE or /3GB. But that still won't get around the issue that you
probably need more memory for the other apps.
--
Andrew J. Kelly SQL MVP
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>|||You are correct Andrew, the VAS issues came into play when we deployed CLR.
To clarify my understanding then, with 64 bit, when I have 8GB RAM, and Max
Server Memory = 6144:
1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic, does
it then borrow from the 6GB in the buffer pool?
2. Regarding the VAS issues, in 32 bit the resolution was to increase the
default MemToLeave from 256 to 512 using startup parameter -g. Is this
startup parameter still needed in 64 bit, or in other words, is 256 still the
default in 64 bit?
Andrew J. Kelly wrote:
>If you were running into VAS issues you must be running apps other than SQL
>Server on the same server. If this is the case you should always leave
>enough free memory for those other apps. The problem with 32 bit and AWE is
>that it is not dynamic so when the other app or the OS needs more than the
>2GB left you are forced to page. With x64 bit it can be dynamic and there is
>no need for AWE or /3GB. But that still won't get around the issue that you
>probably need more memory for the other apps.
>> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
>> Windows 2003.
>[quoted text clipped - 19 lines]
>> necessary?
>> What is the default size of VAS in 64 bit?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1|||OK you have VAS confused with MemToLeave. The - g option is for MemToLeave
and not VAS. MemToLeave is for allocations that require more than 8K of
contiguous memory. I can see where the CLR would require more MemToLeave
than the default.
See if this helps:
http://blogs.msdn.com/khen1234/archive/2005/10/12/480292.aspx
Andrew J. Kelly SQL MVP
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:71e09d8645e08@.uwe...
> You are correct Andrew, the VAS issues came into play when we deployed
> CLR.
> To clarify my understanding then, with 64 bit, when I have 8GB RAM, and
> Max
> Server Memory = 6144:
> 1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic,
> does
> it then borrow from the 6GB in the buffer pool?
> 2. Regarding the VAS issues, in 32 bit the resolution was to increase the
> default MemToLeave from 256 to 512 using startup parameter -g. Is this
> startup parameter still needed in 64 bit, or in other words, is 256 still
> the
> default in 64 bit?
> Andrew J. Kelly wrote:
>>If you were running into VAS issues you must be running apps other than
>>SQL
>>Server on the same server. If this is the case you should always leave
>>enough free memory for those other apps. The problem with 32 bit and AWE
>>is
>>that it is not dynamic so when the other app or the OS needs more than the
>>2GB left you are forced to page. With x64 bit it can be dynamic and there
>>is
>>no need for AWE or /3GB. But that still won't get around the issue that
>>you
>>probably need more memory for the other apps.
>> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2,
>> on
>> Windows 2003.
>>[quoted text clipped - 19 lines]
>> necessary?
>> What is the default size of VAS in 64 bit?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200705/1
>
32 bit vs. 64 bit options
We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
Windows 2003.
We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Ma
x
Server Memory set to 6144.
After a recent application upgrade, we were running into memory pressure due
to limited space in VAS. Our buffer pool remained in good shape. We increase
d
VAS from 256 to 512 and we are no longer having any issues.
During this troubleshooting period, we began toying with the idea of moving
from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
process of being set up. With the same 8GB RAM on the proposed 64 bit server
,
is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary
?
What is the default size of VAS in 64 bit?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200705/1/3gb and AWE is no longer required with x64
max memory option still here.
Windows x64 is required.
and sure, x64 version is really helpful for the memory management.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>|||> What is the default size of VAS in 64 bit?
The user mode addressable space is 8TB.
Linchi
"cbrichards via droptable.com" wrote:
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure d
ue
> to limited space in VAS. Our buffer pool remained in good shape. We increa
sed
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of movin
g
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit serv
er,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE, M
ax
> Server Memory) remain the same in 64 bit? Is the /3GB switch still necessa
ry?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>|||If you were running into VAS issues you must be running apps other than SQL
Server on the same server. If this is the case you should always leave
enough free memory for those other apps. The problem with 32 bit and AWE is
that it is not dynamic so when the other app or the OS needs more than the
2GB left you are forced to page. With x64 bit it can be dynamic and there is
no need for AWE or /3GB. But that still won't get around the issue that you
probably need more memory for the other apps.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>|||You are correct Andrew, the VAS issues came into play when we deployed CLR.
To clarify my understanding then, with 64 bit, when I have 8GB RAM, and Max
Server Memory = 6144:
1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic, doe
s
it then borrow from the 6GB in the buffer pool?
2. Regarding the VAS issues, in 32 bit the resolution was to increase the
default MemToLeave from 256 to 512 using startup parameter -g. Is this
startup parameter still needed in 64 bit, or in other words, is 256 still th
e
default in 64 bit?
Andrew J. Kelly wrote:[vbcol=seagreen]
>If you were running into VAS issues you must be running apps other than SQL
>Server on the same server. If this is the case you should always leave
>enough free memory for those other apps. The problem with 32 bit and AWE i
s
>that it is not dynamic so when the other app or the OS needs more than the
>2GB left you are forced to page. With x64 bit it can be dynamic and there i
s
>no need for AWE or /3GB. But that still won't get around the issue that yo
u
>probably need more memory for the other apps.
>
>[quoted text clipped - 19 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200705/1|||OK you have VAS confused with MemToLeave. The - g option is for MemToLeave
and not VAS. MemToLeave is for allocations that require more than 8K of
contiguous memory. I can see where the CLR would require more MemToLeave
than the default.
See if this helps:
http://blogs.msdn.com/khen1234/arch.../12/480292.aspx
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71e09d8645e08@.uwe...
> You are correct Andrew, the VAS issues came into play when we deployed
> CLR.
> To clarify my understanding then, with 64 bit, when I have 8GB RAM, and
> Max
> Server Memory = 6144:
> 1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic,
> does
> it then borrow from the 6GB in the buffer pool?
> 2. Regarding the VAS issues, in 32 bit the resolution was to increase the
> default MemToLeave from 256 to 512 using startup parameter -g. Is this
> startup parameter still needed in 64 bit, or in other words, is 256 still
> the
> default in 64 bit?
> Andrew J. Kelly wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>
Windows 2003.
We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and Ma
x
Server Memory set to 6144.
After a recent application upgrade, we were running into memory pressure due
to limited space in VAS. Our buffer pool remained in good shape. We increase
d
VAS from 256 to 512 and we are no longer having any issues.
During this troubleshooting period, we began toying with the idea of moving
from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
process of being set up. With the same 8GB RAM on the proposed 64 bit server
,
is it desirable to have the sp_Configure options in 32 bit (such as AWE, Max
Server Memory) remain the same in 64 bit? Is the /3GB switch still necessary
?
What is the default size of VAS in 64 bit?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200705/1/3gb and AWE is no longer required with x64
max memory option still here.
Windows x64 is required.
and sure, x64 version is really helpful for the memory management.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>|||> What is the default size of VAS in 64 bit?
The user mode addressable space is 8TB.
Linchi
"cbrichards via droptable.com" wrote:
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure d
ue
> to limited space in VAS. Our buffer pool remained in good shape. We increa
sed
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of movin
g
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit serv
er,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE, M
ax
> Server Memory) remain the same in 64 bit? Is the /3GB switch still necessa
ry?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>|||If you were running into VAS issues you must be running apps other than SQL
Server on the same server. If this is the case you should always leave
enough free memory for those other apps. The problem with 32 bit and AWE is
that it is not dynamic so when the other app or the OS needs more than the
2GB left you are forced to page. With x64 bit it can be dynamic and there is
no need for AWE or /3GB. But that still won't get around the issue that you
probably need more memory for the other apps.
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71d7704e288d2@.uwe...
> We are currently running 32 bit SQL Server 2005, Standard Edition, SP2, on
> Windows 2003.
> We have 8GB RAM, with AWE enabled, Lock Pages in Memory, /3GB switch, and
> Max
> Server Memory set to 6144.
> After a recent application upgrade, we were running into memory pressure
> due
> to limited space in VAS. Our buffer pool remained in good shape. We
> increased
> VAS from 256 to 512 and we are no longer having any issues.
> During this troubleshooting period, we began toying with the idea of
> moving
> from SQL Server 32 bit to 64 bit. We have a 64 bit test environment in the
> process of being set up. With the same 8GB RAM on the proposed 64 bit
> server,
> is it desirable to have the sp_Configure options in 32 bit (such as AWE,
> Max
> Server Memory) remain the same in 64 bit? Is the /3GB switch still
> necessary?
> What is the default size of VAS in 64 bit?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>|||You are correct Andrew, the VAS issues came into play when we deployed CLR.
To clarify my understanding then, with 64 bit, when I have 8GB RAM, and Max
Server Memory = 6144:
1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic, doe
s
it then borrow from the 6GB in the buffer pool?
2. Regarding the VAS issues, in 32 bit the resolution was to increase the
default MemToLeave from 256 to 512 using startup parameter -g. Is this
startup parameter still needed in 64 bit, or in other words, is 256 still th
e
default in 64 bit?
Andrew J. Kelly wrote:[vbcol=seagreen]
>If you were running into VAS issues you must be running apps other than SQL
>Server on the same server. If this is the case you should always leave
>enough free memory for those other apps. The problem with 32 bit and AWE i
s
>that it is not dynamic so when the other app or the OS needs more than the
>2GB left you are forced to page. With x64 bit it can be dynamic and there i
s
>no need for AWE or /3GB. But that still won't get around the issue that yo
u
>probably need more memory for the other apps.
>
>[quoted text clipped - 19 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200705/1|||OK you have VAS confused with MemToLeave. The - g option is for MemToLeave
and not VAS. MemToLeave is for allocations that require more than 8K of
contiguous memory. I can see where the CLR would require more MemToLeave
than the default.
See if this helps:
http://blogs.msdn.com/khen1234/arch.../12/480292.aspx
Andrew J. Kelly SQL MVP
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:71e09d8645e08@.uwe...
> You are correct Andrew, the VAS issues came into play when we deployed
> CLR.
> To clarify my understanding then, with 64 bit, when I have 8GB RAM, and
> Max
> Server Memory = 6144:
> 1. If CLR or OS needs more than the 2GB left, then if 64 bit is dynamic,
> does
> it then borrow from the 6GB in the buffer pool?
> 2. Regarding the VAS issues, in 32 bit the resolution was to increase the
> default MemToLeave from 256 to 512 using startup parameter -g. Is this
> startup parameter still needed in 64 bit, or in other words, is 256 still
> the
> default in 64 bit?
> Andrew J. Kelly wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200705/1
>
Subscribe to:
Posts (Atom)