[SGVLUG] Are there any oracle gurus on this list?

[Michael Proctor-Smith]

On 8/30/05, Emerson, Tom <Tom.Emerson at wbconsultant.com> wrote:
> 
> How easy (or difficult) is it to (a) install Oracle on linux, and (b) 
> actually USE oracle?
> 

I am not a Oracle expert, but in general Oracle seems to be hard on perpose 
so that you have to hire a dba to manage it for you.
The thing is it is SQL so most SQL should work with Oracle the differance 
seems to be in management.

 select () from lefttable left outer join righttable on key
> vs
> select () from lefttable, righttable where lefttable.key = righttable.key(+)



The first one is general SQL right? 

 -- some time ago [couple of years by now] I got a promotional CD of "linux 
> is hot, oracle on linux is cool" or some such -- part of their "unbreakable" 
> campaign I believe. Is that likely to be a "current enough" version to be of 
> benefit, or should I burn up the DSL line and pull a few more .iso's?


I would think that Oracle is pretty much Oracle when it comes from the user 
persective.

-- I read through some of their vendor-specific installation pages; seems I 
> *may* need to [or would certainly benefit from] upgrade SuSE to 9.3 at the 
> very least. (something about direct access I/O being better supported and/or 
> flaky in earlier versions...) which leads me to:
> 
> -- HOW should I install it? The system I will likely be putting this on 
> uses lvm, and I generally format partitions using reiser -- I saw that 
> Oracle likes to use "raw" partitions as they have their own drivers (which 
> work with the aforementioned direct access I/O routines) to "manage" the 
> internal structure of the database. Would there be a conflict here or not? 
> what about RAID (md) devices? what advantages or disadvantages are there to 
> letting the OS manage the storage (i.e., keep the database as a series of 
> files in a directory rather than it's own entire partition)


I think you will be fine using OS filesystem, as long as you are not going 
for ultimate performance. The thing with Oracle is that there are several 
parts to the database stored in possably differant places.

-- HOW would I back it up? I presume there are utilities, but now this is 
> getting into the "using" side of the question, so:


No idea about backup, but ingeneral you have to take a database offline to 
back it up. Or take its replicated slave offline and back that up then let 
it resync. Just remember that with Oracle it costs so much money that paying 
an expert to manage is not a big percentage of the cost.

USING Oracle:
> 
> -- aside from the fact you have nearly infinite "fine-grain-control" over 
> how oracle deals with the underlying storage, just how difficult is it to 
> define a "database", or is that even the right term? (I hear the word 
> "schema" a lot...)


Well you do it like any other SQL databse.
create database DataBaseNameGoesHere;
use DataBaseNameGoesHere;
create table TableName1(ColumnName1Here int, ColumnsName2Here varchar(25) 
not null default '');
schema just is a fancy word for the structure of the database.

Note: in the world of the HP3000, a "database" is a related collection of 
> "datasets", which are essentially identical to "tables" in SQL terms, but 
> with somewhat limited key and index specifications. "stored procedures", 
> triggers, and similar items simply do not exist /in the database proper/ -- 
> all that is managed by the applications using the database. Some limited 
> "referential integrity" is enforced -- you can define a "master" set which 
> will essentially have a unique "primary key", and can then relate that to 
> one or more "detail" sets. These sets are restricted only in the fact that 
> for any "key" value, a corresponding master record MUST exist, however 
> multiple records can share the same "key". Also, while a detail set can have 
> multiple "keys" [up to 16 I believe), there is no direct provision for a 
> concatenated key -- if you have one key for "order number", a second key for 
> "line number", and want a concatenated key of order+line number, you have to 
> (as the programmer) physically populate a third field with the concatenated 
> value -- and nothing but your own programming skill stops you from putting 
> different "data" in the so-called concatenated key.
> 
> [wow -- that went longer than expected...]
> 
> -- backing up: I'm "used to" a couple of methods of backing up a database 
> [on the HP, naturally...] either storing the underlying files (requires 
> exclusive access to the files, which is not a problem for this application 
> as it runs "business hours", not 24x7) or by "dumping" the data in some 
> reloadable format [i.e., as a series of "insert" statements in a text 
> file, though binary elements might be problematic...] A third way, which 
> I've not used much, is to maintain some form of "transaction log" -- usually 
> a chronological list of every insert, update, and delete statement. This can 
> be replayed as needed to essentially re-create the database, but depending 
> on how your application works and how volitale the data is, you may end up 
> taking longer to "replay" the transactions than it would to restore a 
> "snapshot"


Theose are still all valid ways of backing up data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.sgvlug.net/pipermail/sgvlug/attachments/20050830/ae0d1f77/attachment-0001.html