Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Mailing Lists -> Oracle-L -> OFF-TOPIC RE: opinion needed: when sqlserver & not Oracle
Re. SQL Server being easy to administer, I wish the SQL Server 7
Administration exam was just as easy.
: )
Patrice Boivin
Systems Analyst (Oracle Certified DBA)
Systems Admin & Operations | Admin. et Exploit. des syst=E8mes Technology Services | Services technologiques Informatics Branch | Direction de l'informatique=20 Maritimes Region, DFO | R=E9gion des Maritimes, MPO
E-Mail: boivinp_at_mar.dfo-mpo.gc.ca <mailto:boivinp_at_mar.dfo-mpo.gc.ca>=20
-----Original Message-----
From: Smith, Ron L. [SMTP:rlsmith_at_kmg.com] Sent: Wednesday, August 23, 2000 12:22 PM To: Multiple recipients of list ORACLE-L Subject: RE: opinion needed: when sqlserver & not Oracle We have both Oracle and SQL Server, (as well as DB2 and Adabas). SQL Server is usually selected for small applications with a dozen or fewer users. These are vendor apps which also determine which server the software goes on. We let the vendor choose because we want the project to succeed. Many vendors say they support Oracle but when it comes time to install the software it is obvious they have little or no experience with Oracle. If there is going to be little or no IT staff I would definitely choose SQL Server. Any PC literate person can stumble through maintaining SQL Server. They may not choose the fastest or best way but they will get it going. SQL Server can be ignored for an extended period of time and will usually keep running. That same PC person would have a tough time supporting Oracle with no training. Oracle is too complex and the documentation assumes you know what you are doing. Ron Smith Database Administration rlsmith_at_kmg.comof UNIX.
-----Original Message-----
Sent: Wednesday, August 23, 2000 9:32 AM To: Multiple recipients of list ORACLE-L I don't see how SQLServer is as complex to manage as Oracle when it doesn't even have things like: Parallel Server, Bitmap Indexes plus tons of other missing things. And SQLServer automatically manages memory(SGA). I can go on and on but these are the few examples. Richard Ji
-----Original Message-----
Dijken Sent: Wednesday, August 23, 2000 6:28 AM To: Multiple recipients of list ORACLE-L My $0.02 : Sqlserver is just as complex to manage as is Oracle. You face the same problems with tablespaces, performance issus, backup strategies, etc. The management tools for Oracle however (either by Oracle or 3rd party suppliers) are superior to the management tools for Sqlserver. Don't forget, you also need a system manager to handle NT on the local sites as well. Having a system manager local, you can manage your databases around the world. Be prepared to work 24 hours a day though. :o) Paul
-----Original Message-----
Sent: 22 August 2000 23:12 To: Multiple recipients of list ORACLE-L Hi, I don't want to start any holy war. I can just see the hackles rising over this one already.... I would just like an opinion on the following scenerio: An application was developed without consulting anyone who might have to actually support it (that's a whole OTHER topic). It includes having a database on an NT server at various remote sites around the world where local IT staff will be "minimal" or even non-existent. To make matters worse, I don't have any information about expected transaction volume or projected database size. I realize that I can do a fair amount of monitoring / administration remotely but, to be truthful, I'm not too crazy about supporting remote databases...especially if they are on NT instead
My question is this: at what point (txn volume / db size) would it be
reasonable to push this back to sqlserver over Oracle? Or am I just being
lazy? The assumption by management is that less well trained people could
manage sqlserver and support problems would not come to me (ha ha).
Humbly, Kip BryantReceived on Wed Aug 23 2000 - 10:51:13 CDT
--
Author: INET: Kip.Bryant_at_Vishay.com 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: ListGuru_at_fatcity.com (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).
--
Author: Paul van Dijken INET: paul.vandijken_at_sema.nl 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: ListGuru_at_fatcity.com (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).
--=20
Author: Richard Ji INET: richard_at_letsplay.com 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: ListGuru_at_fatcity.com (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).
--=20
Author: Smith, Ron L. INET: rlsmith_at_kmg.com 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: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L