Paul,
I know what. . . to prevent whining in the future, suggest creating a hidden
file for the rollback tablespace on /u004 and a soft link from the proper
location. No wait, don't do that, they might go for it. ;)
Mike
-Original Message-
Sent: Friday, April 05, 2002 9:53 AM
To: Multi
No failover is involved. And I don't assume that I know the
motivation. I know the motivation because I asked. And I have
permission to ALTER TABLESPACE because I've been administering Oracle
databases since 1987.
--- Tim Gorman <[EMAIL PROTECTED]> wrote:
> Um...
>
> It depends on whether t
Um...
It depends on whether those whining staff DBAs are managing a failover
environment. If you created that datafile on a file-system in a
"non-failover" (not "failover-enabled") volume group, especially when
rollback segments are involved, then you've just ensured an un-open-able and
un-recov
I'm not disagreeing with you - that's my point in saying look inside
the database!
--- Paul Baumgartel <[EMAIL PROTECTED]> wrote:
> What happens when you run out of disk space on a mount point? It
> happened to me. I created a new datafile on another mount point, and
> then had to hear staff D
What happens when you run out of disk space on a mount point? It
happened to me. I created a new datafile on another mount point, and
then had to hear staff DBAs whining, "why is there a rollback segment
tablespace file on /u004?", as though it was a major disaster. Really,
when people get into
I had an SA teach me that one, and it's saved me from making a REALLY
stupid mistake a number of times.
As for your client's standards, I can see why they want to impose
standards and that's a good thing. But they are a bit too rigid with
it, as others have said, what happens if you run out of di
That's a great idea. Henceforth I'm going to do the same! Thanks.
--- Rachel Carmichael <[EMAIL PROTECTED]> wrote:
> and, on a Unix box, I ALWAYS do an "fuser" before deleting a file.
> Just
> in case.
>
>
> --- Jonathan Gennick <[EMAIL PROTECTED]> wrote:
> > On Tue, 02 Apr 2002 07:43:34 -0
and, on a Unix box, I ALWAYS do an "fuser" before deleting a file. Just
in case.
--- Jonathan Gennick <[EMAIL PROTECTED]> wrote:
> On Tue, 02 Apr 2002 07:43:34 -0800, you wrote:
>
> >Great point. I had recently created a DB file and forgot to put the
> ".dbf"
> >extension on it. If someone di
On Tue, 02 Apr 2002 07:43:34 -0800, you wrote:
>Great point. I had recently created a DB file and forgot to put the ".dbf"
>extension on it. If someone didn't query the DD of the DB first, they might
>have thought it was a junk/temp file (they would have to ignore the file's
>timestamp) and del
It's been a while since I've been an admin guy but let me try...
Every file, directory, etc... on a file system is represented by an inode on
the file system. Think of an inode (in a simple term) as another file or a
pointer
if you will. It contains information on that structure (rights, who owns
Could any of you please summarize all the points once the discussion is over.
Thanks,
Ashoke
-Original Message-
Sent: Tuesday, April 02, 2002 11:14 AM
To: Multiple recipients of list ORACLE-L
I agree.
I think that some people don't understand OFA's intentions. First of
all, it _is_ a
Paul Baumgartel wrote:
>
> Hi everyone.
>
> I'm currently working at a client where the OFA standard has been (as
> they put it) "taken to the next level". I disagree with their
> approach, and I'd be interested to see what list members think.
>
> The client believes that any DBA (there are ab
D] Quad/Tech International, Sussex, WI USA
> -Original Message-
> From: Paul Baumgartel [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 02, 2002 11:14 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Seeking opinions
>
>
> I agree.
>
Robert,
Tell me a little more about potential for inode corruption and how this
helps? Never heard of that one before. I stick it all in
/x/oradata/$ORACLE_SID and distinguish my files by .dbf, .ctl, .arc and
.rdo. Also are yall mostly Oracle or are you running anything else?
- Ethan
-Or
I agree.
I think that some people don't understand OFA's intentions. First of
all, it _is_ a standard, meant to provide great flexibility.
The reason mount points are to be named in a generic fashion is to
allow any type of file to reside on them. Any number of file types can
happily coexist u
My apologies, I was reading the post *REALLY* fast (on my way to my daily
deluge of
meetings) and mis-read what you said completely. Upon re-reading, I agree
100% with what you
said about standards.
Again, removing foot from mouth.
RF
Robert G. Freeman - Oracle8i OCP
Oracle DBA Technical Lead
Tom,
I am not oppositting the idea of standard. I implement OFA and other stuff,
and everywhere
I go the first I do is establish standards. The problem is even with
standard
in place one should not assume everything will be in place as is should be.
Which is the problem I see as Paul described.
Robert,
What part of what I said is "hogwash".
The part about the DBA's wanting similiar structures across all machine
types, or the part about having standards?
Huh?
Tom Mercadante
Oracle Certified Professional
-Original Message-
Sent: Tuesday, April 02, 2002 10:58 AM
To: Multiple r
This is hogwash. OFA perfectly helps to separate the datafiles from
different
database instances. We run well over 300+ Oracle databases here and the ONLY
extension we have to OFA is that I add a /data /control and /redo directory
to the file systems for just a little extra protection from possib
It sounds to me that whoever architected this approach really didn't
understand
the idea of "metadata" and the flexibility that OFA provides in terms of
tuning
(I'm not limited to specific disks because I have "customer data") and
performance.
My 2 cents...
RF
Robert G. Freeman - Oracle8i OCP
O
Richard,
In a busy shop, I would think that there is a *less* chance of a DBA making
a mistake if all databases across all platforms conformed to the same
directory standard.
Can you imagine how long it would take to diagnose and fix a problem if
every database was set up to a different standar
eted it.
Rich Jesse System/Database Administrator
[EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA
> -Original Message-
> From: Ji, Richard [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 02, 2002 9:03 AM
> To: Multiple recipients of list ORACLE-L
Hi Paul,
How's going?
What if someone on the dba group make a mistake (typo or whatever)
and put the data file in the wrong place? And other DBAs didn't
notice it and work on something. I don't like the idea people
assume things will be in the right place because the rule says so.
I'd rather t
Paul,
I live under similiar standards. They make sense here becuase, when one
looks at the big picture, they need these types of standards to help the
DBA's (there are three of them) to cope with the many many Oracle instances
across multiple platforms (NT, Sun Unix, Dec Unix).
I look at it thi
-- Paul Baumgartel <[EMAIL PROTECTED]> on 04/01/02 14:48:23 -0800
> Hi everyone.
>
> I'm currently working at a client where the OFA standard has been (as
> they put it) "taken to the next level". I disagree with their
> approach, and I'd be interested to see what list members think.
>
> T
There is no major differences in your opinions/ideas here. Just think about
it as enforcing a naming conventions.
It's nice to have but hopefully it will last when one mount point gets
filled or slow and some files need to be created/moved somewhere else
violating the defined standards.
So come w
Mama always said, "Anal is as anal does..."
--Forrest Gump
PS -- You're right. They're not.
> -Original Message-
> From: Paul Baumgartel [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, April 01, 2002 4:48 PM
> To: Multiple recipients of list ORACLE-L
Hi everyone.
I'm currently working at a client where the OFA standard has been (as
they put it) "taken to the next level". I disagree with their
approach, and I'd be interested to see what list members think.
The client believes that any DBA (there are about 16 on staff) should
be able to loc
28 matches
Mail list logo
