If we create a directory using create or replace directory and another directory exists which has the same path will the original directory get deleted?
Nope, you can have many oracle directories which point to the same place. Creating or removing an oracle directory does nothing at the OS level, the OS directory doesn't have to exist in order to create the oracle directory.
Related
So, I'm currently working on a spring-boot application that should import a database dump based on a config-file. For that I build myself an impdp-command as a String, which then gets executed in the command line. Since this application is based around directories and should work by just moving the dump-file into a specific directory, I would like to use the current directory my application is running in. As far as I know the parameter "DIRECTORY" only accepts oracle directories (created in sql with create directory 'name' as 'C:\path\'). Is there any way I could use the directory from which the command gets executed or just a windows path?
Disclaimer: I'm not a DBA, just a DBA-wannabe.
I have created a Directory in our Production Environment:
CREATE DIRECTORY PAY_FOLDER AS '/u01/EBSPROD/apps/apps_st/appl/cust/12.0.0/per/1.0';
GRANT READ ON DIRECTORY PAY_FOLDER TO PUBLIC;
However, when our Production Environment is cloned to a Non-Prod Instance (for example EBSDEV),
the instance name doesn't change and still stays as EBSPROD.
I would want it to be:
/u01/EBSDEV/apps/apps_st/appl/cust/12.0.0/per/1.0 when cloned over to DEV
/u01/EBSDEV/apps/apps_st/appl/cust/12.0.0/per/1.0 when cloned over to TEST
/u01/EBSUAT/apps/apps_st/appl/cust/12.0.0/per/1.0 when cloned over to UAT
Do I need a separate script to re-create these directories when i clone an instance?
Yes. The directory name is just a string; it does not know that you have embedded the instance name.
Use
CREATE OR REPLACE DIRECTORY directory_name AS'path_name';
instead of a DROP-Statement followed by a CREATE-Statement. This will keep all the grants on this directory.
It should not be too hard to create a single parameterized script that would take the DB Name or Instance name (whichever is appropriate) and build the correct directory name.
I have lost my database on the server because the computer has been formatted on drive C. But the oracle folder was located on Drive E, like oradata, etc. Can I restore oracle database like before?
Well, first you need to install the oracle server with the version which was there before formatting.
Follow these steps:
Install the same Oracle database version with the starter database.
Copy all control files, datafiles to oradata directory
Copy init.ora filr to ADMIN folder
Revise the init.ora file for the changed control file, archive and dump locations. (keep instance, SID, and global db name the same)
Create the instance by running oradim with the pfile(init.ora) location
Connect to DB using internal and mount it.
Check existing data and logfile locations by typing:
SELECT name FROM V$DATAFILE;
SELECT member FROM V$LOGFILE;
Now change the file locations that come up above by using:
ALTER DATABASE RENAME FILE <old file loc list> to <new file loc list>;
After renaming them open the database by alter database open.
And you should be set.
Reference
I deleted my .../hadoop/tmp directory ... will I have to compile hadoop again ?
How do I fix it, I thought it just I made it again but I do not know what other files and folders it contained
Is this a directory in local file system or HDFS? In either case, you can issue mkdir to create this directory and assign appropriate permissions
I've a windows service that updates our product. It copies the product files into a temp directory, usually "C:\Windows\Temp", patches the binaries, and then uses MoveFileEx to copy the files back to the install directory on a reboot, usually "C:\Program Files\Product". The files in the install directory are inheriting their security attributes from the parent folder. After the copy, patch, and reboot, the files in the install directory are missing some ACLs. Specifically the files don't have the ACL for the Users group anymore so users can no longer run the program after the reboot.
Can anyone explain whats going on here? It seems that copying from the install directory to the temp directory, the files inherit the ACLs of the temp directory. On the MoveFileEx/Reboot, though, the files only inherit the ACLs that both the install and temp directories have in common.
In Windows if you copy a file the file takes on the ACLs of the destination directory. If you move a file the ACL goes with it overriding any it might inherit from that directory. I'm not sure how MoveFileEx might operate differently on a file.
The temp directory is usually located under the user profile (both %TMP% and %TEMP% usually point here) so copying files here will have permissions for that user. Moving those files to the program files directory will take only that users rights with them and therefore only runnable by the installing user.
One potential workaround is to patch copies of the files with-in the same directory but with different names. After the reboot, the patched versions could be swapped in. Alternatively, do a reboot first and then patch them in-place, and just back them up to the temp directory in the event a manual rollback is required.
If you really want to move them to a different location, creating a temp folder in the same place as the files to be patched would help the permissions stay the same assuming the directory is using inherited permissions.