I couldn't find a declarative way to store typical privs like SELECT, INSERT, UPDATE in table definition (in Relational Model) of Oracle SQL Developer Data Modeler 19.2. I can places SQL GRANT into Table Properties -> Scripts -> After Create, but prefer more suitable way.
You don't do it in the Relational Model, you do it in a physical model - to a specific kind of database, in this case, a 12c Release 2 database.
It's at the physical level that you start to worry about things like storage properties, encryption, compression, partitions, and security (grants).
Related
Within enterprise manager 12c, when I go to Targets -> Databases, I see all my databases, but I don't quite understand how they arrive at this list. When I do a SQLplus query for this same information, I get a larger number (the same as the number of database instances when I look at "All Targets").
How can I restrict my SQLplus query so that I'm getting the same list of databases? I'm querying sysman tables like
mgmt$targets
mgmt$database_properties
and restricting by target_type.
We are writing some interfacing routines in PL/SQL to transfer data between several oracle database by using another oracle database as host. (ie hr -> host -> finance)
the transfers are happening over db_links
essentially
insert into schema.tablname#dblink1 select * from schema.tablename#dblink2;
(its more complicated then that with multiple tables and transformations etc.. but that's the general idea)
the discussion we have been having here is which of the following should do
reference "schema.tablename#dblink" everywhere in out code
create synonyms (public or private) "create synonym tablename for schema.tablename#dblink"
create views on the object " create view tablename as select * from schema.tablename#dblink"
are there any other options?
are any inherently better then the others?
NB:the dblink names are standardised throughout each level dev/test/prod
so that dblink 'server1' goes to the dev server on the dev host and the test server on test host etc..
none of the table names should ever exist on multiple servers
Location transparency is easiest setup by creating synonyms for your remote objects. That is easier to maintain than having the remote addresses in every SQL. How would you make a quick test for something in an other remote database? Just re creating the involved database links is enough to accomplish that.
An other option could be to create snapshots are materialized views from the remote tables in the local database but that also requires a database link. It would have a good performance at the cost of extra space.
I installed Oracle on my system, so now orcl is the SID, which is the unique identifier of my database instance.
Now starter db was created as part of the installation. I created 2 users user1 and user2 using the system account.
Using SQL developer I am accessing the users, this shows me 2 different connections with all the database objects like tables, stored procedures views etc.
so
When using these 2 users, am I accessing the same database? I am giving all the ddl commands by logging into the user1 or user 2, does all this data goes into the same .dbf file?
The database instance can be connected to only one database, then does this essentially mean that everytime I create a new database, to make a database instance to point to that, I need to do a configuration change?
In my experience with Oracle, the typical unit of division is a schema. Schemas in Oracle are used more like you would use databases in SQL Server or PostgreSQL. They represent both users and a logical separation of objects. Physical separation would usually be done using tablespaces. Tablespaces are a group of physical files where data is stored. Schemas can share or use different tablespaces. Having one tablespace per schema is uncommon; they usually share a few tablespaces or often even just one.
With that in mind, to answer your questions more directly,
1) Like in any other database, you can specify the schema the object belongs to:
CREATE TABLE MY_SCHEMA.TABLE_X ( X NUMBER )
If the schemas on two CREATE statements are different, then it will create different objects. What's different in Oracle is that the default schema changes for every user. The default schema is always the currently connected schema/user. So if you omit the schema like so:
CREATE TABLE TABLE_X ( X NUMBER )
then the implied schema is the currently connected schema/user. So if I'm logged in as MY_SCHEMA, then the above is equivalent to the first example. When connecting as two different users, then the implied schema will be different and the DDL is not equivalent between the two users. So running the same statement would create two different objects if you do not specify a schema.
The two objects may be stored in the same physical file if they are in the same tablespace. (They are most likely in the USERS tablespace if you did not create one explicitly and did not specify a different default tablespace when creating the schemas.) Regardless, they are still two completely separate objects.
If you specify the schema explicitly like in the first example, then the DDL is equivalent regardless of who executes it (although permissions may prevent some users from executing it). So it would result in creating the object once, and attempting to create it a second time would result in an error unless you're using CREATE OR REPLACE or something similar.
2) I don't know the answer to this question, but as I said, in Oracle, the basic unit of separation is usually the schema, not a database. I believe the question you're asking is a large part of the reason why the schemas are used in the way they are. Having multiple actual databases on the same machine/instance is far more difficult in Oracle than in other databases (if not impossible), so it's much simpler to have a single database with many schemas.
This is known to us that all DML statement has been supported by Oracle Regular Table but not the same for External Table? I tried below :
SQL> INSERT INTO xtern_empl_rpt VALUES ('70','Rakshit','Nantu','4587966214','na
tu.rakshit#ge.com','55');
INSERT INTO xtern_empl_rpt VALUES ('70','Rakshit','Nantu','4587966214','natu.ra
kshit#ge.com','55')
*
ERROR at line 1:
ORA-30657: operation not supported on external organized table
SQL> update xtern_empl_rpt set FIRST_NAME='Arup' where SSN='896743856';
update xtern_empl_rpt set FIRST_NAME='Arup' where SSN='896743856'
*
ERROR at line 1:
ORA-30657: operation not supported on external organized table
SQL>
So it seems External table not support this. But my question is - what the logical reason behind this design?
There is no mechanism in Oracle for locking rows in external tables, none of the concurrency controls which we get with regular heap tables. So updating is not allowed.
External tables created with the Oracle Loader driver are read only; the Datapump driver allows us to write to external table files but only in an CTAS mode.
The problem is that eternal tables are basically windows on OS files, without the layer of abstraction and control that internal tables offer. Basically, there is no way for the database to lock a record in an OS file, because the notion of a "record" is a databse thang, not an OS file thang.
External tables are designed for only one thing: data loading and unloading. They are simply not meant to be used with normal DML, and they're not really meant for normal selects either - that works, but if you need to do a lot of selections on an external table, you're "doing it wrong": load the data into proper tables, calculate statistics & add indexes as necessary.
Having external tables behave like normal tables would need that all the transactional machinery be implemented for them, which is very complex, and not worth it since that's not what they are meant for.
If you need normal tables and want to transplant them from one Oracle database to another, you should evaluate using transportable tablespaces too.
Limitations of external table are an obvious consequence of their being read-only; they are an adapter to involve in SQL queries either arbitrary record-organized files (ORACLE_LOADER type) or exported copies of tables in another database (ORACLE_DATAPUMP type).
As already mentioned, external tables are only good for full table scan queries; if one needs to use indexes in heavy duty queries or to modify foreign data sets that have been imported from files, regular tables can be populated using the SQL Loader tool.
I have one database in mysql.
But when i log into phpMyAdmin , it shows another database called information_schema.
Is that database always present with one database?
I mean to say is there a copy of information_schema for every database present in mysql or is there one database called inforemation_schema per mysql server?
If i modify this information_schema database how will that affect my current database?
You can think of information_schema as a "master database" that holds details about all the other databases on the server such as the names and types of tables, columns and users.
What is information_schema?
From the reference documentation:
INFORMATION_SCHEMA provides access to
database metadata.
Metadata is data about the data, such
as the name of a database or table,
the data type of a column, or access
privileges. Other terms that sometimes
are used for this information are data
dictionary and system catalog.
INFORMATION_SCHEMA is the information
database, the place that stores
information about all the other
databases that the MySQL server
maintains. Inside INFORMATION_SCHEMA
there are several read-only tables.
They are actually views, not base
tables, so there are no files
associated with them.
What is stored in information_schema?
You can see the kinds of things stored in information_schema, and the way in which they are organised, by viewing this diagram (for MySQL 5.0) or this diagram (for MySQL 5.1).
What happens if I modify information_schema?
In reality, information_schema is a collection of read-only views. As such, it should be impossible to modify it and do any damage. However, the MySQL FAQ on this topic has this to say:
23.7.3: Can I add to or otherwise modify the tables found in the
INFORMATION_SCHEMA database?
No.
Since applications may rely on a
certain standard structure, this
should not be modified. For this
reason, we cannot support bugs or
other issues which result from
modifying INFORMATION_SCHEMA tables or
data.
This implies that if you do find yourself able to modify information_schema (which should be impossible, and is in MySQL, but other vendor implementations of SQL might allow it) you should at the very least choose not to. If you could damage/modify information_schema you'd be damaging the actual structure (e.g. table names, column types) of your other databases.
Does every user have their own copy of information_schema?
Each user can see information_schema that pertains to the tables and databases they have access to. Some users with heavily limited rights will still see information_schema but will see only NULL values for any information_schema queries. However, it is important to remember that information_schema is not an actual database, but simply a convenient way SQL provides so that you can select information about your database(s) and table(s).
From the reference documentation:
Each MySQL user has the right to
access these tables, but can see only
the rows in the tables that correspond
to objects for which the user has the
proper access privileges. In some
cases (for example, the
ROUTINE_DEFINITION column in the
INFORMATION_SCHEMA.ROUTINES table),
users who have insufficient privileges
will see NULL.
Where can I find more information?
The MySQL Reference Manual article on information_schema (http://dev.mysql.com/doc/refman/5.0/en/information-schema.html)
The MySQL FAQ article on information_schema (http://dev.mysql.com/doc/refman/5.0/en/faqs-information-schema.html)