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

[Max Clark]

 > 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.

Why would you answer a question that you have "no idea about"? There is 
not a _real_ database on the planet that you have to take offline to backup.

Michael Proctor-Smith wrote:
> On 8/30/05, *Emerson, Tom* <Tom.Emerson at wbconsultant.com 
> <mailto: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.
>  
>