SQL Remove Old Backups: 32bit

Showing posts with label 32bit. Show all posts

Tuesday, March 27, 2012

32bit vs 64bit SQL 2005

Just curious if anyone has any numbers for this.
We have a customer that has their server running windows server 64bit.
But, SQL 2005 loaded on it is only 32bit. What would be the benefits
(speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
increase, or something like that. Or, is there some certain issue when
running the 32bit SQL on 64bit OS that I need to be aware of.
TIA
Darin
*** Sent via Developersdex http://www.codecomments.com ***
The immediate benefit would be an improvement in the accessibility of memory
past 2GB (you wouldn't need to have AWE enabled - and AWE has restrictions
and is slow to deal with compared to normal memory).
I personally wouldn't expect a massive performance difference between 32-bit
vs. 64-bit on a 64-bit box, although 25% might not be unrealistic (have seen
this kind of performance difference with 32-bit Integration Services running
on a 64-bit box).
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I don't know that there can be an explicit across the board answer for this
situation. It probably depends on the load on the server. The more heavily
loaded the server runs the better the 64bit sql server install should
perform.
Kevin G. Boles
Indicium Resources, Inc.
SQL Server MVP
kgboles a earthlink dt net
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||I don't think you can really quantify the performance without actually
running tests in your environment. See
http://blogs.msdn.com/sqlprogrammability/default.aspx.
Hope this helps.
Dan Guzman
SQL Server MVP
"Darin" <darin_nospam@.nospamever> wrote in message
news:u0FNa53WIHA.484@.TK2MSFTNGP06.phx.gbl...
> Just curious if anyone has any numbers for this.
> We have a customer that has their server running windows server 64bit.
> But, SQL 2005 loaded on it is only 32bit. What would be the benefits
> (speed mainly) of upgrading to 64bit SQL - in numbers - like a 25%
> increase, or something like that. Or, is there some certain issue when
> running the 32bit SQL on 64bit OS that I need to be aware of.
> TIA
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***
|||This server is the distributor for 2 replicated subscribers.
One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
is enough reason to upgrade.
All 3 servers have 64bit Windows but are only running 32bit SQL2005.
Also, the distributor has 3GB RAM, one subscriber has 4GB and the other
has 2.93GB RAM. I have told their IT person to put at least 4GB on the
distributor since that is in the main office w/ the most users, and is
handling the replication.
Darin
*** Sent via Developersdex http://www.codecomments.com ***
|||> One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
> is enough reason to upgrade.
Memory in Standard Edition (and above) is limited only by the OS. However,
in 32-bit versions, memory beyond 3GB can be used only for data buffer cache
and is addressable only via AWE. One the the reasons to migrate to 64-bit
is that memory beyond 3GB can be used for other memory needs, like procedure
cache.
Hope this helps.
Dan Guzman
SQL Server MVP
"Darin" <darin_nospam@.nospamever> wrote in message
news:eGsq6P4WIHA.5132@.TK2MSFTNGP02.phx.gbl...
> This server is the distributor for 2 replicated subscribers.
> One question - does 32bit SQL 2005 ONLY use 2GB RAM? If so, that to me
> is enough reason to upgrade.
> All 3 servers have 64bit Windows but are only running 32bit SQL2005.
> Also, the distributor has 3GB RAM, one subscriber has 4GB and the other
> has 2.93GB RAM. I have told their IT person to put at least 4GB on the
> distributor since that is in the main office w/ the most users, and is
> handling the replication.
> Darin
> *** Sent via Developersdex http://www.codecomments.com ***

32bit vs 64bit SQL 2005

Sunday, March 25, 2012

32bit to 64bit Server performance is very poor

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 ar
e
> facing performance related issues....Could any one help me plz?
> Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itani
um
> 2(IA64).
> Regards,
> JaisonDear 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
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 ar
e
> facing performance related issues....Could any one help me plz?
> Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itani
um
> 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:
[vbcol=seagreen]
> 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:
>|||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:
[vbcol=seagreen]
> 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:
>|||Hi Jaison
When you have
http://www.microsoft.com/sql/soluti...ingto64bit.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/pr...on.ms
px 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.c...nce_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/d...>
g64_2ctv.asp and everything is service packed?
John
"Jaison Jose" wrote:
[vbcol=seagreen]
> 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 mov
e a
> 32 bit database to a 64 bit environment, what and all the wright steps tha
t 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:
>|||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 ar
e
> facing performance related issues....Could any one help me plz?
> Previous OS was win2003 EE(X86),Now we are using win2003 EE with SP1,Itani
um
> 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:
[vbcol=seagreen]
> 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-> ) fr
om
> the 32 bit sql server and made it run on 64 bit. And then done a DTS to mo
ve
> 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(Sorr
y,
> 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:
>|||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:
[vbcol=seagreen]
> 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. I
f
> you have auto create stats on for you database then you will have lost the
se.
> Backup/restore should have worked fine when transferring the database as
> well as detach/attach which should be significantly quicker than your meth
od
> so you may want to try it again.
> John
> "Jaison Jose" wrote:
>|||Hi Jaison
When you have
http://www.microsoft.com/sql/soluti...ingto64bit.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/pr...on.ms
px 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.c...nce_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/d...>
g64_2ctv.asp and everything is service packed?
John
"Jaison Jose" wrote:
[vbcol=seagreen]
> 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 mov
e a
> 32 bit database to a 64 bit environment, what and all the wright steps tha
t 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:
>

32bit to 64bit Server performance is very poor

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

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

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

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

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 on 64bit windows?

We have new servers with 16GB RAM. I want the OS and SQL to use as much of it
as possible. I can't put 64bit SQL on the box because the vendor doesn't
support that. Can I install 64bit 2003 and 32bit SQL 2000? If so, will SQL be
able to use all of the memory or just the OS?
Thanks
Roger"Roger" <Roger@.discussions.microsoft.com> wrote in message
news:8796554C-FC5D-44F4-A150-2E867AA9F7AB@.microsoft.com...
> We have new servers with 16GB RAM. I want the OS and SQL to use as much of
> it
> as possible. I can't put 64bit SQL on the box because the vendor doesn't
> support that. Can I install 64bit 2003 and 32bit SQL 2000? If so, will SQL
> be
> able to use all of the memory or just the OS?
>
SQL Server 2000 SP4 is supported on Windows Server 2003 x64 Edition. SQL
Server 2000 Standard Edition is limited to 2GB of RAM. SQL Server 2000
Enterprise Edition on 64bit Windows can use 4GB of ram without AWE, and can
use more with AWE.
David|||Interesting...
May I ask, how you go about setting up AWE in a 64-bit Windows? Does it need
to be set up from Windows side? Or is it just one needs to do sp_configure
'awe enabled', 1, from SQL Server side, will that be sufficient?
"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:e8tawkn3GHA.3828@.TK2MSFTNGP06.phx.gbl...
>
> "Roger" <Roger@.discussions.microsoft.com> wrote in message
> news:8796554C-FC5D-44F4-A150-2E867AA9F7AB@.microsoft.com...
>> We have new servers with 16GB RAM. I want the OS and SQL to use as much
>> of it
>> as possible. I can't put 64bit SQL on the box because the vendor doesn't
>> support that. Can I install 64bit 2003 and 32bit SQL 2000? If so, will
>> SQL be
>> able to use all of the memory or just the OS?
> SQL Server 2000 SP4 is supported on Windows Server 2003 x64 Edition. SQL
> Server 2000 Standard Edition is limited to 2GB of RAM. SQL Server 2000
> Enterprise Edition on 64bit Windows can use 4GB of ram without AWE, and
> can use more with AWE.
> David|||Nothing at the OS level, and same thing with sp_configure 'awe enabled' in
SQL Server.
Linchi
"Sean T Shen" wrote:
> Interesting...
> May I ask, how you go about setting up AWE in a 64-bit Windows? Does it need
> to be set up from Windows side? Or is it just one needs to do sp_configure
> 'awe enabled', 1, from SQL Server side, will that be sufficient?
>
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:e8tawkn3GHA.3828@.TK2MSFTNGP06.phx.gbl...
> >
> >
> > "Roger" <Roger@.discussions.microsoft.com> wrote in message
> > news:8796554C-FC5D-44F4-A150-2E867AA9F7AB@.microsoft.com...
> >> We have new servers with 16GB RAM. I want the OS and SQL to use as much
> >> of it
> >> as possible. I can't put 64bit SQL on the box because the vendor doesn't
> >> support that. Can I install 64bit 2003 and 32bit SQL 2000? If so, will
> >> SQL be
> >> able to use all of the memory or just the OS?
> >>
> >
> > SQL Server 2000 SP4 is supported on Windows Server 2003 x64 Edition. SQL
> > Server 2000 Standard Edition is limited to 2GB of RAM. SQL Server 2000
> > Enterprise Edition on 64bit Windows can use 4GB of ram without AWE, and
> > can use more with AWE.
> >
> > David
>
>|||So, there is no solution for 32bit SQL 2000 Standard Edition to allow more
than 2GB on Windows 2003 Enterprise 64bit environment with AWE setup?
Alex
"Linchi Shea" wrote:
> Nothing at the OS level, and same thing with sp_configure 'awe enabled' in
> SQL Server.
> Linchi
> "Sean T Shen" wrote:
> > Interesting...
> > May I ask, how you go about setting up AWE in a 64-bit Windows? Does it need
> > to be set up from Windows side? Or is it just one needs to do sp_configure
> > 'awe enabled', 1, from SQL Server side, will that be sufficient?
> >
> >
> >
> > "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> > message news:e8tawkn3GHA.3828@.TK2MSFTNGP06.phx.gbl...
> > >
> > >
> > > "Roger" <Roger@.discussions.microsoft.com> wrote in message
> > > news:8796554C-FC5D-44F4-A150-2E867AA9F7AB@.microsoft.com...
> > >> We have new servers with 16GB RAM. I want the OS and SQL to use as much
> > >> of it
> > >> as possible. I can't put 64bit SQL on the box because the vendor doesn't
> > >> support that. Can I install 64bit 2003 and 32bit SQL 2000? If so, will
> > >> SQL be
> > >> able to use all of the memory or just the OS?
> > >>
> > >
> > > SQL Server 2000 SP4 is supported on Windows Server 2003 x64 Edition. SQL
> > > Server 2000 Standard Edition is limited to 2GB of RAM. SQL Server 2000
> > > Enterprise Edition on 64bit Windows can use 4GB of ram without AWE, and
> > > can use more with AWE.
> > >
> > > David
> >
> >
> >|||I am having the same issue. 3 new servers,
Quad DualCore Opteron 880 2.4 gHz w/ 16 GB RAM
Windows 2003 R2 Enterprise x64 Edition SP1
SQL Server 2000 EE SP4
AWE Enabled, 14GB Dynamically allocated to SQL Server
Oddly 2 servers are running just fine, but I can't find the difference to
the 3rd and it will not recognize beyond 3.55GB of memory in SQL Server.
Anyone have any experience with this who could offer any suggestions would
be appreciated.

32bit SQL 2005 on Windows 2003R2 64bit

Is it possible to run sql 2005 on windows 2003 64? I would like to take
advantage of more than 4gb of memory in a windows 2003r2 server that will be
running sql 2005. As I understand it SQL2005 Standard 32 can be installed
and is supported on a 64bit windows2003 server.
Is this correct?
Although we want to scale to upwards of 8gb of memory in this particular box
down the road, this server will not be taking on enough load to warrant sql
64bit architecture.
You can run 32-bit SQL2005 on Win2003 x64.
Linchi
"Corey_in_Canada" wrote:

> Is it possible to run sql 2005 on windows 2003 64? I would like to take
> advantage of more than 4gb of memory in a windows 2003r2 server that will be
> running sql 2005. As I understand it SQL2005 Standard 32 can be installed
> and is supported on a 64bit windows2003 server.
> Is this correct?
> Although we want to scale to upwards of 8gb of memory in this particular box
> down the road, this server will not be taking on enough load to warrant sql
> 64bit architecture.
>
>
|||No offense, but why in the name of all that is holy are you not running
a 64-bit SQL Server on a 64-bit OS? Your assertion that "this server
will not be taking on enough load..." is nonsense.
If you want to use the 32-bit SQL Server product, install it on a 32-bit
Windows box and use PAE and AWE. While your installation *may* be
supported, I doubt it is a common scenario.
-D
Corey_in_Canada wrote:
> Is it possible to run sql 2005 on windows 2003 64? I would like to take
> advantage of more than 4gb of memory in a windows 2003r2 server that will be
> running sql 2005. As I understand it SQL2005 Standard 32 can be installed
> and is supported on a 64bit windows2003 server.
> Is this correct?
> Although we want to scale to upwards of 8gb of memory in this particular box
> down the road, this server will not be taking on enough load to warrant sql
> 64bit architecture.
>
>
-Dave Markle
http://www.markleconsulting.com/blog
|||I would not dismiss running 32-bit SQL2005 on Win2003 x64 out of hand. There
are cases where this combo may have a performance advantage. See
http://sqlblog.com/blogs/linchi_shea/archive/2007/01/02/32-bit-vs-x64.aspx
for an example.
However, I'd agree that performance is not the only factor in choosing a
platform. SQL2005 x64 on Win2003 x64 has many other advantages such as future
growth potential.
Linchi
"Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:

> No offense, but why in the name of all that is holy are you not running
> a 64-bit SQL Server on a 64-bit OS? Your assertion that "this server
> will not be taking on enough load..." is nonsense.
> If you want to use the 32-bit SQL Server product, install it on a 32-bit
> Windows box and use PAE and AWE. While your installation *may* be
> supported, I doubt it is a common scenario.
> -D
> Corey_in_Canada wrote:
>
> --
> -Dave Markle
> http://www.markleconsulting.com/blog
>
|||I agree that x64/x64 isn't always the best-performing option. But in
your tests the x86/x64 combination never bests both the x86/x86 and
x64/x64 workloads except for in Table 2, where you get only a 2%
performance increase over x86/x86. That, to me, isn't significant,
especially when you consider that different CPUs (AMD/Core/Xeon P4) and
memory architectures are probably going to be far more significant.
For me, the overriding factor here is to garner the benefits of running
a common configuration that lots and lots of other people use. For
almost everyone, that's going to be either x86/x86, or x64/x64. The
very fact that not a lot of folks run x86/x64 would make it less
attractive from my perspective -- has there been a large community
running this configuration in production scenarios? Is it truly proven?
For me, things as basic as memory allocation shouldn't be configured in
an exotic fashion. Maybe I'm growing too conservative in my old age,
but recent issues such as 899761 don't give me too much confidence about
such things... (http://support.microsoft.com/kb/899761).
-Dave
Linchi Shea wrote:[vbcol=seagreen]
> I would not dismiss running 32-bit SQL2005 on Win2003 x64 out of hand. There
> are cases where this combo may have a performance advantage. See
> http://sqlblog.com/blogs/linchi_shea/archive/2007/01/02/32-bit-vs-x64.aspx
> for an example.
> However, I'd agree that performance is not the only factor in choosing a
> platform. SQL2005 x64 on Win2003 x64 has many other advantages such as future
> growth potential.
> Linchi
> "Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:
-Dave Markle
http://www.markleconsulting.com/blog
|||Dave;
I don't disagree with you on SQL2005x86/Win2003x86 vs.
SQL2005x86/Win2003x64. And excellent point on preferring a platform that is
widely used. I was strictly commenting on SQL2005x86/Win2003x64 vs.
SQL2005x64/Win2003x64.
Linchi
"Dave Markle" <"dma[remove_ZZ]ZZrkle" wrote:

> I agree that x64/x64 isn't always the best-performing option. But in
> your tests the x86/x64 combination never bests both the x86/x86 and
> x64/x64 workloads except for in Table 2, where you get only a 2%
> performance increase over x86/x86. That, to me, isn't significant,
> especially when you consider that different CPUs (AMD/Core/Xeon P4) and
> memory architectures are probably going to be far more significant.
> For me, the overriding factor here is to garner the benefits of running
> a common configuration that lots and lots of other people use. For
> almost everyone, that's going to be either x86/x86, or x64/x64. The
> very fact that not a lot of folks run x86/x64 would make it less
> attractive from my perspective -- has there been a large community
> running this configuration in production scenarios? Is it truly proven?
> For me, things as basic as memory allocation shouldn't be configured in
> an exotic fashion. Maybe I'm growing too conservative in my old age,
> but recent issues such as 899761 don't give me too much confidence about
> such things... (http://support.microsoft.com/kb/899761).
> -Dave
>
> Linchi Shea wrote:
>
> --
> -Dave Markle
> http://www.markleconsulting.com/blog
>
|||You almost take on a defensive approach from your first response. Firstly,
it should not really be of great concern to you what we choose to do. My
question was simply one that asked whether this scenario was supported.
There *are* reasons and limiting factors as to why one may need to take such
an approach.
Anyways, thanks for the feedback.
"Dave Markle" <"dma[remove_ZZ]ZZrkle"@.gmail.dot.com> wrote in message
news:ecZQCA1RHHA.2256@.TK2MSFTNGP02.phx.gbl...
>I agree that x64/x64 isn't always the best-performing option. But in your
>tests the x86/x64 combination never bests both the x86/x86 and x64/x64
>workloads except for in Table 2, where you get only a 2% performance
>increase over x86/x86. That, to me, isn't significant, especially when you
>consider that different CPUs (AMD/Core/Xeon P4) and memory architectures
>are probably going to be far more significant.
> For me, the overriding factor here is to garner the benefits of running a
> common configuration that lots and lots of other people use. For almost
> everyone, that's going to be either x86/x86, or x64/x64. The very fact
> that not a lot of folks run x86/x64 would make it less attractive from my
> perspective -- has there been a large community running this configuration
> in production scenarios? Is it truly proven?
> For me, things as basic as memory allocation shouldn't be configured in an
> exotic fashion. Maybe I'm growing too conservative in my old age, but
> recent issues such as 899761 don't give me too much confidence about such
> things... (http://support.microsoft.com/kb/899761).
> -Dave
>
> Linchi Shea wrote:
>
> --
> -Dave Markle
> http://www.markleconsulting.com/blog
|||Sorry if you felt like I was jumping down your throat. I had just
finished a day at work "discussing" with a "senior" DBA why it *might*
not be a "best practice" to reboot each of our mission-critical
(non-clustered, mind you) SQL Servers on a nightly schedule. I was sort
of in "kill mode". That and I'd just seen the pictures of the "new"
Tyra, and am still taking it hard. I promise I'm a big teddy bear.
Why shouldn't it concern me, though? That's one of the big reasons why
I am on this board in the first place. I don't want to just answer
people's questions -- I want to point people toward the best solutions
whenever possible.
I also want to talk about issues of preference in a forum with people
who know more than I do. Linchi Shea is one of those people, and I'm
totally stoked that we get to even talk about this stuff. The fact is,
most people really couldn't give a squirt about how databases work, and
this forum is one of the few places we all get to go to read and learn
from one another.
-Dave
Corey_in_Canada wrote:
> You almost take on a defensive approach from your first response. Firstly,
> it should not really be of great concern to you what we choose to do. My
> question was simply one that asked whether this scenario was supported.
> There *are* reasons and limiting factors as to why one may need to take such
> an approach.
> Anyways, thanks for the feedback.
>
> "Dave Markle" <"dma[remove_ZZ]ZZrkle"@.gmail.dot.com> wrote in message
> news:ecZQCA1RHHA.2256@.TK2MSFTNGP02.phx.gbl...
>
-Dave Markle
http://www.markleconsulting.com/blog
|||On Fri, 2 Feb 2007 18:17:01 -0800, Linchi Shea
<LinchiShea@.discussions.microsoft.com> wrote:

>I would not dismiss running 32-bit SQL2005 on Win2003 x64 out of hand. There
>are cases where this combo may have a performance advantage. See
>http://sqlblog.com/blogs/linchi_shea/archive/2007/01/02/32-bit-vs-x64.aspx
>for an example.
>However, I'd agree that performance is not the only factor in choosing a
>platform. SQL2005 x64 on Win2003 x64 has many other advantages such as future
>growth potential.
Outstanding stuff.
Do you have something else that gives the same benchmarks on 32bit
hardware running AWE?
For extra special bonus, if it shows what happens when non-memory
stressed loads run on AWE vs native memory!
Josh
|||yes, It's Posible
ElTriKi
ElTriKi's Profile: http://unixadmintalk.com/1019
View this thread: http://unixadmintalk.com/showthread.php?t=261801

Tuesday, March 27, 2012

32bit vs 64bit SQL 2005

32bit vs 64bit SQL 2005

Sunday, March 25, 2012

32bit to 64bit Server performance is very poor

32bit to 64bit Server performance is very poor

32bit SQL Server on Win2003 64bit server?

32bit SQL Server on Win2003 64bit server?

32bit SQL Server on Win2003 64bit server?

32bit SQL Server on 64bit Inter Hardware

32bit sql on 64bit windows?

32bit sql on 64bit windows?

32bit sql on 64bit windows?

32bit SQL 2005 on Windows 2003R2 64bit

SQL Remove Old Backups

Blog Archive

About Me