On 8/30/05, <b class="gmail_sendername">Emerson, Tom</b> <<a href="mailto:Tom.Emerson@wbconsultant.com">Tom.Emerson@wbconsultant.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
How easy (or difficult) is it to (a) install Oracle on linux, and (b) actually USE oracle?<br>
</blockquote><div><br>
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.<br>
The thing is it is SQL so most SQL should work with Oracle the differance seems to be in management.<br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> select () from lefttable left outer join righttable on key<br>
vs<br> select () from lefttable, righttable where lefttable.key = righttable.key (+)</blockquote><div><br>
<br>
The first one is general SQL right? <br>
</div><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-- 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?</blockquote><div><br>
I would think that Oracle is pretty much Oracle when it comes from the user persective.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --
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:<br><br> -- 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)</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-- HOW would I back it up? I presume there are utilities,
but now this is getting into the "using" side of the question, so:</blockquote><div><br>
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.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">USING Oracle:<br><br> --
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...)</blockquote><div><br>
Well you do it like any other SQL databse.<br>
create database DataBaseNameGoesHere;<br>
use DataBaseNameGoesHere;<br>
create table TableName1(ColumnName1Here int, ColumnsName2Here varchar(25) not null default '');<br>
schema just is a fancy word for the structure of the database.<br>
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.<br><br>[wow -- that went longer than expected...]<br><br> --
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"</blockquote><div><br>
Theose are still all valid ways of backing up data.<br>
</div><br></div>