Denny,
Re the Sybase Replication server: It is a separate product and truly an impressive piece of work. While I was very impressed with Rep Server, the database is what's lacking. Jared PS. to all: if you've never used Sybase, you haven't developed a true appreciation for SQL*Plus. On Sunday 31 March 2002 15:28, Denny Koovakattu wrote: > Having worked with a lot of Sybase DBAs and having discussed why "Sybase > Architecture is Inferior to Oracle's" and having helped them > understand/learn Oracle, I know why Sybase DBAs find it difficult to > understand Oracle. But there are a few things Sybase is better at. > > - Ablility to return result sets from procedures - Ref cursors or > dbms_output donot match up to what Sybase offers > - bcp out - It's time Oracle came up with some utility to extract the data > in ascii format other than recommending "sqlplus and spool" > - Replication - I like the Sybase replication architecture. This is a lot > closer to what Quest offers (Shareplex). > - Seperation of Schema and normal users. - The closest you could get to > this is by using "alter session set current_schema". I am not familiar with > LDAP. I believe we could be having something similar soon. > > If you compare the architecture of both the products, Sybase architecture > is inferior to Oracle. My favorite is the way the transaction logs are > managed in Sybase. Its both the rollback segments and redo logs (but only > one log) rolled into one. Simple explanation (Unless something changed in > one of the newer versions) - The log gets reused only after checkpointed > transactions are cleared. Open transactions will NOT be checkpointed. But > open transactions will not be skipped to checkpoint commited transactions. > All it takes is one small open transaction to fill up the log. And if the > Sybase Server goes down at this point, recovery has to start at this point, > replaying all the transactions including commited ones. I know of cases > where recovery took hours because of this. And the lack of rollback > segments mean Sybase has to put a shared lock on tables during SELECTs to > get a read consistent view of the data. But then Sybase replication may not > work without this "architecture". > > I remember reading "The good thing about Oracle is it's so tunable and > the bad thing about Oracle is it's so tunable". Change "tunable" to > "features/options" and I guess that will explain why anybody who doesn't > really understand the architecture find it so overwhelming. Try comparing > Oracle Backup and Recovery options to Sybase's. Oracle has a lot of > features/options than Sybase. Lack of understanding of the product make > them not like the product. But I don't understand somebody not > understanding the product after working on it for 3 years. My imagination's > not up to the task ;) > > Translating Sybase lingo to Oracle is not easy. In most cases there is no > direct match. > > Oracle Instance - Sybase doesn't have one > Oracle Database - Sybase Server > Oracle Schema - Sybase Database (Not completely true. The > Sybase Database also has storage allocated to it. More like a minature > database within a database. For practical purposes schema makes sense.) > SYS User - sa User > SYS Schema & SYSTEM tablespace - master Database > Schema Owner - dbo User (Database Owner) > Users (Non-Schema Owners) - Sybase Login/Users > alter session > set current_schema=SCHEMA - use DATABASE > Tablespace - Segment > Datafile - Device (There can be multiple segments on > a singe device.) > > Regards, > Denny > > Rachel Carmichael wrote: > > Ian, > > > > Having worked with Sybase years ago, I developed this "translation" > > > > Sybase instance = Oracle database > > Sybase database = Oracle tablespace > > Sybase dbo user = Oracle sys user > > Sybase master database = Oracle SYSTEM tablespace > > > > anyone have a better explanation? > > > > Rachel > > > > --- "MacGregor, Ian A." <[EMAIL PROTECTED]> wrote: > > > Well, that certainly was interesting!! No database will always > > > compare favorably to others for every feature. There are some tings > > > SYBASE does better than Oracle. However, he is either ignorant of > > > such things as the "no logging" directive, or refuses to consider > > > them because they are not part of SYBASE. I believe that is his real > > > point, Oracle ain't Sybase. If methods to accomplish a task differ > > > Oracle's way is wrong. Oracle has lagged other database vendors in > > > facilitating getting the data out of the database, while doing a > > > superior job of lessening the chances of losing data. > > > > > > Perhaps someone with SYBASE experience can explain exactly what a > > > database is to Sybase. I infer from the posting that having > > > thousands of them on a single server is common place. I imagine it's > > > the opposite of parallel server: instead of multiple instances > > > associated with a single set of database files, a single instance is > > > associated with multiple sets of database files. Each set of files > > > being a database. > > > > > > Ian MacGregor > > > Stanford Linear Accelerator Center > > > [EMAIL PROTECTED] > > > > > > -----Original Message----- > > > Sent: Friday, March 29, 2002 10:43 AM > > > To: Multiple recipients of list ORACLE-L > > > > > > > > > Dear list, > > > > > > Feel like having a good rant? Need to take some frustrations > > > out on lies, ignorance and misinformation? > > > > > > I received a document from a friend that live in both the Sybase > > > and Oracle worlds. He was interested in my comments on it > > > as he recognized it as a rant against Oracle that was full of > > > misinformation. > > > > > > Oracle has it's problems, but if you want to rant about it's > > > inadequacies, you should at least be accurate. > > > > > > Some of the things in here I can't address, such as the > > > IEEE number formats. > > > > > > Others are just plain stupid. > > > > > > The writer claims to have spent 3 years with Oracle, but he's > > > either lying or extraordinarily incompetent, I dunno which. > > > > > > Here's my proposal: I'm turning this document loose to the list. > > > I was going to comment on it myself, but it's fairly lengthy, and I > > > just don't have time to do it myself. > > > > > > Besides, I know that some of you relish such opportunities. :) > > > > > > It's in MS Word format. If you want to make comments about > > > any section of the document, include your comments in blue > > > font below that section. > > > > > > I will compile the comments, and send the annotated document > > > back to my friend. He can distribute it to his Sybase DBA friends > > > if he likes. > > > > > > I was kidding about the ranting. Please keep it objective and > > > professional. > > > > > > Please include your name at the top of the document. Tell me if > > > you want your name and email address included in the finished > > > document. > > > > > > The document can be found at: > > > > > > http://www.cybcon.com/~jkstill/Oracle_from_a_Sybase_DBA.doc > > > > > > Thanks, > > > > > > Jared -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jared Still INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).