Oracle Response 7

Oracle's Response (7)

26. A Sybase database is roughly equivalent to an Oracle schema. There is no limit on the number of Oracle schemas. Why anyone would want 32,767 databases on a single machine is beyond me.

Mr. Conway is not aware how far Oracle falls short, even when the distance is the square root of Sybase. A Sybase database is not equivalent to an Oracle schema. A Sybase database is equivalent to an Oracle instance. A Sybase server supports up to 32,767 databases, the equivalent of 32,767 Oracle instances. Each one of Sybase's 32,767 databases can have tens of thousands of its own users.

When you buy Sybase, you get 32,767 times more flexibility than Oracle. Mr. Conway asks what one does with that? The fact is, is that a company generally has about 5 major multiuser application systems each requiring its own database with its own security. To accomplish that in Oracle, you will need to buy 5 Oracle Enterprise products at $40,000 a piece because you will need 5 Oracle instances to do it.

Sybase, on the other hand, comes with the capability to manage not just 5, but up to 32,767 independent databases with a single Sybase ASE Server. For the company's five application systems, you have already saved over $200,000.

The question is not "why would anyone want 32,767 databases on a single machine." The question is why anyone would want Oracle and spend $36,000 more each time the company wants a new application system. That is beyond me. One can work around the security and naming problems so that one instance can support 5 application systems each with its own thousands of users. Unfortunately, the expense of programming the work-arounds will cost you even more.

Oracle charges you an exorbitant price not because of its added functionality, but because you think a higher cost means a better product. The purpose of these web pages it is show you that Oracle is not worth more, but is worth magnitudes less than Sybase.

27. Create indexes PARALLEL NOLOGGING UNRECOVERABLE. It is faster, and doesn't use temp or rollback or redo. Large tables are usually partitioned, so you can create indexes piece-wise in parallel. Can Sybase create a large partitioned index in parallel?

NOLOGGING and UNRECOVERABLE cannot be used at the same time, nor do they prevent the index from writing to rollback segments. Oracle phased out UNRECOVERABLE and replaced it with NOLOGGING. The UNRECOVERABLE option does not exist in the 8i or 9i manuals. While NOLOGGING prevents the index from writing to the redo logs, it does prevent the index from writing to rollback segments.

Sybase and MS SQL Server do not write the individual rows of an index to its transaction log. Either the index gets created or it doesn't. Sybase and MS SQL Server do not employ rollback segments, so there is no overhead there either. Oracle's NOLOGGING keyword, seemingly a feature, is really only a kludge. It still does not prevent Oracle from writing the entire index to a rollback segment.. Also, since Oracle uses the TEMPORARY tablespace to sort indexes, Oracle writes to the rollback segments on the temporary tablespace.

As for partitioned indexes, Sybase can create a large partitioned clustered index in parallel. Sybase cannot partition a non-clustered index. While I can see the use of a partitioned non-clustered index, it would not be used often, if at all. Sybase and MS SQL Server process non-clustered indexes rapidly anyway (no redo and no rollback segments overhead). A partitioned clustered index, however, is useful. Sybase supports that.

A note here. The definition of clustered differs between Sybase and Oracle. A Sybase table which has a clustered index is roughly the equivalent of an Oracle index-organized table.

28. Rollback segments disappear in 9i, so this statement is false.

Rollback segments do not disappear in 9i. And a confession: Creating indexes needlessly uses rollback segments. Apparently Mr. Conway, the Systems Engineering Manager of Oracle, does not know Oracle. Rollback segments still exist in Oracle 9i. The disappearance of rollback segments is only skin-deep. In 9i, Oracle automatically creates and maintains rollback segments for you. While the DBA no longer has to set them up, Oracle still employs them.

29. (see 27)

Confession: create index writes to the redo logs for no reason. You can avoid the senseless processing if you specify NOLOGGING in your create index statement.

30. This was a bug, fixed in 8.1.7.

Confession: Oracle will step over its shared memory bounds when creating an index, after which every user on the instance hangs. I discovered this problem in 8.1.7.

31. To the Oracle dba dbcc, readers & writers of data blocking each other, and using a single log to do redo & undo sounds idiotic.

We already covered dbcc.

Readers & writers blocking data: All databases, even Oracle, must do that. But what I think Mr. Conway is referring to, is Sybase's page-level locking. Sybase has two locking schemes, page-level and row-level. The default is page-level. Sybase will lock an entire page's worth of rows, not just a single row, during an update. This can cause Sybase to block other processes who are trying to read or write to the same page.

There is one good reason to use page-level locking:

1. It is fast. It is fast because it uses less resources. Far fewer locks. Much less memory.

There is one good reason to use page-level locking:

1. Your programmers write code like:

begin transaction
select id, name from employees
Ask information from user.
User goes to the bathroom.
update employees set id = @new_id, name = @new_name
commit transaction

Sybase programmers never keep a transaction open while their user goes to the bathroom. Oracle programmers think nothing of that because hoarding and wasting resources is a favorite Oracle pasttime. Uncommitted long transactions are commonplace, even expected. Such transactions fuel the fire of why Oracle requires rollback segments, redo and undo logs. Oracle expects transactions to abort. Which leads to . . .

Sybase's overall design. Sybase's basic architecture is the product of an optimist. Sybase assumes that programmers want to commit transactions, not roll them back. If a programmer is as smart as he should be, he should never undo, redo or rollback anything. Undo or redo exist only for emergencies. That is why Sybase has one log for one database. That is efficient.

(As far as Sybase having one transaction log per database, Mr. Conway attempts to equate a barrel of apples with a single apple. Sybase supports 32,767 databases per server. That means that Sybase supports 32,767 logs per server. Mr. Conway does not see this because Oracle only supports 1 database per server. )

Oracle's overall design comes from a pessimist. That is because Oracle is its own reason. It's a chicken and the egg paradox. As opposed to Sybase, Oracle promotes and allows errors. SQL*Plus does not provide the tools to prevent errors. Instead, SQL*Plus uses the try and bomb paradigm. WHENEVER SQLERROR and WHENEVER OSERROR give the programmer license to allow errors to happen. Oracle expects the programmer not to check SQL before executing it since there are no real tools to do it. Oracle expects and allows the programmer to create stored procedures with errors. With all this crashing and burning, rollback, undo and redo become the standard, not the emergency. It is because of this, that Oracle gives its DBAs 2-tiers of logs for each tablespace. Oracle needs to save Oracle from itself.

Programming without errors is an axiom. One learns it in high school. It is the normal to do. But Oracle is not normal. The laws of the universe change in Oracle. Normal to Oracle, is to bomb and ignore your error.



	© 2010 Talus Software. All Rights Reserved. Home \| Buy Software \| Privacy