yipeee!

[Joel Garry]

Re: yipeee!

bucknuggets@yah oo.com (Buck Nuggets) wrote in message news:<66a61715. 0402041122.27cd c560@posting.go ogle.com>...[color=blue]
>
> However - one more thing: I find that my database choices usually
> hinge more on the strategic direction of the company - rather than on
> the specific needs of the application. If you go
> application-by-application you'll end up with a half-dozen different
> databases, and the skillset problem that results is typically more
> challenging than the minor technical differences between commercial
> databases.[/color]

I don't see this. Even if a company has a strategic initiative to go
to a particular database, mergers, aquisitions, and specific
application requirements still mean heterogeneity. There may be some
pure MS companies around, but I wouldn't know about them (and I don't
think MS is one of them, and of course IBM may well be its own world).

The skillset problem is challenging, but a red herring since it is
probably not a good idea as a strategic plan, except maybe in certain
small companies. Even governments that specified Oracle figured that
out. Enterprise software salespeople sell gateways, if they have to.

jg
--
@home.com is bogus.
"I don't practice Santeria." - some pop song.

http://www.signonsandiego.com/news/uniontrib/thu/currents/news_1c5cuba.html

[Joel Garry]

Re: yipeee!

pagesflames@usa .net (Dusan Bolek) wrote in message news:<1e8276d6. 0402050207.5dfd e5c9@posting.go ogle.com>...[color=blue]
> Daniel Morgan <damorgan@x.was hington.edu> wrote in message news:<107594886 8.103447@yasure >...[/color]
[color=blue]
>
> That's true, but for me real performance measurement should be done
> while everything is working. According to my experiences If you have
> proper enteprise environment outages are almost NULL and during short
> period, when you are dealing with some problem, lower performance is
> usually acceptable by business users.
> On the other hand I apriori distrust *any* benchmarks, because for me
> they're just marketing (read lies).[/color]

I guess there's no such thing as a proper enterprise environment. One
of my favorite personal war stories is the electrician who reached in
and turned off the UPS for Superdome, numerous HP's, etc.

Benchmarks are ok since they state their parameters. We all know how
to tell when a marketing person is lying...

jg
--
@home.com is bogus.

http://www.signonsandiego.com/news/uniontrib/fri/business/news_1b6madcatz.html

[Daniel Morgan]

Re: yipeee!

Joel Garry wrote:
[color=blue]
> There may be some
> pure MS companies around, but I wouldn't know about them (and I don't
> think MS is one of them, ....[/color]

MS isn't one of them. MS runs SAP for their financial system. And it
sure isn't on SQL Server.

--
Daniel Morgan

http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Mark Townsend]

Re: yipeee!

Blair Adamache wrote:[color=blue]
> Mark Townsend wrote:
>[color=green]
>> Sigh.
>>
>> Check out the #1 result at
>> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp[/color]
>
>
> Double sigh -
>
> Mark B. Townsend (Mark.Townsend@ oracle.com) also wrote:
> Subject: Re: What's the fastest database on IBM's fastest computer?
>
> Newsgroups: comp.databases. ibm-db2
> Date: 2001-06-22 14:14:01 PST
> ...
> I would contend that TPC-C on a un-clustered SMP environment is a better
> indication of database and hardware capabilities than a clustered
> result. The real challenge with clusters is not to run larger and faster
> TPC-C's, but instead to make them work in typical OLTP environments -
> where data cannot be easily partitioned.
>
>
>[/color]

Agreed. No conusion here. Benchmarks are useful exercises in
testing-to-scale, but you also need real world workloads as well. Hence
the links to the references as well ( which strangely didn't survive the
redaction ).

[Sybrand Bakker]

Re: yipeee!

On Wed, 4 Feb 2004 10:24:51 -0700, "Mark A" <ma@switchboard .net>
wrote:
[color=blue]
>
>You may not think that a true parallel query environment (what you call
>share nothing) is important, but if you look at the client list of Teradata
>and IBM who have implemented that technology, it would be obvious that you
>are wrong.[/color]

Apparently you are unaware of Oracle Parallel Execution feature.
It is recommended you do your homework prior to starting a flame to
promote a competitor product.


--
Sybrand Bakker, Senior Oracle DBA

[Mark A]

Re: yipeee!

"Sybrand Bakker" <gooiditweg@syb randb.demon.nl> wrote in message
news:30p9209m7e j6epctkncdgut2u 2ivlekhnl@4ax.c om...[color=blue]
> On Wed, 4 Feb 2004 10:24:51 -0700, "Mark A" <ma@switchboard .net>
> wrote:
>[color=green]
> >
> >You may not think that a true parallel query environment (what you call
> >share nothing) is important, but if you look at the client list of[/color][/color]
Teradata[color=blue][color=green]
> >and IBM who have implemented that technology, it would be obvious that[/color][/color]
you[color=blue][color=green]
> >are wrong.[/color]
>
> Apparently you are unaware of Oracle Parallel Execution feature.
> It is recommended you do your homework prior to starting a flame to
> promote a competitor product.
> --
> Sybrand Bakker, Senior Oracle DBA[/color]

I was responding to someone who said that share nothing is not important and
that share everything scales just as well.

I don't know what you mean by "competitor product," since I am not
associated with Oracle or IBM other than having used both products. But, I
don't really understand why Oracle trolls come on this forum to denigrate
Oracle competitors. Well, maybe I do understand.

[Daniel Morgan]

Re: yipeee!

Mark A wrote:
[color=blue]
> I was responding to someone who said that share nothing is not important and
> that share everything scales just as well.[/color]

I didn't say as well ... I said better. As you scale shared nothing the
time between failures decreases ... you are more likely to have a
failure and thus zero performance. With shared everything the time
between failures increases ... you are less likely to have a failure
that brings down the system.

That some people don't seem to concern themselves with 7x24x365 uptime
may explain why their product isn't used by most major web sites. Alfred
E. Neuman said "What me worry" and apparently that mantra has now
changed to "Well it was running really really fast when it was up."

--
Daniel Morgan

http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

Re: yipeee!

> > I was responding to someone who said that share nothing is not important
and[color=blue][color=green]
> > that share everything scales just as well.[/color]
>
> I didn't say as well ... I said better. As you scale shared nothing the
> time between failures decreases ... you are more likely to have a
> failure and thus zero performance. With shared everything the time
> between failures increases ... you are less likely to have a failure
> that brings down the system.
>
> That some people don't seem to concern themselves with 7x24x365 uptime
> may explain why their product isn't used by most major web sites. Alfred
> E. Neuman said "What me worry" and apparently that mantra has now
> changed to "Well it was running really really fast when it was up."
>
> --
> Daniel Morgan[/color]

No one that I know suggested that share nothing be used for 7x24x365 uptime.
In fact most decision support systems need downtime to refresh their
historical data from operational systems.

You seem to ignore the fact that many companies have decision support
systems that don't require 7x24x365 uptime, that need share nothing to be
efficient, and that prefer Teradata or DB2 because of that.

[Daniel Morgan]

Re: yipeee!

Mark A wrote:
[color=blue]
> I don't know what you mean by "competitor product," since I am not
> associated with Oracle or IBM other than having used both products. But, I
> don't really understand why Oracle trolls come on this forum to denigrate
> Oracle competitors. Well, maybe I do understand.[/color]

No one came to the DB2 forum to denigrate an Oracle competitor. Get over
the insecurity. The OP asked a question about Oracle and DB2 and posted
it to both forums. A response in one forum was a response in both.

I find it fascinating that in the Oracle forum ... Oracle developers and
DBAs routinely criticize Oracle. They are honest, open, forthright, and
willing to call bad support bad support, bad policies bad policies, and
bad product implementations exactly what they are.

Apparently in the DB2 forum some are driven by insecurity, perhaps
a fear of men in blue suits, because they react to every statement that
doesn't heap praise upon DB2 as some kind of terrorist attack on God
and Country.

Get over it! It is just software.

--
Daniel Morgan

http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)

[Mark A]

Re: yipeee!


"Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
news:1076171235 .839763@yasure. ..[color=blue]
> Mark A wrote:
>[color=green]
> > I don't know what you mean by "competitor product," since I am not
> > associated with Oracle or IBM other than having used both products. But,[/color][/color]
I[color=blue][color=green]
> > don't really understand why Oracle trolls come on this forum to[/color][/color]
denigrate[color=blue][color=green]
> > Oracle competitors. Well, maybe I do understand.[/color]
>
> No one came to the DB2 forum to denigrate an Oracle competitor. Get over
> the insecurity. The OP asked a question about Oracle and DB2 and posted
> it to both forums. A response in one forum was a response in both.
>
> I find it fascinating that in the Oracle forum ... Oracle developers and
> DBAs routinely criticize Oracle. They are honest, open, forthright, and
> willing to call bad support bad support, bad policies bad policies, and
> bad product implementations exactly what they are.
>
> Apparently in the DB2 forum some are driven by insecurity, perhaps
> a fear of men in blue suits, because they react to every statement that
> doesn't heap praise upon DB2 as some kind of terrorist attack on God
> and Country.
>
> Get over it! It is just software.
>
> --
> Daniel Morgan[/color]

Daniel, I have criticized IBM about problems with DB2 many times in this
forum, especially when I think it is something that can be easily fixed.
Most recently that included poor support of the Linux environment,
especially with regard to the bash shell.

But you come here as a troll, and never as someone trying help others with
DB2 problems (other than suggesting that they switch to Oracle). Your lack
of knowledge about relational technology is appalling for someone who
teaches the subject. For example, you recently claimed that RAC was share
nothing, and then had to retract that statement. I don't believe for one
second the excuse you gave for not knowing the facts.

The truth is that you are a troll on this forum, never passing up a chance
to push Oracle as the solution to every problem. Personally, I don't care
about that, since I don't work for IBM, but I find it very distracting for
those of us trying to help others with their DB2 problems.

[Buck Nuggets]

Re: yipeee!

joel-garry@home.com (Joel Garry) wrote in message news:<91884734. 0402061455.50ec e075@posting.go ogle.com>...[color=blue]
> I don't see this. Even if a company has a strategic initiative to go
> to a particular database, mergers, aquisitions, and specific
> application requirements still mean heterogeneity. There may be some
> pure MS companies around, but I wouldn't know about them (and I don't
> think MS is one of them, and of course IBM may well be its own world).
>
> The skillset problem is challenging, but a red herring since it is
> probably not a good idea as a strategic plan, except maybe in certain
> small companies. Even governments that specified Oracle figured that
> out. Enterprise software salespeople sell gateways, if they have to.[/color]

You misread my email: I didn't and don't advocate blind and complete
adherance to a strategic direction for vendor products. I did,
however, recommend putting a lot of priority on compliance with that
strategic direction.

Sure, you can build appliations that are a mix of vb, clipper, .net,
jdbc, and mainframe COBOL. But just because those technologies might
exist in the organization is no reason to avoid attempting some
consistency.

Same issue with databases - you can support Informix, Sybase, SQL
Server, Oracle, DB2, Postgresql, MySQL, Firebird, and Access if you
want. But you'll pay more for licenses, you'll have more human-error
failures due to insufficient skillsets.

Gateways aren't an answer either - just another set of product version
constraints, and incompatibiliti es. Want to be successful with this
kind of middleware - make sure you've got experts on all databases
*AND* the gateway. Nothing like finding that you've got to upgrade a
database to support an essential new application version, but that
your gateway doesn't yet support that version.

I'd firmly recommend trying to stick to an absolute minimum number of
database and application technologies. These days, the pressure seems
to be on one open source and one commercial product in most
departments that I work with. My recommendation is often something
like:
* mysql only if you have to (if required by application you want)
* postgresql for low-end databases
* db2/sybase/oracle/informix/sql server depending on:
* application requirements
* os preferences (unix vs windows)
* cost

The fact that one database has feature a and another database doesn't
(this year), is only very seldom the best reason for selecting a
database. Decide databases exclusively on that kind of criteria and
you'll create a disaster.

[Joe Weinstein]

Re: yipeee!



Daniel Morgan wrote:
[color=blue]
> Joe Weinstein wrote:
>[color=green]
>> Yep. Also, I really don't want to sound like I'm picking only on Oracle,
>> because I complain about other DBMSes too. Oracle's TAF fooled a number
>> of customers into believing it really was Transparent Application
>> Failover,
>> but it seems to be so only for certain mostly-idle clients. The reason I
>> say this is because while there is no data loss during a failover, nor
>> even any transactional context (locks), what is lost is any
>> *computational*
>> context that the client may be relying on if it was actually doing
>> something when the failover occurred. For instance, most cursor context
>> is lost. Java clients that may have created and are re-using Prepared
>> Statements will find that all those prepared statements are now defunct,
>> and must be recreated before the client can even retry what they were
>> doing.
>> This generally means returning to the line of code right after
>> obtaining the
>> original connection. Having the connection automatically failover to an
>> appropriate backup DBMS is certainly valuable, but calling it "TAF" was
>> 'aiming high' in the marketing department, IMHO.
>> Joe[/color]
>
>
> From the client's standpoint it is completely transparent which is the
> origin of the name.
>
> Perhaps you need to come take the class I teach on RAC.[/color]

Thanks! I could use your help! I'm operating (in this topic context) as middleware
which pools JDBC connections, each of which cache prepared statements. Customer code
uses these connections, and involves them in multi-statement, multi-resource transactions.
If there is a "TAF", is there a way *I* can shield the client code from the effects
on the prepared statements they may be in the process of using?
Appreciatively,
Joe Weinstein at BEA

[Noons]

Re: yipeee!

Oh dear! The victim...

--
Cheers
Nuno Souto
wizofoz2k@yahoo .com.au.nospam
"Mark A" <ma@switchboard .net> wrote in message
news:h46Vb.242$ gu2.7915@news.u swest.net...
[color=blue]
> I don't know what you mean by "competitor product," since I am not
> associated with Oracle or IBM other than having used both products. But, I
> don't really understand why Oracle trolls come on this forum to denigrate
> Oracle competitors. Well, maybe I do understand.[/color]

[Telemachus]

Re: yipeee!



cough "10G Beta Program" cough !
"Daniel Morgan" <damorgan@x.was hington.edu> wrote in message
news:1076171235 .839763@yasure. ..[color=blue]
> Mark A wrote:
>[color=green]
> > I don't know what you mean by "competitor product," since I am not
> > associated with Oracle or IBM other than having used both products. But,[/color][/color]
I[color=blue][color=green]
> > don't really understand why Oracle trolls come on this forum to[/color][/color]
denigrate[color=blue][color=green]
> > Oracle competitors. Well, maybe I do understand.[/color]
>
> No one came to the DB2 forum to denigrate an Oracle competitor. Get over
> the insecurity. The OP asked a question about Oracle and DB2 and posted
> it to both forums. A response in one forum was a response in both.
>
> I find it fascinating that in the Oracle forum ... Oracle developers and
> DBAs routinely criticize Oracle. They are honest, open, forthright, and
> willing to call bad support bad support, bad policies bad policies, and
> bad product implementations exactly what they are.
>
> Apparently in the DB2 forum some are driven by insecurity, perhaps
> a fear of men in blue suits, because they react to every statement that
> doesn't heap praise upon DB2 as some kind of terrorist attack on God
> and Country.
>
> Get over it! It is just software.
>
> --
> Daniel Morgan
> http://www.outreach.washington.edu/e...ad/oad_crs.asp
> http://www.outreach.washington.edu/e...oa/aoa_crs.asp
> damorgan@x.wash ington.edu
> (replace 'x' with a 'u' to reply)
>[/color]

[Daniel Morgan]

Re: yipeee!

Joe Weinstein wrote:[color=blue]
>
>
> Daniel Morgan wrote:
>[color=green]
>> Joe Weinstein wrote:
>>[color=darkred]
>>> Yep. Also, I really don't want to sound like I'm picking only on Oracle,
>>> because I complain about other DBMSes too. Oracle's TAF fooled a number
>>> of customers into believing it really was Transparent Application
>>> Failover,
>>> but it seems to be so only for certain mostly-idle clients. The reason I
>>> say this is because while there is no data loss during a failover, nor
>>> even any transactional context (locks), what is lost is any
>>> *computational*
>>> context that the client may be relying on if it was actually doing
>>> something when the failover occurred. For instance, most cursor context
>>> is lost. Java clients that may have created and are re-using Prepared
>>> Statements will find that all those prepared statements are now defunct,
>>> and must be recreated before the client can even retry what they were
>>> doing.
>>> This generally means returning to the line of code right after
>>> obtaining the
>>> original connection. Having the connection automatically failover to an
>>> appropriate backup DBMS is certainly valuable, but calling it "TAF" was
>>> 'aiming high' in the marketing department, IMHO.
>>> Joe[/color]
>>
>>
>>
>> From the client's standpoint it is completely transparent which is
>> the origin of the name.
>>
>> Perhaps you need to come take the class I teach on RAC.[/color]
>
>
> Thanks! I could use your help! I'm operating (in this topic context) as
> middleware
> which pools JDBC connections, each of which cache prepared statements.
> Customer code
> uses these connections, and involves them in multi-statement,
> multi-resource transactions.
> If there is a "TAF", is there a way *I* can shield the client code from
> the effects
> on the prepared statements they may be in the process of using?
> Appreciatively,
> Joe Weinstein at BEA[/color]

Feel free to contact me off-line.

--
Daniel Morgan

http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp

http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp

damorgan@x.wash ington.edu
(replace 'x' with a 'u' to reply)