date:20020605

Re: Jr.DBA, Mid level DBA, Sr.DBA

2002-06-05 Thread Bunyamin Karadeniz


That is my opinion ..

Jr. learns the methods.
Mid. knows the methods and predicts the results of some.
Sr. had used all of them and knows the results.
Guru seems to know the database internal code.

Bunyamin Karadeniz



- Original Message -
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Wednesday, June 05, 2002 11:50 PM


> The Jr knows the passwords and where to find the databases. (Data)
> The Mid knows the answers to the exam questions. (Information)
> The Sr knows how the systems integrate and where to find things out.
> (Knowledge)
> The Guru knows the engine internals but also knows to test for 'features'.
> (Wisdom)
>
> -Original Message-
> Sent: Friday, May 31, 2002 1:11 PM
> To: Multiple recipients of list ORACLE-L
>
>
> The jr thinks that she knows.
> The mid knows that she knows.
> The sr knows that she knows not.
>
> Awareness of ignorance is the mark of true knowledge.
>
> I like cake.
>
> jack silvey
>
>
> --- "Fink, Dan" <[EMAIL PROTECTED]> wrote:
> > I agree, the Jr. DBA must focus on learning.
> > Mid DBA...is still learning. Many Mid still view
> > tuning/troubleshooting as
> > an art (with a little magic thrown in)
> > Sr. DBA...is still learning. Realizes that database
> > management is a science,
> > requiring research, expirementation and a very
> > healthy dose of skepticism.
> >
> > The best Sr. DBAs that I know are the first ones to
> > say 'I don't know'. That
> > is the only true path to learning. No one can know
> > everything. Often times
> > the Jr. DBA will be a great source of knowledge
> > since they don't know what
> > NOT to ask.
> >
> > Reaction to reading Books/Documentation
> > Junior - I did not know that
> > Mid - I know that
> > Senior - Perhaps...let's prove it
> >
> > When a developer/user asks for a change to the
> > database
> > Junior - I'll look it up and change it
> > Mid - I have a script to do that, I'll let you know
> > when I am done
> > Senior - Why are you needing this change? Did you
> > realize that x will cause
> > y? Let's figure out the best way to accomplish the
> > result.
> >
> > When faced with an undocumented condition/unknown
> > error
> > Junior - Log a TAR, get frustrated with 'We need a
> > trace file. We need more
> > information. '. Calls more
> > senior help.
> > Mid - Remembers a passage in a book, tries out the
> > command. Fixes the
> > symptom.
> > Senior - Knows that x can cause y, if z is present.
> > Tracks condition from
> > symptom through to actual problem.
> >
> > Attends sessions at IOUG
> > Junior - Assumes that all speakers know exactly what
> > they are talking about
> > and all vendor tools work as advertised.
> > Mid - Listens to and believes Tim, Cary, Craig,
> > Rich, Rachel, Gaja and all
> > other High Holy Oracle Gurus preach
> > Senior - Listens to, questions and tests (on non
> > production systems) what
> > Tim, Cary, Craig, Rich, Rachel, Gaja and all other
> > High Holy Oracle Gurus
> > preach
> >
> > Knowledge level
> > Junior - Has no clue what they know and don't know
> > Mid - Knows what they know
> > Senior - Knows what they don't know
> >
> > Every Senior DBA is a mix of Jr. and Mid. They may
> > know a great deal about
> > one subsystem of Oracle, but lack knowledge in
> > another area.
> >
> >
> > Daniel W. Fink
> > Sr. Oracle DBA
> > MICROMEDEX
> > 303.486.6456
> >
> >
> > -Original Message-
> > Sent: Friday, May 31, 2002 2:43 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Junior DBA's job is a learning.
> > Mid DBA's job is a science.
> > Sr. DBA's job is the Art.
> >
> > Srs feel database, users, developers and everything
> > else.
> > They feel what, where, how, when and why should by
> > done.
> > Their intuition is of high degree.
> > ... and everybody is sure - the Sr DBA knows
> > everything. (so one of the
> > priority of Sr DBA is to make this impression)
> >
> > --
> > Alexandre
> >
> > --
> > Please see the official ORACLE-L FAQ:
> > http://www.orafaq.com
> > --
> > Author: Alexandre Gorbatchev
> >   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).
> > i
> > --
> > Please see the official ORACLE-L FAQ:
> > http://www.orafaq.com
> > --
> > Author: Fink, Dan
> >   INET: [EMAIL PROTECTED]
> >
> > Fat City Network Services-- (858) 538-5051  FAX:
> > (858) 538-5051
> > San Diego, California-- Public Internet
> > access / Mailing Lists
> >
> --

RE: Complex Integrity Checking

2002-06-05 Thread Iulian . ILIES

Title: RE: Complex Integrity Checking



Ok 
Richard, this seems to be what I want. 
I read 
carefully the message but I didn't find the trigger 
RHUNTLEY.SINTERVAL
How 
did you do that?
Thanks!
 
iulian
 
-Original Message-From: Richard Huntley 
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, June 05, 2002 7:44 
PMTo: Multiple recipients of list ORACLE-LSubject: RE: 
Complex Integrity Checking

  Iulian, this is what you want, NO? (except this works for date 
  fields not number fields as you've put in your latest 
  posts)...  This is done using two triggers. 
  SQL> insert into interval values('01-JAN-2002','01-MAR-2002');   
  2 1 row created. 
  SQL> insert into interval values('03-MAR-2002','26-MAR-2002');   
  2 1 row created. 
  SQL> insert into interval values('03-FEB-2002','14-MAR-2002');   
  2  insert into interval     
  * ERROR at line 1: ORA-2: 
  date overlap 03-FEB-02 14-MAR-02 ORA-06512: at 
  "RHUNTLEY.SINTERVAL", line 23 ORA-04088: error during 
  execution of trigger 'RHUNTLEY.SINTERVAL' 
  SQL> insert into interval values('01-DEC-1999','01-JAN-2002');   
  2  insert into interval     
  * ERROR at line 1: ORA-2: 
  date overlap 03-FEB-02 14-MAR-02 ORA-06512: at 
  "RHUNTLEY.SINTERVAL", line 23 ORA-04088: error during 
  execution of trigger 'RHUNTLEY.SINTERVAL' 
  SQL> insert into interval values('05-JAN-2002','01-FEB-2002');   
  2  insert into interval     
  * ERROR at line 1: ORA-2: 
  date overlap 03-FEB-02 14-MAR-02 ORA-06512: at 
  "RHUNTLEY.SINTERVAL", line 23 ORA-04088: error during 
  execution of trigger 'RHUNTLEY.SINTERVAL'   
  -Original Message- From: 
  [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
  Sent: Wednesday, June 05, 2002 10:39 AM To: Multiple recipients of list ORACLE-L Subject: RE: Complex Integrity Checking 
  -Original Message- Sent: 
  Wednesday, June 05, 2002 4:53 PM To: Multiple 
  recipients of list ORACLE-L 
  ** 
  This email has been tested for viruses by F-Secure 
  Antivirus administered by IT Network 
  Department. ** 
  
   two questions: How many records do you insert into that 
  table before a commit ? 
  Is the whole issue simply mutating table error when running 
  some business logic in an insert/update trigger for 
  the intervals table? 
  Regards, 
  Waleed 
  I'm sorry bu I can't answer to your questions because I don't 
  see the point. 
  Here's a test table: CREATE TABLE 
  intervals (     start_time NUMBER NOT NULL, 
      end_time NUMBER 
  NOT NULL ) 
  Here are some statemens: 
  INSERT INTO intervals (START_TIME,END_TIME) VALUES (3,5) / INSERT INTO 
  intervals (START_TIME,END_TIME) VALUES (2,3) / 
  INSERT INTO intervals (START_TIME,END_TIME) VALUES (7,8) 
  What I want is that the integrity rule (no overlapped 
  intervals) be operational even if i insert a new 
  record or more or update one or more. Think of it the 
  same way an unique key works. This is a simplified 
  table for example purpose. In fact my application is a resource scheduler, so I want a resource not to be assigned for more 
  than 1 client at the same time. Here the start_time and end_time are of number type just for testing, 
  but of course it'll be of date type. 
  I'm starting to think that what I want, can be done in a 
  simple, clean manner but using complex workarounds, 
  isn't it? Thanks! 
  iulian 
  -Original Message- To: 
  Multiple recipients of list ORACLE-L Sent: 6/5/02 4:33 
  AM 
  First of all I want to thank you all for your answers. 
  Let's take'em one by one: 
   
   Attn: Mercadante, Thomas F 
  [[EMAIL PROTECTED]] - I cannont use "instead 
  of" trigger because of this error: 
  ORA-25002: cannot create INSTEAD OF triggers on tables 
  Cause: Only BEFORE or AFTER triggers can be created on a 
  table. Action: Change the trigger type to BEFORE or 
  AFTER. 
  I have an Oracle database version 9.0.1.1.1 
   
   Attn: Stephane Faroult 
  [[EMAIL PROTECTED]] - for insert your approach works 
  (although I have to change a bit the select 
  in exists condirion) but what about the update statements. 
  - moreover i think this will not keep my integrity 
  rule consistent, if someone try to simply use typical 
  insert&update statements. 
   
   Attn: Khedr, Waleed 
  [[EMAIL PROTECTED]] - Can you give me an example 
  for your unique function based index, I mean 
  how can you assign an unique number for various intervals. 
  - anyway if this can be done I assume that would be a 
  very nice, clean solution 
   
   Attn: Richard Huntle

Maintaining Simulated Standby DB on 7.1.6.0

2002-06-05 Thread Ross Collado


Hi,

I've got an old (test db) Oracle 7.1.6.0 db on HP-Ux. I've created a
"simulated" standby db on another server of same spec. I say simulated
because there is no real standby mechanism in this old version.  Anyway, the
standby database is mounted and on regular intervals (via cron), is doing
recover database using backup controlfile until cancel.  So far this
arrangement is working perfectly. Now this is where it starts to become
hairy. The tablespace USERS has 2 datafiles. USERS needs to be resized and
the datafiles relocated.

What I've done so far are the ff:
1. exported everything in USERS
2. dropped USERS t/space on primary then recreate with new datafile size and
location.
3. recreated all tables in it.
4. imported all data back.

While this is happening, the primary is happily generating all these archive
logs which in turn are also being applied to the standby. The standby's
alert.log indicates it has applied all logs and reports no errors.  I then
tried to open the standby db using alter databse open resetlogs.  I didn't
expect this to work and sure enough I got the error:
SQLDBA> alter database open resetlogs;
ORA-01177: data file does not match dictionary - probably old incarnation
ORA-01110: data file 5: '/u9/db/DEV/users01.dbf'

users01.dbf is the old filename.

My questions are:
1. Why is there no error reported? I was expecting it to complain about an
unknown datafile.
2. If the standby is applying the logs where is it applying the transactions
to?
3. Since there is no '... offline drop' in this version, is there any other
way to get around this apart from completely recreating the standby?

Any input much appreciated. 

Rgds,
Ross

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Ross Collado
  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).

RE: Complex Integrity Checking

2002-06-05 Thread Khedr, Waleed

Title: RE: Complex Integrity Checking

The problem with
this solution is the Autonomous Transactions will not
be able to see any changes done within the current transaction only the
committed one. So no way to enforce business logic during the context of the
transaction.
This is why I asked before how
frequently commit happens.
Regards,
Waleed

-Original Message-From: Aponte, Tony
[mailto:[EMAIL PROTECTED]]Sent: Wednesday, June 05, 2002 6:33
PMTo: Multiple recipients of list ORACLE-LSubject: RE:
Complex Integrity Checking
With the introduction of Autonomous Transactions this is no
longer entirely true. If you call an autonomous transaction procedure,
it is executed in a separate transaction context. This gives you the
ability to probe the mutating table without inducing the error. A good
explanation can be found in Tom Kyte's Export One-on-one Oracle book in the
chapter on Autonomous Transactions.
HTH Tony Aponte
-Original Message- From:
Jamadagni, Rajendra [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, June 05, 2002 9:24 AM To: Multiple recipients of list ORACLE-L Subject: RE: Complex Integrity Checking
no matter what you do, if you access table A inside a trigger
on table A, oracle will give you mutating table error.
What you could (and I really mean you have to consider
your business logic here) is go ahead and insert the rows with a temp flag. As soon as you commit, fire up a procedure that
will do the scan on the table and delete appropriate
rows which have the temp status.
BTW how big is this table? What is the frequency of inserts
and updates?
Raj __ Rajendra Jamadagni
MIS, ESPN Inc. Rajendra dot Jamadagni at ESPN dot com Any
opinion expressed here is personal and doesn't reflect that of ESPN
Inc.
QOTD: Any clod can have facts, but having an opinion is an
art!

85 matches

Mail list logo