RMAN won't write to mapped drive under Windows
Domenic G.
r/w permissions ...
run
{
allocate channel ch1 device type disk format 'x:\orabkup\b_%U';
backup database plus archivelog delete input;
}
Why does RMAN report an OS error? -- to the OS x: looks like it's
local. Anybody know? Without using tape, I want to get the backups
onto another machine with a mirrored drive.
Domenic.
Paul Drake
Domenic,
You did not report oracle version info here. That is usually highly
significant.
Please post that and others might respond in a helpful fashion.
When you are logged into a desktop (console) as your user account, be
it a local or domain account, your console session is running under
your credentials.
If you accept the defaults, and run the "OracleService%ORACLE_SID%" as
LocalSystem, that account has no rights off of the local machine.
Can you imagine how widespread the damage would be, if a single
(win32) machine that was compromised had admin rights to other win32
boxen as LocalSystem?
Sealed for your protection.
In a domain environment, if a domain controller is compromised, the
offending code (e.g. worm, Nimda comes to mind) can traverse the
admin$ shares of every machine belonging to the domain, infecting
every box in that domain. Fortunately, things are slightly more secure
now than then, but mostly due to the compromises that occurred in the
past, and people not wanting to lose the mail servers, domain
controllers, etc. EVER AGAIN.
So, I would recommend that you examine what security token the oracle
instance (oracle.exe) and rman process are running as. If they are
running as a domain account that belongs to a local ORA_DBA group
(Pete Finnegan, feel free to shoot this one) that has access rights on
the network, chances are, you won't receive the error. I've run
standby code over NetBIOS using batch jobs running as network
(domain) accounts that moves files between servers without error.
Back before Nimda, we even had a domain ORA_DBA group that was godlike
over every oracle database in the domain, in which the domain group
ORA_DBA had been added to the local ORA_DBA group. Mighty convenient.
Very bad idea.
You *can* open permissions sufficiently to get this to work.
The question is - do you want to?
Another question would be, what are the implications of opening shares
that wide open. Do you care if others have access to those database
backups?
Its not difficult to create a password file and init file to open a
backup set as a clone.
Proposal:
Why not stage your RMAN backups to local disk - and -
configure access permissions to the staging area for network (domain)
backup service accounts to be able to read/list/exec the files
(or the compressed files, if you have cpu cycles to burn)
and let your local jobs run locally?
OR -
use a domain account to perform the file copy operation from local
staging to network storage.
In case you've missed the point of the above text, here it is real
simple:
1. that "local" mapped drive is not local.
2. localsystem has no privs on the network.
Paul
Domenic G.
Thank you very much for the detailed and informative response. I'm
using RMAN with 9.2.0.4. Normally I use RMAN to dump to disk and have
the network backup come around and pick up the files later on.
Getting RMAN to dump directly to tape looks like a pain. I changed
all the Oracle Services to log on as Domain Admin but this doesn't
work ...
run {
backup
format '\\servername\sharename$\foldername\%U'
database plus archivelog delete input;
}
With RMAN 9i, I know the RUN {} is not needed in this case, but it
seems to me RMAN just can't write to a remote machine under Windows
like this. I think I'm going to log a TAR with Oracle to see if it is
possible.
Thanks again,
Domenic.
drak...@yahoo.com (Paul Drake) wrote in message news:<1ac7c7b3.03092...@posting.google.com>...
Paul Drake
>
> Thank you very much for the detailed and informative response. I'm
> using RMAN with 9.2.0.4. Normally I use RMAN to dump to disk and have
> the network backup come around and pick up the files later on.
> Getting RMAN to dump directly to tape looks like a pain. I changed
> all the Oracle Services to log on as Domain Admin but this doesn't
> work ...
>
> run {
> backup
> format '\\servername\sharename$\foldername\%U'
> database plus archivelog delete input;
> }
>
> With RMAN 9i, I know the RUN {} is not needed in this case, but it
> seems to me RMAN just can't write to a remote machine under Windows
> like this. I think I'm going to log a TAR with Oracle to see if it is
> possible.
>
> Thanks again,
>
> Domenic.
Domenic,
> run as domain admin ...
I certainly wasn't advocating that response.
What I meant to get across it the difference between the scope of
local and domain accounts, and of the localsystem account.
It is higly likely that others have already encountered and solved
this problem, maybe in comp.databases.oracle.server, maybe in Metalink
Forums, maybe via TARs.
Since you have a metalink account, I'd search there.
Sorry that I can't help, but I'm having fun (not really) with
execution paths changing greatly between 8.1.7 and 9.2, and it ain't
in testing ...
Paul
Domenic G.
Pull out the stored outlines from 8i!! That's the only way you're
going to solve that mess without injecting hints (if you can). CBO
drives me nuts when it does this. If all else fails, switch to RULE,
FIRST_ROWS_x and say a quiet prayer.
Domenic.
drak...@yahoo.com (Paul Drake) wrote in message news:<1ac7c7b3.03092...@posting.google.com>...
Daniel Morgan
I'd suggest ignoring this advice and fixing the problem. Unless your
PL/SQL and object types are vanilla Oracle 7.3
the RBO will not be used and everything will be a full table scan.
Dominic is just on a tear about the CBO and takes every chance to
express his displeasure with the fact that Oracle
has declared it deceased.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damo...@x.washington.edu
(replace 'x' with a 'u' to reply)
Teatime Results
https://teatimeresultsz.com/