In oracle what's the differences between a database and a table space?
A little terminology:
Oracle defines a database as the set of files that you find on your Oracle system. This means all data in your Oracle system is in these database files, commonly known as "data files". There are other files in the database such as parameter files and redo logs.
On the other hand, an instance consists of the processes and memory areas that Oracle database uses. Together, a database and an instance make up a database system. (For more information, see the Oracle Concept guide)
Logically, you will want to define different spaces within that database. This is done via tablespaces (see Oracle Concept guide). A tablespace usually consists of one or more data files. When you define a table with CREATE TABLE, you can specify in which tablespace the table should be created. This allows you to seperate different applications on the same database system, for example.
The Oracle Concepts guide is an excellent source of information for questions like these. See this picture on how data files and tablespaces are composed.
Let's consider an example of an Ocean consist of lots of water. Now you want that water. For this what you do is collect water in barrel for better usage and better storage purpose. Same here Ocean is database having lots of Data files here data file means water and for better usage and handling you put that into barrel you can relate barrel as Tablespace
An Oracle database consists of one or more logical storage units
called tablespaces, which collectively store all of the database's
data.
Databases, tablespaces, and datafiles are closely related, but they have important differences:
Each tablespace in an Oracle database consists of one or more files
called datafiles, which are physical structures that conform to the
operating system in which Oracle is running.
A database's data is collectively stored in the datafiles that
constitute each tablespace of the database. For example, the simplest
Oracle database would have one tablespace and one datafile. Another
database can have three tablespaces, each consisting of two datafiles
(for a total of six datafiles).
reference link
DATABASES's data are stored in logical storage units called TABLESPACES. A database may contain "one or more" tablespaces. A tablespace may contain one or more datafiles.
A database's data is collectively stored in the datafiles that constitute each tablespace of the database.
Example: the simplest database may have one tablespace and one datafile. On the other hande another database can have 5 tablespaces which may contain two datafiles each (On a total of 10 files)
This question is quite dated. IBM Db2 also has Table spaces. I think there is some commonality between Db2 table spaces and Oracle database table spaces. In that respect this link offers more insight into why table spaces, as storage structures, are needed and how are they distinct from databases. Two benefits are easy recoverability of the database and better storage management.
Related
i have to take incremental backup of 5 specific tables in a oracle database...i cannot use data pump api as it doesn't support incremental backup...in recovery manager(RMAN) the backup is taken of whole database but i want to have backup if data changes in these 5 specific tables , not all tables in which data changes
You can take incremental backups of databases, individual tablespaces or datafiles. So if you only want 5 tables, you could move those tables into their own tablespace and then take backups of just that tablespace.
You would want to be very sure that these tables are "self-contained" in the sense that if you wanted to restore that tablespace to a specific point in time, you would not introduce a logical corruption into the rest of the database.
In Oracle schema used size can be greater than tablespace used size ? If yes how its possible as schema is associated with tablespace ?
A schema is not "associated" with a tablespace.
A user (=schema) can have a default tablespace, but that does not necessarily mean that all tables that user owns are stored in that default tablespace. If the user has the privileges, tables can be created in other tablespaces as well.
In addition to what #a_horse_with_no_name mentioned, you need to undrstand few basics of orale as well.
Oracle Tablespace -
This is a logical structure, meaning that a tablespace is not a
physical object
A tablespace is made of 1 or more physical structures called
datafiles. A datafile is a physical file on disk, just like any other file which sits on a hard disk but in an Oracle format. The datafile is created as part of a tablespace, and only one tablespace
Each tablespace can have different characteristics, such as extent
size and how the extents are managed
They are used to group segments into logical
groups. For example, you may have accounting data in one tablespace
and reporting data in another.
The Oracle Schema or User
Oracle Schema and user are synonymous and the terms are usually used
interchangeably
There can be thousands of users within one database
The schema owns segments and objects (tables, indexes,views,
constraints, etc) and each segment/object can belong to only one
schema
My boss has a concern that creating LOB columns in our database tables could result in effectively permanent storage overhead if we do not partition the table and drop the partitions over time (as opposed to just deleting the records). He thinks that data for the LOB will be stored separately when the record is created, which seems to be correct, but that Oracle may not delete the data for the LOB column when the row is deleted.
Is this correct or even possible? I find it hard to believe that the DBMS would handle object storage so poorly. We are using Oracle 11g if that changes anything.
I eventually found this ask tom question which covers the same topic.
When the database creates an extent to store the LOBs it is associated directly with the table. When rows containing those LOBs are deleted, the LOBs are removed from the extent which remaining the same size (it does not shrink just because a LOB was removed). However, the table is able to reuse the space from the removed LOB as one would expect.
So while the database at large is not able to reuse the free space in an extent created for a table's LOB storage, the space IS free for use by the table. The extent will exist (and therefore take up space that would otherwise be completely available to the database) until table is dropped or truncated, or the extent is explictly deallocated.
In the end, unless the extent(s) remaining allocated to the table is a concern (or there are other concerns that may be addressed through partition), creating partitions solely for this purpose is unnecessary.
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.
I'm a noob in Oracle, is it possible to partition a table to remote server using db link? is it possible at all?
I'm trying something like this:
CREATE TABLE Test (
TestID integer not null,
Name varchar2(20) not null
)
PARTITION BY LIST (TestID)
(PARTITION testPart1 VALUES (1)
TABLESPACE tbspc1,
PARTITION testPart2 VALUES (2)
TABLESPACE tbspc2#RemoteServer);
thank you
No, that will not work. You're confusing an instance with a database.
A database is the physical storage of the data and metadata. The number of disks you use and the location of the disks is up for management. You can put indexes one place, data in another; you can put some data on local drives and some on mounted drives. That's a database.
An Instance is the memory structures and computer processes which access a database and make it possible to query it, write to it, update it, etc.
When you say #DB_LINK... you're saying "That set of memory and cpu processes".
When you say Tablespace, you're saying "On those files, on those disks"
If you want to store data on the same drives that your #dblink is storing data then mount that drive and build a new tablespace there.
If you're trying to OPEN the database with more than one instance, that's called RAC and it's bit over your head. <-- I say this because you have to have these concepts mastered before you'd ever consider RAC.
It's hard to say that something is impossible, but based on the syntax diagram for CREATE TABLE this doesn't look possible. For the select statement you can see that the dblink syntax (# dblink): http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10002.htm#i2126073 But for partitioning storage there is no such remote syntax: http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_7002.htm#CJADDEEH
Perhaps the following would be a reasonable starting point:
Have a database at the "home office" to contain the common data.
Have a "local" database at each branch to store branch-specific data, with links to the "home office" database to access the common data.
To help eliminate the "single point of failure" which could occur if the central database was to go down or communications were to be lost, you might try replicating the common data from the central database to the branch databases so that each branch has a complete copy of the common data which could be updated on some sort of regular schedule.
Share and enjoy.