We have an oracle 11g installed on a linux machine. I want to duplicate the database on my local 64-bit windows machine. We have total 403 tables and a few of them have foreign key constraints. I am not a dba so I don't have the sysdba privilege. Also I cannot shutdown the remote database. Is there a quick way to do this rather than I copy the tables one by one? Thanks
Considering you do not have DBA role granted and not having access to server machine, you won't be able to do a cold backup and install in on your machine, because cold backup requires database getting shut downed.
Secondly, you can't use rman utility either.
You can use expdp utility to get database exported as files and import it to your db with impdp utility.But in order to get data exported you at least need CONNECT and RESOURCE roles granted to your user ( Assuming you already have CONNECT otherwise you won't be able to connect to db at all ) and with those roles you can only import objects you already have access to. Including objects you own.
On the other hand, if you need a full database export, then you need EXP_FULL_DATABASE granted. DBA, SYS and some other roles has this role included. So your best chance is to contact dba's asking for the role granted to your user, see how they react to that.
Related
I'm new to Oracle and I'm currently hardening a database.
It's a good idea to drop SYS and SYSTEM users? normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
From the documentation (emphasis added):
All databases include the administrative accounts SYS, SYSTEM, and DBSNMP. Administrative accounts are highly privileged accounts, and are needed only by individuals authorized to perform administrative tasks such as starting and stopping the database, managing database memory and storage, creating and managing database users, and so on. You log in to Oracle Enterprise Manager Database Express (EM Express) with SYS or SYSTEM. You assign the passwords for these accounts when you create the database with Oracle Database Configuration Assistant (DBCA). You must not delete or rename these accounts.
And:
All base (underlying) tables and views for the database data dictionary are stored in the SYS schema. These base tables and views are critical for the operation of Oracle Database.
So no, it is not a good idea, and it would destroy your database.
normally default accounts are dropped because of security reasons, I can do that on Oracle, or I will break something?
The first documentation link above also says (emphasis added again):
All databases also include internal accounts, which are automatically created so that individual Oracle Database features or components such as Oracle Application Express can have their own schemas. To protect these accounts from unauthorized access, they are initially locked and their passwords are expired. (A locked account is an account for which login is disabled.) You must not delete internal accounts, and you must not use them to log in to the database.
And it mentions sample schema accounts, which you can choose not to install in the first place, but which could be dropped if required.
The main thing is to secure all accounts, and you should limit any accounts you create to only have the minimum privileges necessary.
You can also read more about this in the database administrator's guide,
It is a very bad idea. I don't think the database will even work without them and doubt that the drop is allowed. Make sure the accounts are safe instead.
When we connect to Oracle database for the first time from SQLPlus command line tool, why do we always connect like this
"sys as sysdba"
Can some one tell me the significance of this?
Why do not we do this in MYSQL?
I am new to Oracle, and this question might sound silly. I am learning using Oracle 11g XE.
SYS and SYSTEM are administrative users, they kind of "own" the database. Data dictionary is stored in SYS schema so - if you screw it up, you'll most probably destroy the database. Therefore, never mess up with it - use it only for necessary administrative tasks. Never touch any SYS owned tables (thinking "if I change this I'll make that happen). Even better, create your own user and grant it DBA privilege - it'll be able to do mostly everything you'd ever want.
SYSDBA is a privilege which is automatically granted to user SYS; it lets it perform high-level administrative tasks (such as backup and recovery or upgrade the database). SYSTEM doesn't have it; that's why you don't specify as sysdba when connecting as SYSTEM.
Furthermore, SYSDBA privilege lets you to connect to database instance although database isn't open yet - and lets you start it up.
Saying that you "always connect as sys as sysdba" - well, you don't have to do that "always". There are other predefined users (such as Scott or HR (Human Resources)) you can use. Default username/password combinations are "scott/tiger" and "hr/hr". Though, they are most probably locked so you can't establish connection. That's why you connect as SYS, unlock those accounts (or create new one(s), depending on what you want to do), and then connect as some other user.
More info here:
SYS and SYSTEM users
SYSDBA and SYSOPER system privileges
Why you don't have that in MySQL? Probably because MySQL isn't Oracle.
Finally, as you're new with Oracle, I'd suggest you to visit & bookmark this page: Oracle Database 10gR2 documentation. Yes, it is kind of "old" and you don't use that version, but it is the last one that separated "Getting Started" and "Most popular" books which makes it easy to find and read. I'd suggest you to read:
Concepts, to learn what Oracle is and how it works
Then, depending on what you'd want to do/be (developer or DBA), pick e.g.
2 day DBA
Administrator's guide
or
SQL reference
PL/SQL user's guide and reference
Application developer's guide - fundamentals
Certainly, you can find these books for database version you do use (11g), it is here: Oracle database online documentation 11g Release 2 (11.2) but - as I said - it is not as nicely presented as 10g.
Good luck with Oracle, enjoy!
I'm just getting started with Oracle data export and import and things worked perfectly fine the first time around. But then I came back next day repeated the exact same steps on the same systems, but get ORA-01435: user does not exist error.
System Specs for all machines:
-OS: Windows 2012 R2 x64
-Oracle Server: Oracle 11G Express x64
Objective:
I'm exporting data from Oracle server 1 and importing to Oracle server 2.
Procedure:
Export data dump is successful from Oracle server 1.
but when importing the data dump on Oracle server 2, I follow this procedure:
-Stop IIS service
net stop WAS
Create Schema/user account and Grant privileges before import
net stop WAS
sqlplus / as sysdba;
CREATE user PIE1 identified by PASS1;
GRANT ALL PRIVILEGES TO PIE1;
GRANT IMP_FULL_DATABASE TO PIE1;
According to oracle, all goes well, but look at the first image bellow. In DBeaver, I can see that only the User account PIE1 has been created, but NO schema.
Oracle issue 1. User account created, but not the Schema
Question 1: According to Oracle, the command "Create User" IS supposed to also create an associated Schema. Anyone have an idea why this is no longer working for me? It worked once the night before.
I then continue the import procedure as follows:
imp PIE1/PASS1#xe file=c:\Backups\AVUSER2_6_7.dmp log=c:\Backups\import.log fromuser=AVUSER2_6_7 touser=PIE1;
But get the following error:
Oracle claims the User doesn't exist even though it does
Oracle claims the User doesn't exist even though it does. I repeated the entire procedure and even created an identical import/export user account and credentials, and this error still comes up.
Question 2: Any idea why Oracle "Can't find" a user account that's clearly in the database?
Additional Info:
Checked that my windows account is in admin group
Checked that my windows account is in ORA_DBA group
Opened all CMD prompt as Admin
As you implied, users and schemas as the same in Oracle, you can't have a user without a schema. No idea about DBeaver, but as there are other users that aren't listed under 'schemas' (according to your second image - ANONYMOUS, DIP, ...) that seems to be unrelated.
(Purely a guess, but perhaps the user you're connect as in DBeaver just doesn't have visibility of any objects owned by those users - maybe it only lists users it can see in all_objects, say. Pure speculation, but you could investigate that by looking at the data dictionary while connect through SQL*Plus as the same user. According to this old forum post, there is an option to hide empty schemas...)
The import is connecting successfully as PIE1 - you'd get a different error, ORA-01017, if it wasn't and you wouldn't see the 'Connected to...' banner or anything after that.
Your import command has a trailing semicolon that should not be there. The "importing ... objects into" message shows that it's trying to import into the PIE1; user and not the one you actually created, PIE1. Remove that semicolon and try again.
Incidentally, you can probably also remove the #xe TNS alias and stick to a local connection, assuming the environment is configured as it was whenyou ran SQL*Plus. You should also consider using datapump expdp/impdp rather than the legacy exp/imp.
I want to know what is the difference between the following two statements in oracle:
GRANT DBA TO Jack
GRANT ALL PRIVILEGES TO Jack
I advise you not to try providing dba and NEVER provide ALL PRIVILEDGES to any user, because such thing should be done only by experienced developers.
Usually there is only ONE user who is provided DBA role.
As per oracle documentation:
When oracle database is installed, there are two admin roles created:
1. SYS 2. SYSTEM
An SYS role can access internal data dictionary tables of oracle database.
All of the base tables and views for the database data dictionary are stored in the schema SYS. These base tables and views are critical for the operation of Oracle Database. To maintain the integrity of the data dictionary, tables in the SYS schema are manipulated only by the database.
If you flirted with any internal sys tables, you may face license cancellation
The SYSTEM username is used to create additional tables and views that display administrative information, and internal tables and views used by various Oracle Database options and tools. Never use the SYSTEM schema to store tables of interest to non-administrative users.
The DBA role does not include the SYSDBA or SYSOPER system privileges. These are special administrative privileges that allow an administrator to perform basic database administration tasks, such as creating the database and instance startup and shutdown.
Here GRANT ALL PRIVILEGES are provided to user on particular object, even system object, and this does not includes sys and system privilege, you can do any action on such object, this is why you should avoid using ALL PRIVILEGES.
What are the differences between the Oracle SYS and SYSTEM built in accounts?
Edit: Apart from 3 letters!
SYS owns the oracle data dictionary. Every object in the database (tables, views, packages, procedures, etc. ) all have a single owner. For the database dictionary, and a whole lot of special tables (performance views and the like) are all owned by the SYS user.
The SYSTEM user is supposed to be the master DBA user, with access to all of these object. This reflects an early, and long time, Oracle security design philosophy. You build the application using one user, then create a second with access (select, update, delete) but not drop privileges. This gives you a "super-user" access to your schema without being able to destroy it accidentally. Over the years, thing have been added to the SYSTEM account that may have needed to be in the SYS account. But very few people want to give out access to their SYS account if they don't have to.
SYS can connect AS SYSDBA, SYSTEM cannot.
SYSDBA privilege is required to perform certain administrative tasks, like CREATE DATABASEand DROP DATABASE, and query any tables despite GRANT'ed permissions on them.
In fact, whenever you connect as SYSDBA, you become a SYS.