Re: Informix to Oracle Migration

nobody wrote: >> Actually this is not true. And it is that misconception that is the >> heart of what I am pointing out. The exact same code doing the exact >> same thing. Or put another way the exact same transaction architecture >> put on all of the products you list will absolutely, definitely, and >> unconditionally fail on one or more of them except by unadulterated >> luck. >> > So where did you get your education in software development? You're > clearly not an engineer. Stanford and I now teach at the University of Washington to answer your question. > The point I am trying to make is that I *can* write a POS system where > the underlying data storage is abstracted. Which is totally irrelevant to the point I made. > (And yes, I have written > several applications where the client wanted database portability. Oh > and with JDBC, you really do have it. JDBC is irrelevant to transaction architecture. You clearly know a lot about somethings and very little about the differences in architecture between the major commercial RDBMS products. > Its called abstraction of the data storage layer. And is, as stated above, completely irrelevant to the differences in architecture to which I refer. >> A wise person doesn't trust luck to make an application behave properly. >> >> What amazes me is that this mythology, mythology that you have repeated >> here, is so widespread. It may be widely believed ... but the fact that >> many repeat it does not make it so. > > Myth? > Junior, learn the art of software development and then talk to me. "Junion" is likely as old or older than your father. You make assumptions about me as on-target as those about RDBMS architecture: No surprise there methinks. > JDBC doesn't care what the data storage layer looks like, as long as it > conforms to a published API spec. And JDBC is irrelevant to what I have brought up as an issue. Perhaps a good read of Tom Kyte's "Expert one-on-one Oracle" ... just the first three chapters ... would help you. Well that or reading the concept docs for the major RDBMS products but that I suspect would be asking too much. > Having said that, your "myth" is now grounded in reality. I've read words without grounding in fact. JDBC is irrelevant to tranaction architecture. JDBC is irrelevant to basic RDBMS concepts implemented differently by different companies in different products. You've not argued any point. You have attacked this issue as would a politician. By ignoring that which you don't understand and repeating your campaign slogan. You don't get my vote because your statements are, while true, irrelevant. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"DA Morgan" <damorgan@x.washington.edu> wrote You first wrote:- >Actually this is not true. And it is that misconception that is the >heart of what I am pointing out. The exact same code doing the exact >same thing. Or put another way the exact same transaction architecture >put on all of the products you list will absolutely, definitely, and >unconditionally fail on one or more of them except by unadulterated >luck. and also wrote:- > JDBC is irrelevant to transaction architecture. You clearly know a lot > about somethings and very little about the differences in architecture > between the major commercial RDBMS products. not taking sides with any one here, but u are out of whack when u suggest that *all* RDBMs have different architecture to such an extent that if a product is to support different RDBMs, one has to code accordingly. Well that applies to only Oracle. That is, a product can be developed with the same locking, transaction and isolation strategy for Informix, SQL Server/Sybase and DB2 and it will work just fine. The one RDBMS which requires a different mindset is Oracle and only Oracle. If you read the documentation of SQL Server 2005, they clearly mention that the main reason for introducing Oracle like versioning in 2005 is to make it easy for ISV's who develop a product for both Oracle and SS.

rkusenet wrote: > "DA Morgan" <damorgan@x.washington.edu> wrote > > You first wrote:- > > >>Actually this is not true. And it is that misconception that is the >>heart of what I am pointing out. The exact same code doing the exact >>same thing. Or put another way the exact same transaction architecture >>put on all of the products you list will absolutely, definitely, and >>unconditionally fail on one or more of them except by unadulterated >>luck. > > > and also wrote:- > > >>JDBC is irrelevant to transaction architecture. You clearly know a lot >>about somethings and very little about the differences in architecture >>between the major commercial RDBMS products. > > > not taking sides with any one here, but u are out of whack when u suggest > that *all* RDBMs have different architecture to such an extent that if > a product is to support different RDBMs, one has to code accordingly. Well > that applies to only Oracle. That is, a product can be developed with > the same locking, transaction and isolation strategy for Informix, > SQL Server/Sybase and DB2 and it will work just fine. The one RDBMS > which requires a different mindset is Oracle and only Oracle. > > If you read the documentation of SQL Server 2005, they clearly mention > that the main reason for introducing Oracle like versioning in 2005 is > to make it easy for ISV's who develop a product for both Oracle and SS. I never said "ALL" I said one or more in the list I provided which was: DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same transaction model. And whether one approaches them with ODBC or JDBC or any other driver set will have no affect on the transaction model or best practice. Tom Kyte clearly spells this out in the book I referenced. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"DA Morgan" <damorgan@x.washington.edu> wrote in message news:1113804286.177778@yasure... > I never said "ALL" I said one or more in the list I provided which was: > DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same > transaction model. there u go again. Only Oracle in the above list does not share the same transaction model. When u or Tom Kyte mentions "they do not share", it is not entirely true. Only oracle does not share the same model. Don't u think there is a subtle difference in mentioning "they do not share the same transaction model" to "only oracle does not share the same transaction model" . > Tom Kyte clearly spells this out in the book I referenced. Been reading it. I have reached upto Chapter 5. Excellent book though the obvious Oracle slant makes me chuckle. Mr. Kyte definitely knows how to put his slanted (and incorrect views) in an interesting manner.

DA Morgan wrote: > rkusenet wrote: > >> "DA Morgan" <damorgan@x.washington.edu> wrote >> You first wrote:- >> >> >>> Actually this is not true. And it is that misconception that is the >>> heart of what I am pointing out. The exact same code doing the exact >>> same thing. Or put another way the exact same transaction architecture >>> put on all of the products you list will absolutely, definitely, and >>> unconditionally fail on one or more of them except by unadulterated >>> luck. >> >> >> >> and also wrote:- >> >> >>> JDBC is irrelevant to transaction architecture. You clearly know a lot >>> about somethings and very little about the differences in architecture >>> between the major commercial RDBMS products. >> >> >> >> not taking sides with any one here, but u are out of whack when u suggest >> that *all* RDBMs have different architecture to such an extent that if >> a product is to support different RDBMs, one has to code accordingly. >> Well >> that applies to only Oracle. That is, a product can be developed with >> the same locking, transaction and isolation strategy for Informix, >> SQL Server/Sybase and DB2 and it will work just fine. The one RDBMS >> which requires a different mindset is Oracle and only Oracle. >> >> If you read the documentation of SQL Server 2005, they clearly mention >> that the main reason for introducing Oracle like versioning in 2005 is >> to make it easy for ISV's who develop a product for both Oracle and SS. > > > I never said "ALL" I said one or more in the list I provided which was: > DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same > transaction model. > > And whether one approaches them with ODBC or JDBC or any other driver > set will have no affect on the transaction model or best practice. > > Tom Kyte clearly spells this out in the book I referenced. I have the book Tom-Kyte-Oracle-expert-one-on-one book and it does say that Oracle is different from all the others, which supports the statement that rkusenet said. ( what he said ). Starting on page 124. It **is** relevant to point out that Oracle has gone out of its way to be MORE complex, not less complex, when dealing with transactions compared to most if not all other major database products on the market. ( Which is quite humorous in light of Oracles' campaign to "reduce complexity". ) One of the reasons I believe, reading Mr. Kytes book, that there is more complexity, is to simply provide non-blocking reads and non-blocking writes. Having worked with just about all the non-Oracle products out there, I would find this feature very desirable in a high transaction environment, but the cost to implement it reminds me that this feature is not in use in quite a few environments quite successfully. I would hardly expect this to even be understood by a majority of systems that choose not to use Oracle. ( SQL-Server shops especially! ) The trick is to commit writers fast enough that the readers don't notice. Instead, through better design of the system non-Oracle systems can perform quite well without non-blocking reads/writes. The downside is that the development team must know how to provide transactions that do not block readers without help from the database engine. I've worked in one system using SQL-Server where this is probably one of the chief complaints, during peak usage, lots and lots of blocking writes preventing readers from getting to the data. It is more a design of the application and the application mindset ( COM objects etc ) that actually introduces these problems, not necessarily a problem with the database engine. The developers choose to let their environment literally throw data over the fence at the database without really controlling what is happening--thus leaving the transaction at the mercy of the database engine. In older non-Microsoft environments, most developers know how to control their transactions, and thusly can use a non-Oracle system quite efficiently. I guess according to what was said about Microsoft is that they are essentially saying they will adopt the Oracle method because they know their developers are too lazy to control their transactions. For the smart money a manager will have to size up their team and go with the database engine that works best for the talent pool they can find to make their business work. Which is why the database market will continue to have everybody-else vs. Oracle for generations to come.

"Data Goob" <datagoob@netscape.net> wrote > The downside is that the development team must know how to provide transactions > that do not block readers without help from the database engine. I've worked > in one system using SQL-Server where this is probably one of the chief complaints, > during peak usage, lots and lots of blocking writes preventing readers from > getting to the data. I had the same problem in my new job wherein SQL-Server user complained of blocking. Eventually turned out to be poor design. Well it seems only Informix is the engine which automatically creates an index on foreign key. On all other RDBMSs (DB2/LUW,Oracle,SS,Sybase) one has to explicitly create an index on FKY. That's what happened in the product I am working. The developer created FKY and just didn't care about index on FKY columns. Result was that on non-indexed FKY tables, the table was locked whenever master-child table join is used. Since Oracle has versioning feature, lack of index on child table will not result in blocking despite table scan involved.

rkusenet wrote: > "Data Goob" <datagoob@netscape.net> wrote > >> The downside is that the development team must know how to provide >> transactions >> that do not block readers without help from the database engine. I've >> worked >> in one system using SQL-Server where this is probably one of the chief >> complaints, >> during peak usage, lots and lots of blocking writes preventing readers >> from >> getting to the data. > > > I had the same problem in my new job wherein SQL-Server user complained of > blocking. Eventually turned out to be poor design. Well it seems only > Informix > is the engine which automatically creates an index on foreign key. On all > other RDBMSs (DB2/LUW,Oracle,SS,Sybase) one has to explicitly create > an index on FKY. That's what happened in the product I am working. The > developer created FKY and just didn't care about index on FKY columns. > Result was that on non-indexed FKY tables, the table was locked whenever > master-child table join is used. > Since Oracle has versioning feature, lack of index on child table will > not result in > blocking despite table scan involved. > > It is the nature of Microsoft environments to create application abstraction from the database, either physically or logically, because of people wanting to program in OO. This means that many developers may not even know how to understand the complexity created by other programmers, to the point where they can't even figure out what the problem is that creates the blocker. The DBA gets involved using the few tools available such as SQL-Profiler or the sysprocesses table, but even here it is difficult to diagnose, and as such, SQL code review is paramount. But the DBA will get blamed for the poor performance or other errors and omissions created by the developers--it's a thankless job. SQL-Server has limited tuning, limited-to-none log management, so you really need to enforce index usage with table hints, and other enforcement to make sure developers do the right things. Maybe Microsoft will buy an old version of Oracle and come up with a new database engine. LOL.

rkusenet wrote: > Been reading it. I have reached upto Chapter 5. Excellent book though the > obvious Oracle slant makes me chuckle. Mr. Kyte definitely knows how > to put his slanted (and incorrect views) in an interesting manner. I would expect him to bias in Oracle's favor as he is a Vice President. But if you think there are errors of fact I invite you to come over to c.d.o.server and post the matters of fact so Tom can respond publicly to your statements rather than to inuendo. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

rkusenet wrote: > > "DA Morgan" <damorgan@x.washington.edu> wrote in message > news:1113804286.177778@yasure... > >> I never said "ALL" I said one or more in the list I provided which was: >> DB2, Informix, Oracle, SQL Server, Sybase. They do not share the same >> transaction model. > > > there u go again. Only Oracle in the above list does not share the same > transaction model. To you and Data Goob and others ... all in a single response: Of course. And if one looks at the Subject above it says: "Informix to Oracle Migration." I was trying to word my comment in such a way as to not incite a synapse-free flame war on product A vs product B. But as long as the subject is Informix to Oracle migration my comments are valid and are, as I stated, irrelevant to ODBC, JDBC, or any other front-end driver. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace 'x' with 'u' to respond)

"DA Morgan" <damorgan@x.washington.edu> wrote in message news:1113842711.76226@yasure... > rkusenet wrote: > >> Been reading it. I have reached upto Chapter 5. Excellent book though the >> obvious Oracle slant makes me chuckle. Mr. Kyte definitely knows how >> to put his slanted (and incorrect views) in an interesting manner. > > I would expect him to bias in Oracle's favor as he is a Vice President. I am aware that he is VP and that's why his obvious slant doesn't dignify his position. The book is excellent. No two questions about it. > But if you think there are errors of fact I invite you to come over to > c.d.o.server and post the matters of fact so Tom can respond publicly > to your statements rather than to inuendo. Pls read what I mentioned. I said "incorrect views" and not inaccurate facts :-) U have read his book, right? Note the clever usage of words "in Informix lock implementation is expensive" in page 102 of chapter-3. Exactly how does one quantify "row-level locks in the Informix server is expensive both in terms of time and memory". How about this: Oracle's implementation of versioning comes at a price, both in terms of memory and CPU cycles. < space here for more anti oracle comments > In chapter 5 (redo and rollback) he mentions how in some other RDBMS the transaction log contains both undo and redo information. I know SQL Server and Informix follow that model. I am not able to pull out the page number, but to paraphrase him "that architecture will be a disaster in rollback because the process is trying to read behind in the disk while processes are trying to write sequentially". While this statement is true, it has to remembered that the rollback operation itself is an exception, not a norm in any business scenario. So any performance implication of a rollback operation is moot in any technical discussion. It also seems that Mr. Kyte's experience with Informix is badly dated. His biography at the back of the book says that he has been working with Oracle Corp since 1993 and prior to working with Oracle he worked with Sybase and Informix. So which version of Informix. Version 5.? I am sure he must be knowing that Informix has something called log buffer and most of the rollbacks (to rollback the current transaction ) will be handled in the buffer itself. So how much likely is that "rollback will cause I/O contention". The fact is that neither architectures (Oracle on one hand and Informix/DB2/SS on other) has clearly proved itself to be better. I know one customer site in Calif using both Informix and Oracle and they consistently get better result in Informix than in Oracle. Of course Oracle can come up with their counter anecdotal references. Sure there is no way to prove like that. If we take TPC benchmarkings, then DB2 currently beats Oracle and SS not far behind. I am sure once I have more experience with Oracle, I can pull out more of his slants when I get my working experience with Oracle. Until then... rk- ps: And no thanks. No need to start a flame war with Mr. Kyte.

"rkusenet" <usenet.rk@gmail.com> wrote in message news:3ci8i4F6juf62U1@individual.net... > In chapter 5 (redo and rollback) he mentions how in some other RDBMS > the transaction log contains both undo and redo information. I know > SQL Server and Informix follow that model. I am not able to pull out > the page number, but to paraphrase him got it. It is actually Chapter 4 Transactions - Page 153 "many other databases treat the log files as transaction logs. they do not have this separation of redo and undo - they keep both in the same file. For those systems, the act of rolling back can be disastrous - the rollback process must read the logs their log writer is trying to write to. They introduce contention into the part of the system that can least stand it. Oracle's goal is to make it so that logs are written sequentially, and no one ever reads them while being written- ever". Note the clever way of exaggerating the operation of rollback as if in any production instance rollback is a regular business operation, worthy of being considered in any design for I/O contention.

rkusenet wrote: > > "rkusenet" <usenet.rk@gmail.com> wrote in message > news:3ci8i4F6juf62U1@individual.net... > >> In chapter 5 (redo and rollback) he mentions how in some other RDBMS >> the transaction log contains both undo and redo information. I know >> SQL Server and Informix follow that model. I am not able to pull out >> the page number, but to paraphrase him > > > got it. It is actually Chapter 4 Transactions - Page 153 > > "many other databases treat the log files as transaction logs. they do > not have this > separation of redo and undo - they keep both in the same file. For those > systems, > the act of rolling back can be disastrous - the rollback process must > read the > logs their log writer is trying to write to. They introduce contention > into the > part of the system that can least stand it. Oracle's goal is to make it > so that > logs are written sequentially, and no one ever reads them while being > written- ever". > > Note the clever way of exaggerating the operation of rollback as if in > any production > instance rollback is a regular business operation, worthy of being > considered in any design for I/O contention. > I would be willing to bet the vast majority of Oracle or MS-SQL-Server programmers/developers rarely if ever understand their databases the way an ex-Informix DBA or ex-Informix developer does. No matter who's the best, Informix was/is the best teacher by far in terms of how-to. Most of my experience is tainted with knowing what was/is the best but now having to use inferior products. DB2 in a lot of ways is probably "the best" in terms of a broad, mainstream, non-Oracle, brand-aware database that people have actually heard of, as an alternative to Oracle, but I still find a lot of favor with MySQL too. It now has a shared-nothing cluster capability that makes it quite interesting and appealing (cheap). When MySQL gets partitioning going the competition will really get interesting.