IA64 teradata OLE-DB or ODBC

I have a 32 bit development/playbox SQL 2005 SSIS that can see and run 32 bit OLE DB drivers from Teradata. Granted I have the same issues as others where a table or a view would work and not a query or a variable query. The alternative is to use Linked Server and OPENQUERY.

But our real development box is a 64 bit IA 64 using 64 bit SQL 2005. Non of the Teradata.com drivers would work/show up in the dropdown box of the Connection Manager since they are 32 bit. One option is to use the 64 bit Teradata ODBC drivers and then use the .Net ODBC connection instead. Linked server doesn't work either because the SQL 2005 is 64 bit and it is looking for 64 bit drivers.

Has anyone have any experience with 64 bit SQL 2005 and Teradata?

Looked at other 3rd party vendors such as ETI but their documentation excludes IA 64 (Itanium).

Planning to try again using the 64 bit ODBC and .Net Adapter but I'm interested to hear if someone (MSFT & NCR) would have a real solution for 64 bit.

Thanks

Anatole

I'm replying to my own thread as I want to see who else is having the same issue using Teradata Drivers and SSIS (32 or 64 bit).

I think this is a given where the Teradata OLE-DB driver is failing when used as a SQL Stmt rather than Table/View to extract data.

The message is:

An OLE DB error has occurred. Error code: 0x80040E21.An OLE DB record is available. Source: "OLE DB Provider for Teradata" Hresult: 0x80040E21 Description: "Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done."

Has anyone found a work-around and/or contacted MS about this?

I opened a ticket with teradata/ncr but they are pointing back at SSIS and MS.

This error can occur on any box/cpu (32 bit or 64bit).

Since ODBC adaptor in SSIS converts everything into UNICODE, the only option is to use Linkedserver and OPENQUERY cmd.

I would like to hear back from MS (I know thay have teradata servers) or anyone that has either received this error and has a solution OR is also waiting on one.

Thanks

Anatole

|||

Anatole,

Take a look at :

www.openlinksw.com/

They seem to have an IA64 OLE to ODBC driver. I am not sure I even understand the issue well enough, but we had a similar issue and found them, we are still looking to see if they can solve our issue witch is with Sybase and SQL, but I thought I would just throw it out there for you since you had not gotten anyone to reply back, it might at least give you a better lead....

Hope it helps...

Steve

|||

2 other potential resources are:

www.odbcsdk.com

This is another Third Party (Open Access) that advertises a 64bit OLEDB to ODBC Data Provider (Itanium).

http://www.datadirect.com/products/odbc64/overview/index.ssp

This is another Third Party (DataDirect) that advertises a 64bit Sybase ODBC driver (Itanium)

Just trying to be helpful for people running into these types of problems....Hopefully this is helpful...

Steve

|||

Hi!

See also my similar question (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=853174&SiteID=1&mode=1).

I can't work out your suggestion using a ".net ODBC".

B.G.

IA64 teradata OLE-DB or ODBC

I have a 32 bit development/playbox SQL 2005 SSIS that can see and run 32 bit OLE DB drivers from Teradata. Granted I have the same issues as others where a table or a view would work and not a query or a variable query. The alternative is to use Linked Server and OPENQUERY.

But our real development box is a 64 bit IA 64 using 64 bit SQL 2005. Non of the Teradata.com drivers would work/show up in the dropdown box of the Connection Manager since they are 32 bit. One option is to use the 64 bit Teradata ODBC drivers and then use the .Net ODBC connection instead. Linked server doesn't work either because the SQL 2005 is 64 bit and it is looking for 64 bit drivers.

Has anyone have any experience with 64 bit SQL 2005 and Teradata?

Looked at other 3rd party vendors such as ETI but their documentation excludes IA 64 (Itanium).

Planning to try again using the 64 bit ODBC and .Net Adapter but I'm interested to hear if someone (MSFT & NCR) would have a real solution for 64 bit.

Thanks

Anatole

I'm replying to my own thread as I want to see who else is having the same issue using Teradata Drivers and SSIS (32 or 64 bit).

I think this is a given where the Teradata OLE-DB driver is failing when used as a SQL Stmt rather than Table/View to extract data.

The message is:

An OLE DB error has occurred. Error code: 0x80040E21.An OLE DB record is available. Source: "OLE DB Provider for Teradata" Hresult: 0x80040E21 Description: "Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done."

Has anyone found a work-around and/or contacted MS about this?

I opened a ticket with teradata/ncr but they are pointing back at SSIS and MS.

This error can occur on any box/cpu (32 bit or 64bit).

Since ODBC adaptor in SSIS converts everything into UNICODE, the only option is to use Linkedserver and OPENQUERY cmd.

I would like to hear back from MS (I know thay have teradata servers) or anyone that has either received this error and has a solution OR is also waiting on one.

Thanks

Anatole

|||

Anatole,

Take a look at :

www.openlinksw.com/

They seem to have an IA64 OLE to ODBC driver. I am not sure I even understand the issue well enough, but we had a similar issue and found them, we are still looking to see if they can solve our issue witch is with Sybase and SQL, but I thought I would just throw it out there for you since you had not gotten anyone to reply back, it might at least give you a better lead....

Hope it helps...

Steve

|||

2 other potential resources are:

www.odbcsdk.com

This is another Third Party (Open Access) that advertises a 64bit OLEDB to ODBC Data Provider (Itanium).

http://www.datadirect.com/products/odbc64/overview/index.ssp

This is another Third Party (DataDirect) that advertises a 64bit Sybase ODBC driver (Itanium)

Just trying to be helpful for people running into these types of problems....Hopefully this is helpful...

Steve

|||

Hi!

See also my similar question (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=853174&SiteID=1&mode=1).

I can't work out your suggestion using a ".net ODBC".

B.G.

sql

IA64 bit Performance vs X64 - Update statistics

Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server i
s
4-way SQL EE x64, 9 GB RAM.
At the end of the day (just prior to midnight) I backup the prod database,
then run update statistics fullscan on 13 tables, 30% scan on 9 other tables
.
Elapsed time is 4.5 hrs.
I can restore the backup just taken on prod over to Dev, run the same update
statistics process from Prod on Dev and the elapsed time on Dev is 3.25 hour
s.
Any ideas that adequately explain the difference in elapsed time?
--
jl"John L" <JohnL@.discussions.microsoft.com> wrote in message
news:FE1A33F1-2EA1-4FF6-8E5B-6D469E398BB9@.microsoft.com...
> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server
> is
> 4-way SQL EE x64, 9 GB RAM.
> At the end of the day (just prior to midnight) I backup the prod
> database,
> then run update statistics fullscan on 13 tables, 30% scan on 9 other
> tables.
> Elapsed time is 4.5 hrs.
> I can restore the backup just taken on prod over to Dev, run the same
> update
> statistics process from Prod on Dev and the elapsed time on Dev is 3.25
> hours.
> Any ideas that adequately explain the difference in elapsed time?
Perhaps your dev server is just faster than your production server.
David|||I forgot to mention that the SQL 2000 version for both is SP4.
--
jl
"John L" wrote:

> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server
is
> 4-way SQL EE x64, 9 GB RAM.
> At the end of the day (just prior to midnight) I backup the prod database
,
> then run update statistics fullscan on 13 tables, 30% scan on 9 other tabl
es.
> Elapsed time is 4.5 hrs.
> I can restore the backup just taken on prod over to Dev, run the same upda
te
> statistics process from Prod on Dev and the elapsed time on Dev is 3.25 ho
urs.
> Any ideas that adequately explain the difference in elapsed time?
> --
> jl|||Trying to have that make sense to mgt would be a challenge even though I
inherited these servers. The dev box does have faster CPUs than the prod
server. Regrettably mgt listened to someone's notion that the IA64 servers
were "high performers" Maybe that pitch was referring Oracle on Linux :-)
--
jl
"David Browne" wrote:

> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> news:FE1A33F1-2EA1-4FF6-8E5B-6D469E398BB9@.microsoft.com...
> Perhaps your dev server is just faster than your production server.
> David
>
>|||Hi John,
x64 is definitely better than the IA64 processor. But, you cannot really
compare your production numbers to the development numbers because
Production usually has a lot more going on VS your Dev environment. Plus,
you should check your waitstats counters, filestats, and various other
perfmon counters to get a better picture on the difference in performance.
-Shiva
"John L" <JohnL@.discussions.microsoft.com> wrote in message
news:555B3999-CFF7-43BD-80E3-D85B863623E0@.microsoft.com...[vbcol=seagreen]
>I forgot to mention that the SQL 2000 version for both is SP4.
> --
> jl
>
> "John L" wrote:
>|||Shiva:
I might be guilty of some gross oversimplification here. I agree that
production servers theoretically have more going on with them but this an 8-
5
organization meaning that there is no user activity during the time frames i
n
which these maintenance activities occur (on either server). Ruling out
application related traffic generated by end-users, I am left with elapsed
job times. The IA 64 single core box (prod) runs at 4.5 hours ( replace the
single core CPUs with dual core IA 64s and the run time goes up to 6.25
hours), the EMT64T single core box (dev) runs in 3.25 hours.
The EMT64T's are 3600 Mhz CPUS, IA 64 single cores are 1500 Mhz, and the IA
64 dual cores are 1200 Mhz.
My hope with this post was that perhaps there was someone else out there who
had seen something the same or similar in an IA 64 environment. I am gettin
g
the feeling that there were not many who chose to go with SQL 2000 64-bit on
the IA 64 which may be why SQL 2005 is the only MS product certified for IA
64. I fully expect them to drop support for this architecture especially if
the marketplace doesn't ask for it.
There might be a very simple explanation for the observed phenonmenon and
that is simply CPU speed as David Browne has already hinted at.
jl
"Shiva" wrote:

> Hi John,
> x64 is definitely better than the IA64 processor. But, you cannot really
> compare your production numbers to the development numbers because
> Production usually has a lot more going on VS your Dev environment. Plus,
> you should check your waitstats counters, filestats, and various other
> perfmon counters to get a better picture on the difference in performance.
> -Shiva
> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> news:555B3999-CFF7-43BD-80E3-D85B863623E0@.microsoft.com...
>
>|||Hi,
I don't think that updating statistics is the right load to test Itanium2
processor. Based on my experiences when you update statistics, only one
processor is used so it doesn't matter how many cores you have. There is
usually a lot of disk activity involved (depending on amount of RAM) so disk
subsistem has important role here.
I've been testing SQL2000 sp4 IA64 on Itanium2 and found out that when
running simple querries (basic selects...where...) Itanium2 is almost never
faster, usualy is 10-20% slower than Xeon, BUT when running more complex
querries like large complex joins, sorts on large amounts of data, Itanium
is always faster. More complex querry it is and more data is executing on,
faster it is comparing to Xeon. I think that Itanium is best suited for
running large reports, OLAP, complex calculations and so on, when X64 on
Xeons is faster for simple busines applications.
I've also noticed that processor parallelism is much better implemented on
IA64 than running the same load on SQL2000 sp4 x64 or x86. Using 2 Itaniums
relly made execution times for a lot of procedures almost twice as fast than
using one proccesor. When running the same load on Xeons, parallelism made
it actually slower.
I'm begining to test it on SQL2005. So far, a lot of procedures are faster
then on SQL2000.....
Those are my experiences so far...
Tom
"John L" <JohnL@.discussions.microsoft.com> wrote in message
news:12FCED74-D78D-4912-A81F-13732A833316@.microsoft.com...[vbcol=seagreen]
> Shiva:
> I might be guilty of some gross oversimplification here. I agree that
> production servers theoretically have more going on with them but this an
> 8-5
> organization meaning that there is no user activity during the time frames
> in
> which these maintenance activities occur (on either server). Ruling out
> application related traffic generated by end-users, I am left with elapsed
> job times. The IA 64 single core box (prod) runs at 4.5 hours ( replace
> the
> single core CPUs with dual core IA 64s and the run time goes up to 6.25
> hours), the EMT64T single core box (dev) runs in 3.25 hours.
> The EMT64T's are 3600 Mhz CPUS, IA 64 single cores are 1500 Mhz, and the
> IA
> 64 dual cores are 1200 Mhz.
> My hope with this post was that perhaps there was someone else out there
> who
> had seen something the same or similar in an IA 64 environment. I am
> getting
> the feeling that there were not many who chose to go with SQL 2000 64-bit
> on
> the IA 64 which may be why SQL 2005 is the only MS product certified for
> IA
> 64. I fully expect them to drop support for this architecture especially
> if
> the marketplace doesn't ask for it.
> There might be a very simple explanation for the observed phenonmenon and
> that is simply CPU speed as David Browne has already hinted at.
> --
> jl
>
> "Shiva" wrote:
>|||Tom:
A funny thing about our IA64 experience is that our h/w mgr jumped out and
bought dual core CPUs for the server. After installation the UPDATE STATS
took 1.25 hrs longer than with the single core IA64 CPUs.
Thanks for sharing your experience, this is exactly the sort of feedback
that I have been seeking.
jl
"Tom" wrote:

> Hi,
> I don't think that updating statistics is the right load to test Itanium2
> processor. Based on my experiences when you update statistics, only one
> processor is used so it doesn't matter how many cores you have. There is
> usually a lot of disk activity involved (depending on amount of RAM) so di
sk
> subsistem has important role here.
> I've been testing SQL2000 sp4 IA64 on Itanium2 and found out that when
> running simple querries (basic selects...where...) Itanium2 is almost nev
er
> faster, usualy is 10-20% slower than Xeon, BUT when running more complex
> querries like large complex joins, sorts on large amounts of data, Itanium
> is always faster. More complex querry it is and more data is executing on,
> faster it is comparing to Xeon. I think that Itanium is best suited for
> running large reports, OLAP, complex calculations and so on, when X64 on
> Xeons is faster for simple busines applications.
> I've also noticed that processor parallelism is much better implemented on
> IA64 than running the same load on SQL2000 sp4 x64 or x86. Using 2 Itanium
s
> relly made execution times for a lot of procedures almost twice as fast th
an
> using one proccesor. When running the same load on Xeons, parallelism made
> it actually slower.
> I'm begining to test it on SQL2005. So far, a lot of procedures are faster
> then on SQL2000.....
> Those are my experiences so far...
> Tom
>
>
> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> news:12FCED74-D78D-4912-A81F-13732A833316@.microsoft.com...
>
>

IA64 bit Performance vs X64 - Update statistics

Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server is
4-way SQL EE x64, 9 GB RAM.
At the end of the day (just prior to midnight) I backup the prod database,
then run update statistics fullscan on 13 tables, 30% scan on 9 other tables.
Elapsed time is 4.5 hrs.
I can restore the backup just taken on prod over to Dev, run the same update
statistics process from Prod on Dev and the elapsed time on Dev is 3.25 hours.
Any ideas that adequately explain the difference in elapsed time?
--
jl"John L" <JohnL@.discussions.microsoft.com> wrote in message
news:FE1A33F1-2EA1-4FF6-8E5B-6D469E398BB9@.microsoft.com...
> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server
> is
> 4-way SQL EE x64, 9 GB RAM.
> At the end of the day (just prior to midnight) I backup the prod
> database,
> then run update statistics fullscan on 13 tables, 30% scan on 9 other
> tables.
> Elapsed time is 4.5 hrs.
> I can restore the backup just taken on prod over to Dev, run the same
> update
> statistics process from Prod on Dev and the elapsed time on Dev is 3.25
> hours.
> Any ideas that adequately explain the difference in elapsed time?
Perhaps your dev server is just faster than your production server.
David|||I forgot to mention that the SQL 2000 version for both is SP4.
--
jl
"John L" wrote:
> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server is
> 4-way SQL EE x64, 9 GB RAM.
> At the end of the day (just prior to midnight) I backup the prod database,
> then run update statistics fullscan on 13 tables, 30% scan on 9 other tables.
> Elapsed time is 4.5 hrs.
> I can restore the backup just taken on prod over to Dev, run the same update
> statistics process from Prod on Dev and the elapsed time on Dev is 3.25 hours.
> Any ideas that adequately explain the difference in elapsed time?
> --
> jl|||Trying to have that make sense to mgt would be a challenge even though I
inherited these servers. The dev box does have faster CPUs than the prod
server. Regrettably mgt listened to someone's notion that the IA64 servers
were "high performers" Maybe that pitch was referring Oracle on Linux :-)
--
jl
"David Browne" wrote:
> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> news:FE1A33F1-2EA1-4FF6-8E5B-6D469E398BB9@.microsoft.com...
> > Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev server
> > is
> > 4-way SQL EE x64, 9 GB RAM.
> >
> > At the end of the day (just prior to midnight) I backup the prod
> > database,
> > then run update statistics fullscan on 13 tables, 30% scan on 9 other
> > tables.
> > Elapsed time is 4.5 hrs.
> >
> > I can restore the backup just taken on prod over to Dev, run the same
> > update
> > statistics process from Prod on Dev and the elapsed time on Dev is 3.25
> > hours.
> >
> > Any ideas that adequately explain the difference in elapsed time?
> Perhaps your dev server is just faster than your production server.
> David
>
>|||Hi John,
x64 is definitely better than the IA64 processor. But, you cannot really
compare your production numbers to the development numbers because
Production usually has a lot more going on VS your Dev environment. Plus,
you should check your waitstats counters, filestats, and various other
perfmon counters to get a better picture on the difference in performance.
-Shiva
"John L" <JohnL@.discussions.microsoft.com> wrote in message
news:555B3999-CFF7-43BD-80E3-D85B863623E0@.microsoft.com...
>I forgot to mention that the SQL 2000 version for both is SP4.
> --
> jl
>
> "John L" wrote:
>> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev
>> server is
>> 4-way SQL EE x64, 9 GB RAM.
>> At the end of the day (just prior to midnight) I backup the prod
>> database,
>> then run update statistics fullscan on 13 tables, 30% scan on 9 other
>> tables.
>> Elapsed time is 4.5 hrs.
>> I can restore the backup just taken on prod over to Dev, run the same
>> update
>> statistics process from Prod on Dev and the elapsed time on Dev is 3.25
>> hours.
>> Any ideas that adequately explain the difference in elapsed time?
>> --
>> jl|||Shiva:
I might be guilty of some gross oversimplification here. I agree that
production servers theoretically have more going on with them but this an 8-5
organization meaning that there is no user activity during the time frames in
which these maintenance activities occur (on either server). Ruling out
application related traffic generated by end-users, I am left with elapsed
job times. The IA 64 single core box (prod) runs at 4.5 hours ( replace the
single core CPUs with dual core IA 64s and the run time goes up to 6.25
hours), the EMT64T single core box (dev) runs in 3.25 hours.
The EMT64T's are 3600 Mhz CPUS, IA 64 single cores are 1500 Mhz, and the IA
64 dual cores are 1200 Mhz.
My hope with this post was that perhaps there was someone else out there who
had seen something the same or similar in an IA 64 environment. I am getting
the feeling that there were not many who chose to go with SQL 2000 64-bit on
the IA 64 which may be why SQL 2005 is the only MS product certified for IA
64. I fully expect them to drop support for this architecture especially if
the marketplace doesn't ask for it.
There might be a very simple explanation for the observed phenonmenon and
that is simply CPU speed as David Browne has already hinted at.
--
jl
"Shiva" wrote:
> Hi John,
> x64 is definitely better than the IA64 processor. But, you cannot really
> compare your production numbers to the development numbers because
> Production usually has a lot more going on VS your Dev environment. Plus,
> you should check your waitstats counters, filestats, and various other
> perfmon counters to get a better picture on the difference in performance.
> -Shiva
> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> news:555B3999-CFF7-43BD-80E3-D85B863623E0@.microsoft.com...
> >I forgot to mention that the SQL 2000 version for both is SP4.
> > --
> > jl
> >
> >
> > "John L" wrote:
> >
> >> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev
> >> server is
> >> 4-way SQL EE x64, 9 GB RAM.
> >>
> >> At the end of the day (just prior to midnight) I backup the prod
> >> database,
> >> then run update statistics fullscan on 13 tables, 30% scan on 9 other
> >> tables.
> >> Elapsed time is 4.5 hrs.
> >>
> >> I can restore the backup just taken on prod over to Dev, run the same
> >> update
> >> statistics process from Prod on Dev and the elapsed time on Dev is 3.25
> >> hours.
> >>
> >> Any ideas that adequately explain the difference in elapsed time?
> >> --
> >> jl
>
>|||Hi,
I don't think that updating statistics is the right load to test Itanium2
processor. Based on my experiences when you update statistics, only one
processor is used so it doesn't matter how many cores you have. There is
usually a lot of disk activity involved (depending on amount of RAM) so disk
subsistem has important role here.
I've been testing SQL2000 sp4 IA64 on Itanium2 and found out that when
running simple querries (basic selects...where...) Itanium2 is almost never
faster, usualy is 10-20% slower than Xeon, BUT when running more complex
querries like large complex joins, sorts on large amounts of data, Itanium
is always faster. More complex querry it is and more data is executing on,
faster it is comparing to Xeon. I think that Itanium is best suited for
running large reports, OLAP, complex calculations and so on, when X64 on
Xeons is faster for simple busines applications.
I've also noticed that processor parallelism is much better implemented on
IA64 than running the same load on SQL2000 sp4 x64 or x86. Using 2 Itaniums
relly made execution times for a lot of procedures almost twice as fast than
using one proccesor. When running the same load on Xeons, parallelism made
it actually slower.
I'm begining to test it on SQL2005. So far, a lot of procedures are faster
then on SQL2000.....
Those are my experiences so far...
Tom
"John L" <JohnL@.discussions.microsoft.com> wrote in message
news:12FCED74-D78D-4912-A81F-13732A833316@.microsoft.com...
> Shiva:
> I might be guilty of some gross oversimplification here. I agree that
> production servers theoretically have more going on with them but this an
> 8-5
> organization meaning that there is no user activity during the time frames
> in
> which these maintenance activities occur (on either server). Ruling out
> application related traffic generated by end-users, I am left with elapsed
> job times. The IA 64 single core box (prod) runs at 4.5 hours ( replace
> the
> single core CPUs with dual core IA 64s and the run time goes up to 6.25
> hours), the EMT64T single core box (dev) runs in 3.25 hours.
> The EMT64T's are 3600 Mhz CPUS, IA 64 single cores are 1500 Mhz, and the
> IA
> 64 dual cores are 1200 Mhz.
> My hope with this post was that perhaps there was someone else out there
> who
> had seen something the same or similar in an IA 64 environment. I am
> getting
> the feeling that there were not many who chose to go with SQL 2000 64-bit
> on
> the IA 64 which may be why SQL 2005 is the only MS product certified for
> IA
> 64. I fully expect them to drop support for this architecture especially
> if
> the marketplace doesn't ask for it.
> There might be a very simple explanation for the observed phenonmenon and
> that is simply CPU speed as David Browne has already hinted at.
> --
> jl
>
> "Shiva" wrote:
>> Hi John,
>> x64 is definitely better than the IA64 processor. But, you cannot really
>> compare your production numbers to the development numbers because
>> Production usually has a lot more going on VS your Dev environment. Plus,
>> you should check your waitstats counters, filestats, and various other
>> perfmon counters to get a better picture on the difference in
>> performance.
>> -Shiva
>> "John L" <JohnL@.discussions.microsoft.com> wrote in message
>> news:555B3999-CFF7-43BD-80E3-D85B863623E0@.microsoft.com...
>> >I forgot to mention that the SQL 2000 version for both is SP4.
>> > --
>> > jl
>> >
>> >
>> > "John L" wrote:
>> >
>> >> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev
>> >> server is
>> >> 4-way SQL EE x64, 9 GB RAM.
>> >>
>> >> At the end of the day (just prior to midnight) I backup the prod
>> >> database,
>> >> then run update statistics fullscan on 13 tables, 30% scan on 9 other
>> >> tables.
>> >> Elapsed time is 4.5 hrs.
>> >>
>> >> I can restore the backup just taken on prod over to Dev, run the same
>> >> update
>> >> statistics process from Prod on Dev and the elapsed time on Dev is
>> >> 3.25
>> >> hours.
>> >>
>> >> Any ideas that adequately explain the difference in elapsed time?
>> >> --
>> >> jl
>>|||Tom:
A funny thing about our IA64 experience is that our h/w mgr jumped out and
bought dual core CPUs for the server. After installation the UPDATE STATS
took 1.25 hrs longer than with the single core IA64 CPUs.
Thanks for sharing your experience, this is exactly the sort of feedback
that I have been seeking.
--
jl
"Tom" wrote:
> Hi,
> I don't think that updating statistics is the right load to test Itanium2
> processor. Based on my experiences when you update statistics, only one
> processor is used so it doesn't matter how many cores you have. There is
> usually a lot of disk activity involved (depending on amount of RAM) so disk
> subsistem has important role here.
> I've been testing SQL2000 sp4 IA64 on Itanium2 and found out that when
> running simple querries (basic selects...where...) Itanium2 is almost never
> faster, usualy is 10-20% slower than Xeon, BUT when running more complex
> querries like large complex joins, sorts on large amounts of data, Itanium
> is always faster. More complex querry it is and more data is executing on,
> faster it is comparing to Xeon. I think that Itanium is best suited for
> running large reports, OLAP, complex calculations and so on, when X64 on
> Xeons is faster for simple busines applications.
> I've also noticed that processor parallelism is much better implemented on
> IA64 than running the same load on SQL2000 sp4 x64 or x86. Using 2 Itaniums
> relly made execution times for a lot of procedures almost twice as fast than
> using one proccesor. When running the same load on Xeons, parallelism made
> it actually slower.
> I'm begining to test it on SQL2005. So far, a lot of procedures are faster
> then on SQL2000.....
> Those are my experiences so far...
> Tom
>
>
> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> news:12FCED74-D78D-4912-A81F-13732A833316@.microsoft.com...
> > Shiva:
> >
> > I might be guilty of some gross oversimplification here. I agree that
> > production servers theoretically have more going on with them but this an
> > 8-5
> > organization meaning that there is no user activity during the time frames
> > in
> > which these maintenance activities occur (on either server). Ruling out
> > application related traffic generated by end-users, I am left with elapsed
> > job times. The IA 64 single core box (prod) runs at 4.5 hours ( replace
> > the
> > single core CPUs with dual core IA 64s and the run time goes up to 6.25
> > hours), the EMT64T single core box (dev) runs in 3.25 hours.
> >
> > The EMT64T's are 3600 Mhz CPUS, IA 64 single cores are 1500 Mhz, and the
> > IA
> > 64 dual cores are 1200 Mhz.
> >
> > My hope with this post was that perhaps there was someone else out there
> > who
> > had seen something the same or similar in an IA 64 environment. I am
> > getting
> > the feeling that there were not many who chose to go with SQL 2000 64-bit
> > on
> > the IA 64 which may be why SQL 2005 is the only MS product certified for
> > IA
> > 64. I fully expect them to drop support for this architecture especially
> > if
> > the marketplace doesn't ask for it.
> >
> > There might be a very simple explanation for the observed phenonmenon and
> > that is simply CPU speed as David Browne has already hinted at.
> >
> > --
> > jl
> >
> >
> > "Shiva" wrote:
> >
> >> Hi John,
> >>
> >> x64 is definitely better than the IA64 processor. But, you cannot really
> >> compare your production numbers to the development numbers because
> >> Production usually has a lot more going on VS your Dev environment. Plus,
> >> you should check your waitstats counters, filestats, and various other
> >> perfmon counters to get a better picture on the difference in
> >> performance.
> >>
> >> -Shiva
> >>
> >> "John L" <JohnL@.discussions.microsoft.com> wrote in message
> >> news:555B3999-CFF7-43BD-80E3-D85B863623E0@.microsoft.com...
> >> >I forgot to mention that the SQL 2000 version for both is SP4.
> >> > --
> >> > jl
> >> >
> >> >
> >> > "John L" wrote:
> >> >
> >> >> Prod server is a 4-way IA64 running SQL EE(64-bit), 32 GB RAM. Dev
> >> >> server is
> >> >> 4-way SQL EE x64, 9 GB RAM.
> >> >>
> >> >> At the end of the day (just prior to midnight) I backup the prod
> >> >> database,
> >> >> then run update statistics fullscan on 13 tables, 30% scan on 9 other
> >> >> tables.
> >> >> Elapsed time is 4.5 hrs.
> >> >>
> >> >> I can restore the backup just taken on prod over to Dev, run the same
> >> >> update
> >> >> statistics process from Prod on Dev and the elapsed time on Dev is
> >> >> 3.25
> >> >> hours.
> >> >>
> >> >> Any ideas that adequately explain the difference in elapsed time?
> >> >> --
> >> >> jl
> >>
> >>
> >>
>
>sql

I wants Confirming the Jobs on the sql server by use query

Hello ! ^^
I'm Jae sik in South Korea
I have win2003 (64 bit DataCent Ed) and sql 2000 64 bit Ed. and 1:1
Cluster
I wants Confirming the Jobs on the sql server by use query
How can i do this ?
Thanks.
If I understand that you want to see the SQL Server Agent
Jobs, then you will find that information in the [msdb]
database.
There are three tables that I look at to try to weed my way
an undocumented system. (fun!!!!)
[sysjobs]
[sysjobsteps]
[sysjobschedules]
All in [msdb]
all tables relate to the column [job_id] in
the [sysjobs] tables.
I hope that is what you're looking for, but if not, please
clarify.
Good Luck!
jg

Quote:

Originally posted by
Hello ! ^^
I'm Jae sik in South Korea
I have win2003 (64 bit DataCent Ed) and sql 2000 64 bit Ed. and 1:1
Cluster
I wants Confirming the Jobs on the sql server by use query
How can i do this ?
Thanks.

|||Hi
If I understand you correctly, you are asking how to check the status of SQL
Agent Jobs.
In MSDB, there are the tables called sysjobs, systasks and sysjobsteps.
Querying those will give you the information.
For a complete map of the system tables, get systbl.chm from
http://www.microsoft.com/sql/techinf.../systables.asp
Regards
Mike
"1?à???" wrote:

> Hello ! ^^
> I'm Jae sik in South Korea
> I have win2003 (64 bit DataCent Ed) and sql 2000 64 bit Ed. and 1:1
> Cluster
> I wants Confirming the Jobs on the sql server by use query
> How can i do this ?
> Thanks.
>
>
|||Thanks mike epprecht
"" <jsmin@.techdata.co.kr> wrote in message
news:#5utCWT$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> Hello ! ^^
> I'm Jae sik in South Korea
> I have win2003 (64 bit DataCent Ed) and sql 2000 64 bit Ed. and 1:1
> Cluster
> I wants Confirming the Jobs on the sql server by use query
> How can i do this ?
> Thanks.
>

I want to install SSIS on a 64 bit server without SQL Server on it

I want to install SSIS on a 64 bit server without SQL Server on it.

Say I want to install the SSIS engine on one server and have it call packages stored on another servers msdb.

It this possible?

Yes. It does require a SQL license for the server with SSIS on it, as well as the server with the database engine.

I want to have a live link to data from SQL Server

This is a bit confusing but here goes: I need to access data in SAP via OLE DB. I can't go direct to the back end database (Oracle), we have to use RFC or BAPI calls to access the SAP data. That's part works, we have a DLL that accesses the SAP data we need.

Next I would like to be able to access the data in that DLL with something like:
Select * from view_SAPData.

We messed around with extended stored procedures and it looked good for a bit because we could call the extended proc from a stored proc and we could create a view from a function so I figured we could make it work, but we couldn't.

So now I'm asking you nice folks if there is a way we can provide a dataset to SQL Server from our DLL? I don't know much about DMO, is there anything there?

Hope this makes sense.
TIA,
Blaise

Hi blaise,

You would to use Microsoft .NET Data Provider for mySAP Business Suite:

http://download.microsoft.com/download/f/7/4/f74cbdb1-87e2-4794-9186-e3ad6bd54b41/DataProviderSAP.exe

You could to see more info about it, here:

Feature Pack for Microsoft SQL Server 2005
http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-AA0A-B477BA72A9CB&displaylang=en

Good Coding!

Javier Luna
http://guydotnetxmlwebservices.blogspot.com/

sql

I want to have a live link to data from SQL Server

This is a bit confusing but here goes: I need to access data in SAP via OLE DB. I can't go direct to the back end database (Oracle), we have to use RFC or BAPI calls to access the SAP data. That's part works, we have a DLL that accesses the SAP data we need.

Next I would like to be able to access the data in that DLL with something like:
Select * from view_SAPData.

We messed around with extended stored procedures and it looked good for a bit because we could call the extended proc from a stored proc and we could create a view from a function so I figured we could make it work, but we couldn't.

So now I'm asking you nice folks if there is a way we can provide a dataset to SQL Server from our DLL? I don't know much about DMO, is there anything there?

Hope this makes sense.
TIA,
Blaise

Hi blaise,

You would to use Microsoft .NET Data Provider for mySAP Business Suite:

http://download.microsoft.com/download/f/7/4/f74cbdb1-87e2-4794-9186-e3ad6bd54b41/DataProviderSAP.exe

You could to see more info about it, here:

Feature Pack for Microsoft SQL Server 2005
http://www.microsoft.com/downloads/details.aspx?familyid=DF0BA5AA-B4BD-4705-AA0A-B477BA72A9CB&displaylang=en

Good Coding!

Javier Luna
http://guydotnetxmlwebservices.blogspot.com/

I think this is an easy one...

If I have a 64 bit version of SQL 2005 installed, will "select @.@.version" indicate it is a 64 bit version? If not, how do I determine such? Thanks in advance.

Yes.

Code Snippet

Select @.@.version

On x64 Returns:

Code Snippet

Microsoft SQL Server 2005 - 9.00.3042.00 (X64) Feb 10 2007 00:59:02 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition (64-bit) on Windows NT 5.2 (Build 3790: Service Pack 1)

On x86:

Code Snippet

Microsoft SQL Server 2005 - 9.00.3054.00 (Intel X86) Mar 23 2007 16:28:52 Copyright (c) 1988-2005 Microsoft Corporation Developer Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

|||Excellent Sir! Thank you very much.

I really need some advice.

Hi

Dont laugh but...

I am not entirely ignorant to web technologies, and best practices but i am having a bit of a planning dylema.

My company has a well established SQL 2000 database with windows application which has been created by myself, what i am planning on doing is creating a web site, using asp.net and publishing some of the information, so that our clients may use it, and stop pestering us on the phone. what i would like to know is what would be the best way forward, obviously i don't want to show them all our information, and don't want to put 5Gb worth of data onto a ISP website. What would you suggest i do?

Thanks in advance

BradHow important is it that the data be real-time?

You might consider implementing some DTS packages that extract key pieces of data that you want to share with your clients. The DTS package would write to a database on a separate server.

Terri

I need help with what appears to be a botched install.

Okay, i'm learning VB.NET (and having quite a bit of fun with it). Well, I had the old beta version. Anyway, went away for a week and found I could no longer use it. Why?

"Beta period is over.".

Yeah, it sucks.

Well, I uninstalled it via the uninstaller. I upgraded my .NET framework, etc, and redownloaded VB.NET. Everything installed okay, save for the SQL server. It repeatedly fails.

I have hunted down and shot each component quite ruthlessly, but I don't know what beta component remains. I can't get it to install because it says I have beta components left.

And VB.NET works. Barely. I had to disable the hosting process, otherwise it gives me a message about an invalid binding handle. Not often that a Beta product works better than the production one.

The uninstall tool won't work for some reason. I'm this close to just reformatting.

Please help, I'd like to code again.

Thanks.

bump|||Hi,

if you also had SQL Server beta installed you should also deinstall SQL Server as in the Beta period the SQL Server framework version and the version of the framework VS uses had to be in line.So installing VS / SQL Server / Framework version, reboot, installing SQL Server / VS (Framework is installed with one of the two) should make your system running :-)

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

I need help with what appears to be a botched install.

Okay, i'm learning VB.NET (and having quite a bit of fun with it). Well, I had the old beta version. Anyway, went away for a week and found I could no longer use it. Why?

"Beta period is over.".

Yeah, it sucks.

Well, I uninstalled it via the uninstaller. I upgraded my .NET framework, etc, and redownloaded VB.NET. Everything installed okay, save for the SQL server. It repeatedly fails.

I have hunted down and shot each component quite ruthlessly, but I don't know what beta component remains. I can't get it to install because it says I have beta components left.

And VB.NET works. Barely. I had to disable the hosting process, otherwise it gives me a message about an invalid binding handle. Not often that a Beta product works better than the production one.

The uninstall tool won't work for some reason. I'm this close to just reformatting.

Please help, I'd like to code again.

Thanks.

bump|||Hi,

if you also had SQL Server beta installed you should also deinstall SQL Server as in the Beta period the SQL Server framework version and the version of the framework VS uses had to be in line.So installing VS / SQL Server / Framework version, reboot, installing SQL Server / VS (Framework is installed with one of the two) should make your system running :-)

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de