> Even more frustrating is when the queries "work", the syntax is implemented on
> the engines in such a way that you get different result sets.

Oh, yeah.
That's always a lot of fun to figure out.

---

Grant
Darwin NT

As far as I know most of the important tables in the SETI DB are running on the InnoDB storage engine. This uses most of the same techniques that the Oracle DMBS does to stay consistent.

> The company I work for has code that works with several different DBs. The
> hook is that all but the simplest queries have to be written specifically for
> each DB. Sometimes this is distinctly not pretty.

My experience exactly.

Only simple embedded SQL is common and sometimes not even then. When you get to stored procedures and triggers, well, it is all over ...

Even more frustrating is when the queries "work", the syntax is implemented on the engines in such a way that you get different result sets.

---

> I guess the point I was trying (unsuccessfully I think) to make is that if
> Oracle or DB2 were to be used (or even, shudder, SQL Server), enough would be
> so unique to that system that making a change would be difficult, therefor
> prevening easy migration to anouther platform.
>
> Indeed, it is possible that UCB might have gotten a waiver on licecning
> costs for themselves. But they would not be able to guarenttee it from all
> projects to follow ...
>
The company I work for has code that works with several different DBs. The hook is that all but the simplest queries have to be written specifically for each DB. Sometimes this is distinctly not pretty.

---

BOINC WIKI

I guess the point I was trying (unsuccessfully I think) to make is that if Oracle or DB2 were to be used (or even, shudder, SQL Server), enough would be so unique to that system that making a change would be difficult, therefor prevening easy migration to anouther platform.

Indeed, it is possible that UCB might have gotten a waiver on licecning costs for themselves. But they would not be able to guarenttee it from all projects to follow ...

---

Oracle does have it's own benefits, but they come at a fairly hefty price tag. When I was taking DBA 1, we were looking at about $80,000 per year liscensing fee for Oracle Enterprise 9i.

On the upside, one could download Oracle 9i (we had 9i SR 2, 9i b, however they designated the second 9i version). Sorry, can't view a file with more specific identifier info from the zip file containing the installer without extracting it all), and I'm not looking to install it now). Basically one needs the liscensing to put a server in production. But if it's used by students to learn the software, isn't put into production (used for backend testing) one doesn't need to liscense it. Not until they open it up, and use it in production... That's how we were able to set Enterprise up on our home PCs to get more practice with administering it...

But on the downside, when this would go public...that's a heafty liscensing cost the the staff at Berkely aren't needing to incur now... Unless they specifically need it, I couldn't see telling someone they should go with Oracle, even if it was somewhat through Oracle (indirectly) that I learned something of dB admin...

An improper shutdown of Oracle wouldn't necessarily be unproblematic however. The power being bumped could be a problem on Oracle as well... What they need to do, is what they're doing already, find a way to gracefully shut down their servers in the event of these inordinately high number of power outages...

---

> But supporting something confined to just Oracle, DB2, SQL Server and
> MySQL/MaxDB should be easier, as long as you keep it confined to basic SQL.

Actually, that is a problem too ...

> Once you get into stored procedures, triggers, etc. it might get hairy, but
> still doable.

It means writing code one of two ways, one is to make a copy written in each dialect with significant potential for platform bugs ...

OR, making a code generator that extracts information from a form and converts that into platform specific code ... many design tools claim to do this, including Oracle's (Designer).

My experience with all of them is that as soon as you go above one table none of them generate correct scripts ... I wrote my own (One of the reasons I loved Designer, I could get at the content of the design database).

---

> On your past experience supporting all those databases, I bet that was a
> hoot, especially having to go from both ends of the spectrum: Oracle to
> Access. But supporting something confined to just Oracle, DB2, SQL Server and
> MySQL/MaxDB should be easier, as long as you keep it confined to basic SQL.
> Once you get into stored procedures, triggers, etc. it might get hairy, but
> still doable.

The biggest issue that I see is that the developers would need some sort of access to Oracle, DB2, MS-SQL, MySQL and MaxDB so they could verify that the applications all spoke a common dialect, or at least spoke SQL with the proper accent.

---

>Berkeley: Gentlemen, thankyou for joining us. What would you like to propose?
>Larry: 10 Servers, unlimited user license and 10 man years of development >time.
>Bill: I'll raise you a server, and 10 Gold Support calls
>Larry: I'll see your server, and raise you lifetime gold support
>Bill: See you, and raise ya with 1 keynote speech at the next ms conference.
>Larry: Seen, plus 1 years free advertising for users, and a go on my yacht
>Bill: 1 years advertising (cough) on MSN (cough) and a go on Melinda
>Berkeley: Melinda??? Your wife??? Congratulations Larry, we look forward to ?>your help!

>Thats all we need to do!!! ;o)))))


Pretty funny SwissNic! I like your thinking!! Alhough if Larry threw in some of his girlfriends, it could get awefull competitive.

On your past experience supporting all those databases, I bet that was a hoot, especially having to go from both ends of the spectrum: Oracle to Access. But supporting something confined to just Oracle, DB2, SQL Server and MySQL/MaxDB should be easier, as long as you keep it confined to basic SQL. Once you get into stored procedures, triggers, etc. it might get hairy, but still doable.

---

> > Hey, what can I say, it is a talent ... I can break almost any software
> by
> > looking at it ...
>
> Don't turn your head in the direction of Berkeley, Paul. Please....just DON'T.
> ;)
>
>

i feel you Paul, i can break stuff by looking at it too...
when i was working 12hr shifts in operations, my 3rd or 4th day of the week everything would just start breaking. Service ppl would come in work on it for hours, and find nothing wrong...

weird electromagnetic fields i guess.

does make my PC hobby expensive though, i blew 2 power supplies in a matter of 10 minutes, one i would place to it being a bit old, the other was brand new....
of course it could all be coincidence..

Micah

---

S@h Berkeley's Staff Friends Club

> Hey, what can I say, it is a talent ... I can break almost any software by
> looking at it ...

Don't turn your head in the direction of Berkeley, Paul. Please....just DON'T. ;)

---

Be lucky

Neil

> Paul, I have to disagree on your statement that a "power failure can make
> Oracle inconsistant". I do not see how this is true. From a database
> perspective, as long as you do not turn off the standard reliability features,
> it will be consistant after startup if you pull the rug out from under it.
> Short of a serious disk crash, or OS or human error where a file was deleted,
> the database should be fine. This goes for SQL Server and DB2 as well. SQL
> Transactions are not the same thing as DB transaction integrity and
> redo-logging.

Yes, well, we didn't and I did ... so I do know that it can be done.

Hey, what can I say, it is a talent ... I can break almost any software by looking at it ...

Anyway, I did not say it happened all the time, or was even that likely, because yes, Oracle (DB2, and the other main DBMS - of which, sad to say *I* personnally would not include MS SWL Server, any edition) are designed to not do that.

I am sure that MySQL is also designed to do that too ... however, it does not have the hundreds of person years refining the product that the mainstay DBMS have. Since Open Source does collect some real good talent, I would expect to see that MySQL will likewise improve over time.

---

A few years back, i was writing software for the pensions industry (yawn)... Our programs had to work with a variety of DB's - depending on what the customer had or wanted. We supported MSSQL, Oracle, Paradox and Access. We used standard SQL whereever possible, and programed exceptions depending on DB_Type where db-specific code was required...

It's not so big of a task as you might think - migrating a back-end DB to another manufacturer - they could even just add support for other DB's, then the project owner could choose which one they wanted to use.

If BOINC could support MySQL, MaxDB, Borland Interbase, MSSQL and Oracle it would help other projects leverage existing IT resources... Maybe you could get Mirco$oft and Oracle to bid sponsorship to have the right to be associated with BOINC... ;o))))

Berkeley: Gentlemen, thankyou for joining us. What would you like to propose?
Larry: 10 Servers, unlimited user license and 10 man years of development time.
Bill: I'll raise you a server, and 10 Gold Support calls
Larry: I'll see your server, and raise you lifetime gold support
Bill: See you, and raise ya with 1 keynote speech at the next ms conference.
Larry: Seen, plus 1 years free advertising for users, and a go on my yacht
Bill: 1 years advertising (cough) on MSN (cough) and a go on Melinda
Berkeley: Melinda??? Your wife??? Congratulations Larry, we look forward to your help!

Thats all we need to do!!! ;o)))))

---

> I think the MaxDB product, if available in open source,
> should be given some serious consideration.

It is. Same dual licence as MySQL - GPL and commercial.

---

Be lucky

Neil

Paul, I have to disagree on your statement that a "power failure can make Oracle inconsistant". I do not see how this is true. From a database perspective, as long as you do not turn off the standard reliability features, it will be consistant after startup if you pull the rug out from under it. Short of a serious disk crash, or OS or human error where a file was deleted, the database should be fine. This goes for SQL Server and DB2 as well. SQL Transactions are not the same thing as DB transaction integrity and redo-logging.

Now, if you get a damaged disk farm, file deletion, etc., you might have to restore the database, but assuming you put the redo-logs on a different disk, you should be able to roll forward to the point of failure, with consistant and logical transactions. This assumes that you actually back up the data (using RMAN or even the Export utility). Now, it is possible to write logically incorrect code to purposely hose up a database in the case of failure, but in my experience this is pretty hard to do with Oracle and DB2: I have only seen it one time with Oracle, and a later patch release rendered that point moot. I cannot comment on SQL Server or Sybase.

Regarding SQL standards, you are correct that nobody adhears to the standard, but in reality what you get is a superset of the standard. IIRC, pretty much everybody adhears to SQL-92, I think even MySQL.

My beef was that, as a database guy, I would have a whole lot of explaining to do to my boss if my systems went down and I lost data, or could not be back up in 30-60 minutes. I think the MaxDB product, if available in open source, should be given some serious consideration.

---

As someone said, " ... the nice thing about standards is we have so many to choose from ... " ...

WIth that said, Oracle (much as i like it) is no perfect cure. Power outages can also make the Oracle database, um, inconsistent. Granted they do have probably a better transaction management system than MySQL does. But, MySQL has not the years of refinement that Oracle has ...

I did not do a search, but, I am sure that the later versions of MySQL have transactions, heck they have triggers now ...

BUT, just like many companies are still running NT 4.0; you cannot, and usually will not, rip up the system just to make a change to keep Bill's bank account happy.

Re: SQL, there is a standard SQL, but to my best knowledge, no vendor truly compiles with the standard. For one thing, where is the test suite to validate conformance? Ada had one, W3C has one for XHTML, there was even on for FORTRAN many moons ago. Converting from MySQL to Oracle would probably not be that hard, but you also have to validate that the results created are truly the same.

Oh, and just to FULLY stay complient with Open Source, even the database itself is open for inspection if a project wants to make sure that it compilies with their desire to KNOW all the code ...

---

Also just because Berkeley had a power supply problem didn't effect the other projects. I may have run out of seti work (but that was only due to having a relatively small cache) but I my computer didn't stop crunching the whole time thanks to project resource sharing.

BOINC what a great concept.

Live long and crunch!

---

Paul
(S@H1 8888)
And proud of it!

Well, there is a heavy-duty version of MySQL called MaxDB which is available under the same licensing arrangements as MySQL itself.

Quote:

Today, about 6,000 customer installations are using MaxDB technology globally, including Toyota, Intel, DaimlerChrysler, Braun-Gillette, Bayer, Colgate, Yamaha, and Deutsche Post (the German Post Office).


More information here

---

Be lucky

Neil

> Bottom line is, we are used to a reliability standard set by the corp's, and
> therefore we want to expect that level from BOINC, as it is a multi-project
> high-profile high-value truely global scientific research platform. Given the
> historical significance of this work, (and as it is the ethos of open-source
> software) we should all feel responsibility to use our particular skillsets to
> improve all aspects of the project whenever we can!

BOINC is also an experiment in and of itself.

Part of that experiment is "can we design an overall project with high-reliability that does not require high-reliability at the servers?"

... because high-reliability costs money, and making BOINC accessible (i.e. cheap!) is a big part of the overall goal.

One problem I see: BOINC is like E-Mail. Most of the time, when a mail server is down for an hour or two, users don't even notice. I suspect that most BOINC crunchers didn't really notice the outage for the past few days.

Most of us here have BOINC under a microscope. We see everything. I watch closely because it is interesting to see how things work, and to think about what might make things better. Some watch because they're afraid the flow of credits will stop (I guess -- that's a mystery to me).

As a general rule, though, we're way too busy saying "this project doesn't meet commercial criteria!" and losing sight of the fact that sometimes "good enough" really is.

I also think that the project should get someone from the Sociology department involved because as you said "we're used to commercial reliability" and I think BOINC is also a fascinating study in human behaviour.

---

> We need to be careful about using the term "SETI" and "BOINC" as if they were
> interchangable.
>
> If BOINC required Oracle (and it was donated to SETI) then CPDN would have to
> get Oracle, and Predictor would have to get Oracle, and LHC would have to get
> Oracle, and Einstein would have to get Oracle.
>
> Take LHC as an example. They turned up LHC@home on a shoestring: some old
> machines for servers and a bunch of free software. It worked incredibly well
> so they are buying new hardware and dedicating resources.
>
> They could probably get budget for Oracle, but if they had to buy an Oracle
> license to start, well, they probably wouldn't have.

And not to mention another few projects that are not public knowledge, one of which is run via a one man band doing his phd thesis.

---

Paul
(S@H1 8888)
And proud of it!