Itanium vs Itanium 2

The 64 bit SQL Server version product blurb on the net specificaly reference
s the Itanium 2 processor. Are there any limitations to the original Itanium
? Obviously the Itanium servers are much cheaper to come by.
ThanksI agree with Joe. Don't buy a McKinley, make sure you get a Madison as they
are about twice as fast.
Andrew J. Kelly
SQL Server MVP
"joe chang" <anonymous@.discussions.microsoft.com> wrote in message
news:2efa01c3e219$0ac15cd0$a301280a@.phx.gbl...[QUOTE]
> i would not waste time on the original itanium system no
> matter how cheap they are on ebay, unless you want a space
> heater
> i would not expect any better performance than a Pentium
> III Xeon 700MHz
>
> specificaly references the Itanium 2 processor. Are there
> any limitations to the original Itanium? Obviously the
> Itanium servers are much cheaper to come by.|||I had a discussion on that when I was @.IT FORUM.
Ofcourse 64 bit will perform better I fully agree, but most of the time
people just forget to optimize their databases, actually no one looks at how
their queries perform, how they can be optimized, especially when using some
customized ERP or CRM applications that used to have their own storage
engine and now support sql server as the backend storage
Regards,
Dandy Weyn
MCSE, MCSA, MCDBA, MCT
www.dandyman.net
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23zm%23QJj4DHA.2656@.tk2msftngp13.phx.gbl...

quote:

---

> I agree with Joe. Don't buy a McKinley, make sure you get a Madison as

---

they

quote:

---

> are about twice as fast.
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "joe chang" <anonymous@.discussions.microsoft.com> wrote in message
> news:2efa01c3e219$0ac15cd0$a301280a@.phx.gbl...
>

---

Itanium vs Itanium 2

The 64 bit SQL Server version product blurb on the net specificaly references the Itanium 2 processor. Are there any limitations to the original Itanium? Obviously the Itanium servers are much cheaper to come by
Thanksi would not waste time on the original itanium system no
matter how cheap they are on ebay, unless you want a space
heater
i would not expect any better performance than a Pentium
III Xeon 700MHz
>--Original Message--
>The 64 bit SQL Server version product blurb on the net
specificaly references the Itanium 2 processor. Are there
any limitations to the original Itanium? Obviously the
Itanium servers are much cheaper to come by.
>Thanks
>.
>|||I agree with Joe. Don't buy a McKinley, make sure you get a Madison as they
are about twice as fast.
--
Andrew J. Kelly
SQL Server MVP
"joe chang" <anonymous@.discussions.microsoft.com> wrote in message
news:2efa01c3e219$0ac15cd0$a301280a@.phx.gbl...
> i would not waste time on the original itanium system no
> matter how cheap they are on ebay, unless you want a space
> heater
> i would not expect any better performance than a Pentium
> III Xeon 700MHz
> >--Original Message--
> >The 64 bit SQL Server version product blurb on the net
> specificaly references the Itanium 2 processor. Are there
> any limitations to the original Itanium? Obviously the
> Itanium servers are much cheaper to come by.
> >
> >Thanks
> >.
> >|||I had a discussion on that when I was @.IT FORUM.
Ofcourse 64 bit will perform better I fully agree, but most of the time
people just forget to optimize their databases, actually no one looks at how
their queries perform, how they can be optimized, especially when using some
customized ERP or CRM applications that used to have their own storage
engine and now support sql server as the backend storage
Regards,
Dandy Weyn
MCSE, MCSA, MCDBA, MCT
www.dandyman.net
"Andrew J. Kelly" <sqlmvpnooospam@.shadhawk.com> wrote in message
news:%23zm%23QJj4DHA.2656@.tk2msftngp13.phx.gbl...
> I agree with Joe. Don't buy a McKinley, make sure you get a Madison as
they
> are about twice as fast.
> --
> Andrew J. Kelly
> SQL Server MVP
>
> "joe chang" <anonymous@.discussions.microsoft.com> wrote in message
> news:2efa01c3e219$0ac15cd0$a301280a@.phx.gbl...
> > i would not waste time on the original itanium system no
> > matter how cheap they are on ebay, unless you want a space
> > heater
> > i would not expect any better performance than a Pentium
> > III Xeon 700MHz
> >
> > >--Original Message--
> > >The 64 bit SQL Server version product blurb on the net
> > specificaly references the Itanium 2 processor. Are there
> > any limitations to the original Itanium? Obviously the
> > Itanium servers are much cheaper to come by.
> > >
> > >Thanks
> > >.
> > >
>sql

Itanium or x64

We're looking for information on x64 support of SQL 2000. Will the 64 bit
version of SQL 2000 install on an x64 machine? Do I need to install the 32
bit version and then apply service pack 4?
Any information on how sp4 adds support for x64 would be appreciated.
DanHi
Microsoft is still finalizing this.
Once they have made a decision, there will be a public statement on this.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"DanR" <DanR@.discussions.microsoft.com> wrote in message
news:B7122D72-6462-4152-A650-A3AE5019FEF0@.microsoft.com...
> We're looking for information on x64 support of SQL 2000. Will the 64 bit
> version of SQL 2000 install on an x64 machine? Do I need to install the 32
> bit version and then apply service pack 4?
> Any information on how sp4 adds support for x64 would be appreciated.
> Dan
>|||The timing of all these changes couldn't be worse.
I have budget for a server upgrade but won't have the budget for SQL 2005
until next year and we're trying to figure out what server to purchase today.
We would like to go with x64 if possible, however I haven't come across any
statements from software or hardware manufacturers regarding SQL 2000
Enterprise running on Windows 2003 Enterprise x64. Some of the questions we
have are:
How much memory will be available to us?
Do we still need boot.ini switches?
Should we install 32 bit SQL until we can upgrade to SQL 2005?
Has anybody tried this environment?
Dan|||I have an IBM blade with the EM64t chip. I am not seeing the performance I
feel I should. It may be that Beta 2 is unoptimized. But in running
comparisons between a 32 bit box and the new install I am getting better
performance from the 32 bit. The cpu time is greater by a value of about 4
times. Those beings send I am continuing to investigate this issue. It is
our first venture into the 64 bit world, but we are committed to getting
there.
I will post what we further find out.
"DanR" wrote:
> The timing of all these changes couldn't be worse.
> I have budget for a server upgrade but won't have the budget for SQL 2005
> until next year and we're trying to figure out what server to purchase today.
> We would like to go with x64 if possible, however I haven't come across any
> statements from software or hardware manufacturers regarding SQL 2000
> Enterprise running on Windows 2003 Enterprise x64. Some of the questions we
> have are:
> How much memory will be available to us?
> Do we still need boot.ini switches?
> Should we install 32 bit SQL until we can upgrade to SQL 2005?
> Has anybody tried this environment?
> Dan

Issues for 64 bit 2003 OS Server from Advanced 2000

Running Standard Edition SQL 2000 on Advanced Server with PAE enabled in the
boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
Standard Edition SQL 2000 which as we know well, can access only first two
GIG of RAM thus, I think, AWE is completely out of the question.
Is it necessary to enable PAE on the 2003 server? Are there issues that
should be considered for the 64 bit server running SQL 2000 that are
different from an instance running on Advanced Server 2000?
--
Regards,
Jamie
BOL
Configuration -Enabling AWE Memory for SQL Server (2000?)
http://msdn2.microsoft.com/en-us/library/ms190673.aspx
Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)PAE is only useful on 32 bit systems as X64 can access the memory directly
and does not require it. With SQL2000 Std you will only ever be able to use
2GB max. So why bother going thru these motions? Most of the 8GB is wasted
and you will reap none of the benefits of X64 in this state. I highly
recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
likely a waste of your time.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
> Running Standard Edition SQL 2000 on Advanced Server with PAE enabled in
> the
> boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
> System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
> Standard Edition SQL 2000 which as we know well, can access only first two
> GIG of RAM thus, I think, AWE is completely out of the question.
> Is it necessary to enable PAE on the 2003 server? Are there issues that
> should be considered for the 64 bit server running SQL 2000 that are
> different from an instance running on Advanced Server 2000?
> --
> Regards,
> Jamie
> BOL
> Configuration -Enabling AWE Memory for SQL Server (2000?)
> http://msdn2.microsoft.com/en-us/library/ms190673.aspx
> Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
> http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
>|||A decision was made to wait for SP1 on SQL Server 2008. When that hits, we
upgrade.
Meanwhile...
--
Regards,
Jamie
"Andrew J. Kelly" wrote:
> PAE is only useful on 32 bit systems as X64 can access the memory directly
> and does not require it. With SQL2000 Std you will only ever be able to use
> 2GB max. So why bother going thru these motions? Most of the 8GB is wasted
> and you will reap none of the benefits of X64 in this state. I highly
> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
> likely a waste of your time.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled in
> > the
> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
> > Standard Edition SQL 2000 which as we know well, can access only first two
> > GIG of RAM thus, I think, AWE is completely out of the question.
> >
> > Is it necessary to enable PAE on the 2003 server? Are there issues that
> > should be considered for the 64 bit server running SQL 2000 that are
> > different from an instance running on Advanced Server 2000?
> > --
> > Regards,
> > Jamie
> > BOL
> > Configuration -Enabling AWE Memory for SQL Server (2000?)
> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
> >
> > Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
> >
> >
>|||I'm primarily concerned that there may be pitfalls unknown when we do this
move from the old server to the new. It isn't by choice that we are putting
2000 on this new 64 bit server (16 Gig Ram - 8 Processors). Our production
server is failing and we are scrambling to get it fixed and running on the
new server ASAP. I agree that it would be wiser to go with 2005.
--
Regards,
Jamie
"Andrew J. Kelly" wrote:
> PAE is only useful on 32 bit systems as X64 can access the memory directly
> and does not require it. With SQL2000 Std you will only ever be able to use
> 2GB max. So why bother going thru these motions? Most of the 8GB is wasted
> and you will reap none of the benefits of X64 in this state. I highly
> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
> likely a waste of your time.
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled in
> > the
> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
> > Standard Edition SQL 2000 which as we know well, can access only first two
> > GIG of RAM thus, I think, AWE is completely out of the question.
> >
> > Is it necessary to enable PAE on the 2003 server? Are there issues that
> > should be considered for the 64 bit server running SQL 2000 that are
> > different from an instance running on Advanced Server 2000?
> > --
> > Regards,
> > Jamie
> > BOL
> > Configuration -Enabling AWE Memory for SQL Server (2000?)
> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
> >
> > Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
> >
> >
>|||Wow, must be nice to have wasted resources sitting around for 1 year +,
which is probably when you will be able to upgrade to SQL 2008, sp1. :)
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:B5A4ED33-8758-49C2-BFA3-5960066E5568@.microsoft.com...
>A decision was made to wait for SP1 on SQL Server 2008. When that hits, we
> upgrade.
> Meanwhile...
> --
> Regards,
> Jamie
>
> "Andrew J. Kelly" wrote:
>> PAE is only useful on 32 bit systems as X64 can access the memory
>> directly
>> and does not require it. With SQL2000 Std you will only ever be able to
>> use
>> 2GB max. So why bother going thru these motions? Most of the 8GB is
>> wasted
>> and you will reap none of the benefits of X64 in this state. I highly
>> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
>> likely a waste of your time.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
>> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled
>> > in
>> > the
>> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
>> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
>> > Standard Edition SQL 2000 which as we know well, can access only first
>> > two
>> > GIG of RAM thus, I think, AWE is completely out of the question.
>> >
>> > Is it necessary to enable PAE on the 2003 server? Are there issues
>> > that
>> > should be considered for the 64 bit server running SQL 2000 that are
>> > different from an instance running on Advanced Server 2000?
>> > --
>> > Regards,
>> > Jamie
>> > BOL
>> > Configuration -Enabling AWE Memory for SQL Server (2000?)
>> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
>> >
>> > Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
>> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
>> >
>> >
>>|||You are probably talking close to a year away for that. Oh well.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:B5A4ED33-8758-49C2-BFA3-5960066E5568@.microsoft.com...
>A decision was made to wait for SP1 on SQL Server 2008. When that hits, we
> upgrade.
> Meanwhile...
> --
> Regards,
> Jamie
>
> "Andrew J. Kelly" wrote:
>> PAE is only useful on 32 bit systems as X64 can access the memory
>> directly
>> and does not require it. With SQL2000 Std you will only ever be able to
>> use
>> 2GB max. So why bother going thru these motions? Most of the 8GB is
>> wasted
>> and you will reap none of the benefits of X64 in this state. I highly
>> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
>> likely a waste of your time.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
>> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled
>> > in
>> > the
>> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
>> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
>> > Standard Edition SQL 2000 which as we know well, can access only first
>> > two
>> > GIG of RAM thus, I think, AWE is completely out of the question.
>> >
>> > Is it necessary to enable PAE on the 2003 server? Are there issues
>> > that
>> > should be considered for the 64 bit server running SQL 2000 that are
>> > different from an instance running on Advanced Server 2000?
>> > --
>> > Regards,
>> > Jamie
>> > BOL
>> > Configuration -Enabling AWE Memory for SQL Server (2000?)
>> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
>> >
>> > Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
>> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
>> >
>> >
>>|||Sure there is always the unknown unless you test it first. It is a whole new
OS, drivers etc. Theoretically it should work fine as long as you have all
the proper drivers and are doing just basic database operations. But I have
to assume there are other apps on the same server correct? Otherwise that
is a lot of wasted hardware since 200 Std only supports 4 procs and 2GB of
memory.
--
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:EC033C23-2758-42D5-9BA8-BB61DF2772D2@.microsoft.com...
> I'm primarily concerned that there may be pitfalls unknown when we do this
> move from the old server to the new. It isn't by choice that we are
> putting
> 2000 on this new 64 bit server (16 Gig Ram - 8 Processors). Our
> production
> server is failing and we are scrambling to get it fixed and running on the
> new server ASAP. I agree that it would be wiser to go with 2005.
> --
> Regards,
> Jamie
>
> "Andrew J. Kelly" wrote:
>> PAE is only useful on 32 bit systems as X64 can access the memory
>> directly
>> and does not require it. With SQL2000 Std you will only ever be able to
>> use
>> 2GB max. So why bother going thru these motions? Most of the 8GB is
>> wasted
>> and you will reap none of the benefits of X64 in this state. I highly
>> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
>> likely a waste of your time.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
>> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled
>> > in
>> > the
>> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
>> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
>> > Standard Edition SQL 2000 which as we know well, can access only first
>> > two
>> > GIG of RAM thus, I think, AWE is completely out of the question.
>> >
>> > Is it necessary to enable PAE on the 2003 server? Are there issues
>> > that
>> > should be considered for the 64 bit server running SQL 2000 that are
>> > different from an instance running on Advanced Server 2000?
>> > --
>> > Regards,
>> > Jamie
>> > BOL
>> > Configuration -Enabling AWE Memory for SQL Server (2000?)
>> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
>> >
>> > Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
>> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
>> >
>> >
>>|||I experienced a worse scenario. Listen to this:
I was setting up SQL Server Cluster on two DL580 of HPs with 4 Dual Core
CPUs and 16GB of RAMs... Nice config, yea?
There was a failed cluster node when we went to the scene. I mean, they were
using their SQL Servers for about 6 months...
Servers were x86 and non of the /PAE and AWE was being used. Even /3GB
wasn't used.
I went to the hospital's IT manager and told him about the situation. I told
him you have 16GB of RAM on your servers and your SQL Servers are using only
2GB of RAM out of 16GB and the rest of it is just sitting for months. And
guest what he said? He said, "I knew, but I didn't wanna touch it". Funny,
huh?
--
Ekrem Ã?nsoy
http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
MCBDA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:B5A4ED33-8758-49C2-BFA3-5960066E5568@.microsoft.com...
>A decision was made to wait for SP1 on SQL Server 2008. When that hits, we
> upgrade.
> Meanwhile...
> --
> Regards,
> Jamie
>
> "Andrew J. Kelly" wrote:
>> PAE is only useful on 32 bit systems as X64 can access the memory
>> directly
>> and does not require it. With SQL2000 Std you will only ever be able to
>> use
>> 2GB max. So why bother going thru these motions? Most of the 8GB is
>> wasted
>> and you will reap none of the benefits of X64 in this state. I highly
>> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
>> likely a waste of your time.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
>> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled
>> > in
>> > the
>> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
>> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
>> > Standard Edition SQL 2000 which as we know well, can access only first
>> > two
>> > GIG of RAM thus, I think, AWE is completely out of the question.
>> >
>> > Is it necessary to enable PAE on the 2003 server? Are there issues
>> > that
>> > should be considered for the 64 bit server running SQL 2000 that are
>> > different from an instance running on Advanced Server 2000?
>> > --
>> > Regards,
>> > Jamie
>> > BOL
>> > Configuration -Enabling AWE Memory for SQL Server (2000?)
>> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
>> >
>> > Configuration -Enabling Memory Support for Over 4 GB of Physical Memory
>> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
>> >
>> >
>>|||Definitely a case of fear paralysis. If they didn't NEED the performance
then it was just money sitting for nothing. But if they also had poor
performance then they could have actively been losing money due to the
slowness and that is when it is really a shame!!
--
Kevin G. Boles
TheSQLGuru
Indicium Resources, Inc.
"Ekrem Önsoy" <ekrem@.btegitim.com> wrote in message
news:2B1B5E4E-A07D-4D19-9D69-93F1E0C6ADA5@.microsoft.com...
>I experienced a worse scenario. Listen to this:
> I was setting up SQL Server Cluster on two DL580 of HPs with 4 Dual Core
> CPUs and 16GB of RAMs... Nice config, yea?
> There was a failed cluster node when we went to the scene. I mean, they
> were using their SQL Servers for about 6 months...
> Servers were x86 and non of the /PAE and AWE was being used. Even /3GB
> wasn't used.
> I went to the hospital's IT manager and told him about the situation. I
> told him you have 16GB of RAM on your servers and your SQL Servers are
> using only 2GB of RAM out of 16GB and the rest of it is just sitting for
> months. And guest what he said? He said, "I knew, but I didn't wanna touch
> it". Funny, huh?
> --
> Ekrem Önsoy
> http://www.ekremonsoy.net , http://ekremonsoy.blogspot.com
> MCBDA, MCITP:DBA, MCSD.Net, MCSE, MCBMSP, MCT
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:B5A4ED33-8758-49C2-BFA3-5960066E5568@.microsoft.com...
>>A decision was made to wait for SP1 on SQL Server 2008. When that hits,
>>we
>> upgrade.
>> Meanwhile...
>> --
>> Regards,
>> Jamie
>>
>> "Andrew J. Kelly" wrote:
>> PAE is only useful on 32 bit systems as X64 can access the memory
>> directly
>> and does not require it. With SQL2000 Std you will only ever be able to
>> use
>> 2GB max. So why bother going thru these motions? Most of the 8GB is
>> wasted
>> and you will reap none of the benefits of X64 in this state. I highly
>> recommend you upgrade to SQL2005 Std X64 edition otherwise this is most
>> likely a waste of your time.
>> --
>> Andrew J. Kelly SQL MVP
>> Solid Quality Mentors
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:B1414628-6F34-46A7-83B8-6E8EFB4241F9@.microsoft.com...
>> > Running Standard Edition SQL 2000 on Advanced Server with PAE enabled
>> > in
>> > the
>> > boot ini (8 gig ram on Adv Svr but only two allocates for Standard)
>> > System is migrating to a 64 bit Advanced Server with 8 GIG RAM... also
>> > Standard Edition SQL 2000 which as we know well, can access only first
>> > two
>> > GIG of RAM thus, I think, AWE is completely out of the question.
>> >
>> > Is it necessary to enable PAE on the 2003 server? Are there issues
>> > that
>> > should be considered for the 64 bit server running SQL 2000 that are
>> > different from an instance running on Advanced Server 2000?
>> > --
>> > Regards,
>> > Jamie
>> > BOL
>> > Configuration -Enabling AWE Memory for SQL Server (2000?)
>> > http://msdn2.microsoft.com/en-us/library/ms190673.aspx
>> >
>> > Configuration -Enabling Memory Support for Over 4 GB of Physical
>> > Memory
>> > http://msdn2.microsoft.com/en-us/library/ms179301.aspx (2000?)
>> >
>> >
>>
>

Issue with DB on particular machine

Hi,

I am at a bit of a loss about what to do with a problem I am having. I
have a 7GB database, loaded on to SQL Server 2000 SP4 on 2 different
machines.

Machines have following specs:

1) Intel Pentium 4 Dual Core 3.40 GHz, 3 GB RAM, 2GBb RAM available to
SQL Server. Windows 2003 SP1
2) AMD Athlon 2500 + (1.8GHz), 2GB RAM, , 2GBb RAM available to SQL
Server. Windows 2003 R2 SP1

I hope this is enough relevant information.

The 2nd machine handles the database fine, complex queries are OK etc.
The 1st machine cannot even handle generating an estimated execution
plan for a query on a single table. It dies and has to be killed via
the power button.

However, I have another 9GB DB on the same machine that I can run
complex queries against with no problem.

I thought that there may be a particular issue with that DB so I ran
DBCC CHECKDB against it but no errors were reported. I have also run
Check Disk on the machine and again, no problems were found. So I am
currently at a complete loss about what to do. Both instances of the DB
have come from the same backup. I do not really know what else to try
with this.

If anybody has any ideas at all it would be greatly appreciated.

Thanks in advance,

PaulHi Paul - what are the disk drives like on both servers? Where are the
databases' data files located on each server? If you doing a lot of I/O
(which I suspect your are) then you might want to look at Disk I/O
and/or disk thru put.

JD

Paul wrote:

Quote:

Originally Posted by

Hi,
>
I am at a bit of a loss about what to do with a problem I am having. I
have a 7GB database, loaded on to SQL Server 2000 SP4 on 2 different
machines.
>
Machines have following specs:
>
1) Intel Pentium 4 Dual Core 3.40 GHz, 3 GB RAM, 2GBb RAM available to
SQL Server. Windows 2003 SP1
2) AMD Athlon 2500 + (1.8GHz), 2GB RAM, , 2GBb RAM available to SQL
Server. Windows 2003 R2 SP1
>
I hope this is enough relevant information.
>
The 2nd machine handles the database fine, complex queries are OK etc.
The 1st machine cannot even handle generating an estimated execution
plan for a query on a single table. It dies and has to be killed via
the power button.
>
However, I have another 9GB DB on the same machine that I can run
complex queries against with no problem.
>
I thought that there may be a particular issue with that DB so I ran
DBCC CHECKDB against it but no errors were reported. I have also run
Check Disk on the machine and again, no problems were found. So I am
currently at a complete loss about what to do. Both instances of the DB
have come from the same backup. I do not really know what else to try
with this.
>
If anybody has any ideas at all it would be greatly appreciated.
>
Thanks in advance,
>
Paul

Issue with Ascii 7 files

Hi All,

I need to generate Ascii 7 bit flat file, based on data in db, using integration services, FTP task. Currently i am generating file with ansi-latin and then using the script task converting it to the ascii 7. File looks to be generated properly. But when the target system reads this, they complain that the file has junk charecters some thing like this. when i open it after generating the file it looks fine to me in DOS also. I dont know what is the target system and what OS is used by them. what cud be the issue for these junk charecters and is it possible that a Ascii 7 file generated by windows doesnt work in other OS? If the method i am doing to generate the ascii 7 is not currect then what is the best method for this?

????H^@.D^@.R^@.|^@.1^@.E^@.N^@.I^@.N^@.A^@.|^@.O^@.|^@.2^@.0^@.0^@.6^@.-^@.0^@.9^@.-^@.1^@.3^@.

PS: earlier i had generated a flat file using data export from Excel & that worked in the target system well. is there any difference in the file encoding generated by excel and integration services?

Please help me!!!!

-vinu

ANSI Latin is extention of ASCII character set. Meaning any proper ASCII text is also valid ANSI Latin text. And ANSI Latin text is either valid ASCII text as well, or contains characters that can't be represented in ASCII at all. So you either don't need any conversion from ANSI Latin -> ASCII, or the lossles conversion is not possible.

I'm not sure what you are doing in the script task, but if you specified the requirements correctly, it is either not needed or not possible :). Anyway, it would be helpful if you include the code.

ISSUE WHILE CONNECTING TO ORACLE SOURCE WITH 64 BIT processor SQL SERVER SSIS

Hello All,

I have a unique problem while connecting to oracle source with a 64 bit processor. I can connect to the oracle from the command prompt in the 64 bit processor but not from SSIS.

The acutal problem is, when check the properties of the connection manager and provide a provider for oracle, and then provide username and password and click on test connection. I get the following error:

"Test Connection failed because of an error in initializing provider.ORA-06413: Connection not open"

Regards,

Raju

Hello All,

The above package is running fine with sql server 32 bit development but not running in 64 bit production server.

The oracle client that has been installed on the production server is a 32 bit, because our source database is an oracle 32 bit not 64 bit which is residing in another server.

Hope this additional information will help you people get it resolved.

Regards,

Raju

|||

Hi Raju,

If you want to connect to Oracle using a 32bit driver, then you should execute the SSIS package using the 32bit version of DTEXEC.

Regards,

Christian

Issue in setting up the database Mirrioring environment for SQL Server 2005.

Environment:SQL Server 2005 Enterprise in Win2k3 Enterprise on 32(x86) bit machine

I am able to enable the Trace Flag 1400 using DBCC TRACEON (1400) GO. Only then we can able to configure for the ENDPOINTS.

I successfully configured the ENDPOINTS for both the principal server and Mirror server .And then when I started the START MIRRORING.

I got the error message. Please find the Message below.

An error occured while starting mirroring.

additional Information:
:..>Alter failed for Database 'KQDB', (Microsoft SqlServer.Smo)

:..>An exception occured while executing a Transact-SQL statement or batch
[Microsoft SqlServer.Connection.info]

:..>Database mirroring Transport is disabled in the endpoint configuration.
[Microsft SQL Server,Error: 1486]

If anyone have a solution on how to setup a database mirroring environment.Please send.

You must start up the sql service with trace flag 1400. It is not enough to use DBCC TRACE ON.

Thanks,

Mark

|||I've been encountering the same issue. I've set the trace flag on startup, and still have no luck.
I've gone through every step in the online help, verified that BOTH server instances are listening (the pids corresponds to the ports) and I cannot shake this message:

"Database Mirroring Transport is disabled in the endpoint configuration."

The error comes following the command:

alter database AdventureWorks SET PARTNER = 'TCP://10.0.25.72:5022'
go

It does not seem to matter what port I enter, and it doesn't matter what the IP address is. I've tried this on both the Mirror and on the Primary (ie - in every order).

The mirroring endpoints seem be created properly. I've explored all steps in the msdn "Troubleshooting Database Mirroring Setup" document, checking the various system tables for status, etc. but it is to no avail.

I disabled the 'VIA' protocol in the Configuartion Manager, one of the hints I found from the various newsgroups i've browsed.

I am trying to mirror (without a witness) between two instances on the same server. I am well aware that this is not supported, but I need to kick the tires in a testing playground.

Is this a common problem? The lack of postings with this issue indicate that it may not be, but honestly, i'm stymied.

If anyone has encountered and solved this, please respond, and hopefully it will help others as well.

Cheers,

brentj

|||Can you just please tell use how to start the sql service with trace flag 1400.|||

chanmm wrote:

Can you just please tell use how to start the sql service with trace flag 1400.

You don't need the trace flag if you install SP1 which has now released.

Otherwise if SP1 isn't yet an option (which it really should be if you want to use db mirroring), you can add -T1400 as a startup parameter via the SQL Configuration Manager, properties of the SQL Server service -> advanced tab ->Startup Parameters.

it's not particularly well indexed or cross-referenced but BOL has details here :

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c82d19e5-5557-4235-9a70-37983607a1fd.htm

thx, Simon.

|||I'm wondering if the thread started for this post resolved this issue? I have set Trace Flag 1400 "-T1400;..." in startup configuration options, rebooted and restarted servers and still not able to mirror. Also given the error "Database Mirroring Transport is disabled."

Anyone figure this out? Next I install SQL 2005 SP1.|||To update on my experience:
I installed SP1 and interestingly it even strips the Trace Flag 1400 out of the startup options for you so you don't leave that remnant of a failed Mirroring Attempt - good work guys!

I got an asynchronous mirror working after installing SQL 2005 SP1 but have not fully tested it.|||Sample is there in the updated SQL BOL docs. No gotchas except the fact that security configuration is the MOST critical. If you get that done, the rest is a breeze.

Issue in setting up the database Mirrioring environment for SQL Server 2005.

Environment:SQL Server 2005 Enterprise in Win2k3 Enterprise on 32(x86) bit machine

I am able to enable the Trace Flag 1400 using DBCC TRACEON (1400) GO. Only then we can able to configure for the ENDPOINTS.

I successfully configured the ENDPOINTS for both the principal server and Mirror server .And then when I started the START MIRRORING.

I got the error message. Please find the Message below.

An error occured while starting mirroring.

additional Information:
:..>Alter failed for Database 'KQDB', (Microsoft SqlServer.Smo)

:..>An exception occured while executing a Transact-SQL statement or batch
[Microsoft SqlServer.Connection.info]

:..>Database mirroring Transport is disabled in the endpoint configuration.
[Microsft SQL Server,Error: 1486]

If anyone have a solution on how to setup a database mirroring environment.Please send.

You must start up the sql service with trace flag 1400. It is not enough to use DBCC TRACE ON.

Thanks,

Mark

|||I've been encountering the same issue. I've set the trace flag on startup, and still have no luck.
I've gone through every step in the online help, verified that BOTH server instances are listening (the pids corresponds to the ports) and I cannot shake this message:

"Database Mirroring Transport is disabled in the endpoint configuration."

The error comes following the command:

alter database AdventureWorks SET PARTNER = 'TCP://10.0.25.72:5022'
go

It does not seem to matter what port I enter, and it doesn't matter what the IP address is. I've tried this on both the Mirror and on the Primary (ie - in every order).

The mirroring endpoints seem be created properly. I've explored all steps in the msdn "Troubleshooting Database Mirroring Setup" document, checking the various system tables for status, etc. but it is to no avail.

I disabled the 'VIA' protocol in the Configuartion Manager, one of the hints I found from the various newsgroups i've browsed.

I am trying to mirror (without a witness) between two instances on the same server. I am well aware that this is not supported, but I need to kick the tires in a testing playground.

Is this a common problem? The lack of postings with this issue indicate that it may not be, but honestly, i'm stymied.

If anyone has encountered and solved this, please respond, and hopefully it will help others as well.

Cheers,

brentj

|||Can you just please tell use how to start the sql service with trace flag 1400.|||

chanmm wrote:

Can you just please tell use how to start the sql service with trace flag 1400.

You don't need the trace flag if you install SP1 which has now released.

Otherwise if SP1 isn't yet an option (which it really should be if you want to use db mirroring), you can add -T1400 as a startup parameter via the SQL Configuration Manager, properties of the SQL Server service -> advanced tab ->Startup Parameters.

it's not particularly well indexed or cross-referenced but BOL has details here :

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c82d19e5-5557-4235-9a70-37983607a1fd.htm

thx, Simon.

|||I'm wondering if the thread started for this post resolved this issue? I have set Trace Flag 1400 "-T1400;..." in startup configuration options, rebooted and restarted servers and still not able to mirror. Also given the error "Database Mirroring Transport is disabled."

Anyone figure this out? Next I install SQL 2005 SP1.|||To update on my experience:
I installed SP1 and interestingly it even strips the Trace Flag 1400 out of the startup options for you so you don't leave that remnant of a failed Mirroring Attempt - good work guys!

I got an asynchronous mirror working after installing SQL 2005 SP1 but have not fully tested it.|||Sample is there in the updated SQL BOL docs. No gotchas except the fact that security configuration is the MOST critical. If you get that done, the rest is a breeze.

Issue in setting up the database Mirrioring environment for SQL Server 2005.

Environment:SQL Server 2005 Enterprise in Win2k3 Enterprise on 32(x86) bit machine

I am able to enable the Trace Flag 1400 using DBCC TRACEON (1400) GO. Only then we can able to configure for the ENDPOINTS.

I successfully configured the ENDPOINTS for both the principal server and Mirror server .And then when I started the START MIRRORING.

I got the error message. Please find the Message below.

An error occured while starting mirroring.

additional Information:
:..>Alter failed for Database 'KQDB', (Microsoft SqlServer.Smo)

:..>An exception occured while executing a Transact-SQL statement or batch
[Microsoft SqlServer.Connection.info]

:..>Database mirroring Transport is disabled in the endpoint configuration.
[Microsft SQL Server,Error: 1486]

If anyone have a solution on how to setup a database mirroring environment.Please send.

You must start up the sql service with trace flag 1400. It is not enough to use DBCC TRACE ON.

Thanks,

Mark

|||I've been encountering the same issue. I've set the trace flag on startup, and still have no luck.
I've gone through every step in the online help, verified that BOTH server instances are listening (the pids corresponds to the ports) and I cannot shake this message:

"Database Mirroring Transport is disabled in the endpoint configuration."

The error comes following the command:

alter database AdventureWorks SET PARTNER = 'TCP://10.0.25.72:5022'
go

It does not seem to matter what port I enter, and it doesn't matter what the IP address is. I've tried this on both the Mirror and on the Primary (ie - in every order).

The mirroring endpoints seem be created properly. I've explored all steps in the msdn "Troubleshooting Database Mirroring Setup" document, checking the various system tables for status, etc. but it is to no avail.

I disabled the 'VIA' protocol in the Configuartion Manager, one of the hints I found from the various newsgroups i've browsed.

I am trying to mirror (without a witness) between two instances on the same server. I am well aware that this is not supported, but I need to kick the tires in a testing playground.

Is this a common problem? The lack of postings with this issue indicate that it may not be, but honestly, i'm stymied.

If anyone has encountered and solved this, please respond, and hopefully it will help others as well.

Cheers,

brentj

|||Can you just please tell use how to start the sql service with trace flag 1400.|||

chanmm wrote:

Can you just please tell use how to start the sql service with trace flag 1400.

You don't need the trace flag if you install SP1 which has now released.

Otherwise if SP1 isn't yet an option (which it really should be if you want to use db mirroring), you can add -T1400 as a startup parameter via the SQL Configuration Manager, properties of the SQL Server service -> advanced tab ->Startup Parameters.

it's not particularly well indexed or cross-referenced but BOL has details here :

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c82d19e5-5557-4235-9a70-37983607a1fd.htm

thx, Simon.

|||I'm wondering if the thread started for this post resolved this issue? I have set Trace Flag 1400 "-T1400;..." in startup configuration options, rebooted and restarted servers and still not able to mirror. Also given the error "Database Mirroring Transport is disabled."

Anyone figure this out? Next I install SQL 2005 SP1.|||To update on my experience:
I installed SP1 and interestingly it even strips the Trace Flag 1400 out of the startup options for you so you don't leave that remnant of a failed Mirroring Attempt - good work guys!

I got an asynchronous mirror working after installing SQL 2005 SP1 but have not fully tested it.|||Sample is there in the updated SQL BOL docs. No gotchas except the fact that security configuration is the MOST critical. If you get that done, the rest is a breeze.

Issue in setting up the database Mirrioring environment for SQL Server 2005.

Environment:SQL Server 2005 Enterprise in Win2k3 Enterprise on 32(x86) bit machine

I am able to enable the Trace Flag 1400 using DBCC TRACEON (1400) GO. Only then we can able to configure for the ENDPOINTS.

I successfully configured the ENDPOINTS for both the principal server and Mirror server .And then when I started the START MIRRORING.

I got the error message. Please find the Message below.

An error occured while starting mirroring.

additional Information:
:..>Alter failed for Database 'KQDB', (Microsoft SqlServer.Smo)

:..>An exception occured while executing a Transact-SQL statement or batch
[Microsoft SqlServer.Connection.info]

:..>Database mirroring Transport is disabled in the endpoint configuration.
[Microsft SQL Server,Error: 1486]

If anyone have a solution on how to setup a database mirroring environment.Please send.

You must start up the sql service with trace flag 1400. It is not enough to use DBCC TRACE ON.

Thanks,

Mark

|||I've been encountering the same issue. I've set the trace flag on startup, and still have no luck.
I've gone through every step in the online help, verified that BOTH server instances are listening (the pids corresponds to the ports) and I cannot shake this message:

"Database Mirroring Transport is disabled in the endpoint configuration."

The error comes following the command:

alter database AdventureWorks SET PARTNER = 'TCP://10.0.25.72:5022'
go

It does not seem to matter what port I enter, and it doesn't matter what the IP address is. I've tried this on both the Mirror and on the Primary (ie - in every order).

The mirroring endpoints seem be created properly. I've explored all steps in the msdn "Troubleshooting Database Mirroring Setup" document, checking the various system tables for status, etc. but it is to no avail.

I disabled the 'VIA' protocol in the Configuartion Manager, one of the hints I found from the various newsgroups i've browsed.

I am trying to mirror (without a witness) between two instances on the same server. I am well aware that this is not supported, but I need to kick the tires in a testing playground.

Is this a common problem? The lack of postings with this issue indicate that it may not be, but honestly, i'm stymied.

If anyone has encountered and solved this, please respond, and hopefully it will help others as well.

Cheers,

brentj

|||Can you just please tell use how to start the sql service with trace flag 1400.|||

chanmm wrote:

Can you just please tell use how to start the sql service with trace flag 1400.

You don't need the trace flag if you install SP1 which has now released.

Otherwise if SP1 isn't yet an option (which it really should be if you want to use db mirroring), you can add -T1400 as a startup parameter via the SQL Configuration Manager, properties of the SQL Server service -> advanced tab ->Startup Parameters.

it's not particularly well indexed or cross-referenced but BOL has details here :

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c82d19e5-5557-4235-9a70-37983607a1fd.htm

thx, Simon.

|||I'm wondering if the thread started for this post resolved this issue? I have set Trace Flag 1400 "-T1400;..." in startup configuration options, rebooted and restarted servers and still not able to mirror. Also given the error "Database Mirroring Transport is disabled."

Anyone figure this out? Next I install SQL 2005 SP1.|||To update on my experience:
I installed SP1 and interestingly it even strips the Trace Flag 1400 out of the startup options for you so you don't leave that remnant of a failed Mirroring Attempt - good work guys!

I got an asynchronous mirror working after installing SQL 2005 SP1 but have not fully tested it.|||Sample is there in the updated SQL BOL docs. No gotchas except the fact that security configuration is the MOST critical. If you get that done, the rest is a breeze.

Issue in setting up the database Mirrioring environment for SQL Server 2005.

Environment:SQL Server 2005 Enterprise in Win2k3 Enterprise on 32(x86) bit machine

I am able to enable the Trace Flag 1400 using DBCC TRACEON (1400) GO. Only then we can able to configure for the ENDPOINTS.

I successfully configured the ENDPOINTS for both the principal server and Mirror server .And then when I started the START MIRRORING.

I got the error message. Please find the Message below.

An error occured while starting mirroring.

additional Information:
:..>Alter failed for Database 'KQDB', (Microsoft SqlServer.Smo)

:..>An exception occured while executing a Transact-SQL statement or batch
[Microsoft SqlServer.Connection.info]

:..>Database mirroring Transport is disabled in the endpoint configuration.
[Microsft SQL Server,Error: 1486]

If anyone have a solution on how to setup a database mirroring environment.Please send.

You must start up the sql service with trace flag 1400. It is not enough to use DBCC TRACE ON.

Thanks,

Mark

|||I've been encountering the same issue. I've set the trace flag on startup, and still have no luck.
I've gone through every step in the online help, verified that BOTH server instances are listening (the pids corresponds to the ports) and I cannot shake this message:

"Database Mirroring Transport is disabled in the endpoint configuration."

The error comes following the command:

alter database AdventureWorks SET PARTNER = 'TCP://10.0.25.72:5022'
go

It does not seem to matter what port I enter, and it doesn't matter what the IP address is. I've tried this on both the Mirror and on the Primary (ie - in every order).

The mirroring endpoints seem be created properly. I've explored all steps in the msdn "Troubleshooting Database Mirroring Setup" document, checking the various system tables for status, etc. but it is to no avail.

I disabled the 'VIA' protocol in the Configuartion Manager, one of the hints I found from the various newsgroups i've browsed.

I am trying to mirror (without a witness) between two instances on the same server. I am well aware that this is not supported, but I need to kick the tires in a testing playground.

Is this a common problem? The lack of postings with this issue indicate that it may not be, but honestly, i'm stymied.

If anyone has encountered and solved this, please respond, and hopefully it will help others as well.

Cheers,

brentj

|||Can you just please tell use how to start the sql service with trace flag 1400.|||

chanmm wrote:

Can you just please tell use how to start the sql service with trace flag 1400.

You don't need the trace flag if you install SP1 which has now released.

Otherwise if SP1 isn't yet an option (which it really should be if you want to use db mirroring), you can add -T1400 as a startup parameter via the SQL Configuration Manager, properties of the SQL Server service -> advanced tab ->Startup Parameters.

it's not particularly well indexed or cross-referenced but BOL has details here :

ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/c82d19e5-5557-4235-9a70-37983607a1fd.htm

thx, Simon.

|||I'm wondering if the thread started for this post resolved this issue? I have set Trace Flag 1400 "-T1400;..." in startup configuration options, rebooted and restarted servers and still not able to mirror. Also given the error "Database Mirroring Transport is disabled."

Anyone figure this out? Next I install SQL 2005 SP1.|||To update on my experience:
I installed SP1 and interestingly it even strips the Trace Flag 1400 out of the startup options for you so you don't leave that remnant of a failed Mirroring Attempt - good work guys!

I got an asynchronous mirror working after installing SQL 2005 SP1 but have not fully tested it.|||Sample is there in the updated SQL BOL docs. No gotchas except the fact that security configuration is the MOST critical. If you get that done, the rest is a breeze.