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.
Related
My question is related to Oracle DB performance and ideally finding the better method of the two paths when creating a backup table
Create a new table as a copy of an existing
Merging data to an existing (empty table - The two tables are identical)
If it is a small table, it doesn't matter - both will be fast. Though, CTAS (create table as select) is probably the most usual way to create a "copy" of existing table.
If a table is very large, I don't know how it (CTAS) compares to merge; you should test it.
However, a backup table? Are you sure that's the right way to backup a table? I'd rather think of a proper (RMAN) database backup, or - at least - export (using Export Data Pump) into a file that resides in a filesystem (and can be stored elsewhere, e.g. onto an external hard disk drive, DVD and similar (does anyone use tapes any more? We do)).
Because, if database breaks down, along with your "original" table, that "backup" table will be lost as well.
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.
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.
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 need to perform a query 2.5 million times. This query generates some rows which I need to AVG(column) and then use this AVG to filter the table from all values below average. I then need to INSERT these filtered results into a table.
The only way to do such a thing with reasonable efficiency, seems to be by creating a TEMPORARY TABLE for each query-postmaster python-thread. I am just hoping these TEMPORARY TABLEs will not be persisted to hard drive (at all) and will remain in memory (RAM), unless they are out of working memory, of course.
I would like to know if a TEMPORARY TABLE will incur disk writes (which would interfere with the INSERTS, i.e. slow to whole process down)
Please note that, in Postgres, the default behaviour for temporary tables is that they are not automatically dropped, and data is persisted on commit. See ON COMMIT.
Temporary table are, however, dropped at the end of a database session:
Temporary tables are automatically dropped at the end of a session, or
optionally at the end of the current transaction.
There are multiple considerations you have to take into account:
If you do want to explicitly DROP a temporary table at the end of a transaction, create it with the CREATE TEMPORARY TABLE ... ON COMMIT DROP syntax.
In the presence of connection pooling, a database session may span multiple client sessions; to avoid clashes in CREATE, you should drop your temporary tables -- either prior to returning a connection to the pool (e.g. by doing everything inside a transaction and using the ON COMMIT DROP creation syntax), or on an as-needed basis (by preceding any CREATE TEMPORARY TABLE statement with a corresponding DROP TABLE IF EXISTS, which has the advantage of also working outside transactions e.g. if the connection is used in auto-commit mode.)
While the temporary table is in use, how much of it will fit in memory before overflowing on to disk? See the temp_buffers option in postgresql.conf
Anything else I should worry about when working often with temp tables? A vacuum is recommended after you have DROPped temporary tables, to clean up any dead tuples from the catalog. Postgres will automatically vacuum every 3 minutes or so for you when using the default settings (auto_vacuum).
Also, unrelated to your question (but possibly related to your project): keep in mind that, if you have to run queries against a temp table after you have populated it, then it is a good idea to create appropriate indices and issue an ANALYZE on the temp table in question after you're done inserting into it. By default, the cost based optimizer will assume that a newly created the temp table has ~1000 rows and this may result in poor performance should the temp table actually contain millions of rows.
Temporary tables provide only one guarantee - they are dropped at the end of the session. For a small table you'll probably have most of your data in the backing store. For a large table I guarantee that data will be flushed to disk periodically as the database engine needs more working space for other requests.
EDIT:
If you're absolutely in need of RAM-only temporary tables you can create a table space for your database on a RAM disk (/dev/shm works). This reduces the amount of disk IO, but beware that it is currently not possible to do this without a physical disk write; the DB engine will flush the table list to stable storage when you create the temporary table.