Published on

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Database Links Advanced Administration TipsWhat is a Database Link and how do I configure one?A Database Link is a named object created in one database which describes how toconnect to another, completely different, database. Using a Database Link, it is possible,whilst connected to, say, the DB8 database to issue the command SELECT * FROM EMP@DB9,and the data that is returned will be that from the EMP table in the DB9 database.Links are thus a means of performing distributed database processing –the ability todistibute data around many different databases, on many different machines, in manydifferent physical locations. Such an approach gives you redundancy (if the Melbournemachine blows up, it takes the Melbourne data with it, but Perth and Sydney continueworking as before). It also gives you, potentially, performance benefits –with tablesdistributed amongst many machines, no one machine has to do all the hard work ofresolving Users’ queries. (On the other hand, with data having to pass back and forthacross the network, which is usually relatively slow, the performance benefits ofdistributed processing can easily be swamped by awful networking performance).Database Links are thus at the heart of Advanced Replication, which is Oracle’s completeinfrastructure for distributed database processing.Links are relatively easy to set up, but they do depend on having first configured allaspects of inter-machine and inter-database networking and communication successfully.If you don’t know one end of a LISTENER.ORA from a SQLNET.ORA, then getting Links towork reliably is going to be awkward.Getting Started with the NetworkFor the purposes of this discussion, I’m going to assume that we have an Oracle 8i database(called DB8) on a machine called MONTEVERDI, and an Oracle 9i database (called DB9) ona machine called MOZART. Both machines are part of a networking domain called‘aldeburgh.local’. (For the record, this is exactly how my test machines at home areconfigured, using Windows 2000). We want to establish a link from the DB8 database tothe DB9 one, not the other way around (we’ll come to that later!).Being such a simple network, we’ll use the ‘local naming’ method of connection, meaningthat we’ll use local copies of tnsnames.ora to resolve connection requests to the twoInstances.You might pause at this. Surely, tnsnames.ora is a method of connecting clients toInstances, and therefore it resides only on the client machine? No. One of the keyfeatures of a Database Link is that it is the database that you are directly connected tothat has to be able to resolve the name of the database you want to link to. Therefore,tnsnames.ora must also reside on one or more of the Oracle servers themselves.Copyright © Howard Rogers 2002 3/3/2002 Page 1 of 10
  2. 2. Database Links Advanced Administration TipsSince in this example it is MONTEVERDI that will require the ability to resolve a connectionrequest to the DB9 database on MOZART, we need a tnsnames.ora on MONTEVERDI thatlooks like this:DB9 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = db9.aldeburgh.local) ) )Now the tnsnames.ora merely points the connection request off to the Listener which isrunning on MOZART. So the listener.ora on MOZART must look like this:LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = mozart)(PORT = 1521)) )SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = db9.aldeburgh.local) (ORACLE_HOME = d:oracleora91) (SID_NAME = DB9) ) )This is fairly standard stuff. The Listener is listening on a standard port for TCP/IPconnection requests, on behalf of the db9.aldeburgh.local database. When it receives one,it will connect to the “DB9” Instance, and we should be in business.One final configuration trap: the file sqlnet.ora is used to establish a variety of defaultparameters for all connections made from one machine to another –for example, whetherencryption should be used. One of its parameters is NAMES.DEFAULT_DOMAIN. If this isallowed to be set to anything at all, we’ll have problems, because Oracle appears toappend this default on to the end of otherwise fully-specified global database names.Since we’ve specified our global names exactly, we have no need for a default. Therefore,we need to remove that line (if it’s there) from the sqlnet.ora file. That leaves sqlnet.oralooking like this:SQLNET.AUTHENTICATION_SERVICES= (NTS)NAMES.DIRECTORY_PATH= (TNSNAMES)Copyright © Howard Rogers 2002 3/3/2002 Page 2 of 10
  3. 3. Database Links Advanced Administration TipsInstance ConfigurationTechnically, when you come to create your Database Links, you can call them anything youlike. But Oracle strongly recommends that you follow the ‘global names’ convention,because Advanced Replication (and some other advanced features) won’t work unless youdo. What that convention means is that your links are named in the format <databasename>.<domain name>. To do that might require some editing of your init.ora, however.Three parameters are crucial.DB_NAME is pretty self-explanatory, and has to be set whenever you create a newdatabase. Not a lot of choice here, therefore –ours will be set to “DB9”.DB_DOMAIN is not compulsory though, yet it’s of extreme importance for linking databases.It defaults to a null string so in our case we’ll need to set it explicitly to “aldeburgh.local”.If you’ve got a registered Internet domain, then that’s probably what you’d use (I don’t,which is why the ‘.local’ is there).If you put DB_NAME and DB_DOMAIN together, you’ve got yourself a Global Database Name.In our case, it will be “db9.aldeburgh.local” –though this isn’t actually set as an init.oraparameter in its own right, but is merely constructed from the other two whenever needed.It’s important that the global database name as implied in the DB9 init.ora is what theGLOBAL_DBNAME setting in MOZART’s listener.ora is set to, and also what theSERVICE_NAME is set to in MONTEVERDI’s tnsnames.ora. If you check all these entriesabove, you’ll see that this is indeed the case here. Failure to make sure that they matchwill mean that the DB8 database will request a connection to an Instance which can’t beidentified in the first place or, if identification is possible, can’t be connected to.One last parameter now needs to be set. It’s GLOBAL_NAMES, and it needs to be set toTRUE. There’s no absolute requirement for the parameter to be set in this way: butAdvanced Replication won’t work without it. What it does is to force that all DatabaseLinks must have names which match the global name of the database they’re connectingto. In our case, since we’re connecting from DB8 to DB9, it needs to be set to TRUE in theinit.ora for the DB8 database on MONTEVERDI.One final warning: databases are created (or should be –the default appears to be“us.oracle.com”!) with a global name that needs to match what you configure as theGlobal Database Name in the way described above. If you change your init.ora settings sothat the DB_NAME+DB_DOMAIN combination no longer matches what was set as the globalname at database creation, you’ll need to rename the database. That’s relatively easy todo:Alter database rename global_name to <something>;Copyright © Howard Rogers 2002 3/3/2002 Page 3 of 10
  4. 4. Database Links Advanced Administration TipsIn our case, we may therefore need to issue this command whilst connected as SYS to theDB9 database:Alter database rename global_name to db9.aldeburgh.local;Once all that is set up, we should be able to create our links without too much trouble.Creating the Database LinkThis is the easy part. The basic syntax for creating a Database Link is:Create database link <link name>Connect to <schema> identified by <password>Using <tnsnames alias>;The real question is what goes in all those variable entries –the link name and so on?Well, the link name is the fully-qualified global database name that was discussed earlier.In our case, that’s “db9.aldeburgh.local”. There’s no rule that says it must match theglobal name, remember –except that, following Oracle’s advice, we’ve set GLOBAL_NAMESto be TRUE for the DB8 database. If we therefore specified anything other than“db9.aldeburgh.local” as the link name, the first time we tried to fetch data across thelink we’d get the following error message:ORA-02085: DATABASE LINK DB9.MADEUPNAME CONNECTS TO DB9.ALDEBURGH.COMThe <schema> and <password> entries of the syntax are fairly self-explanatory: which bitof the DB9 database do we want to connect to? If you just want to select from Scott’stables over the link, for example, then ‘Scott’ and ‘Tiger’ would be sensible entries. Youmight not want to limit yourself in this way, though: suppose you want to be able to selectfrom tables that happen to reside in multiple schemas? Well, that can be done, too… butI’ll describe that in my paper “What are the different types of Database Links that can becreated?”. For now, let’s keep it simple.Finally, the <tnsnames alias> entry is hopefully pretty obvious. It’s whatever is in thetnsnames.ora file on the machine where DB8 resides as the alias for the connection to“db9.aldeburgh.local”. Being an alias, you could have set it to anything –but if you referback to the discussion about our specific tnsnames.ora file, you’ll see that we’ve set it to“db9”. Bear in mind that it’s what is on the DB8 machine that’s important. It’s thismachine, after all, that has to resolve the connection request, and pass it on to theListener running on the DB9 machine.All of which means that we can now issue the following command:Copyright © Howard Rogers 2002 3/3/2002 Page 4 of 10
  5. 5. Database Links Advanced Administration TipsCreate database link db9.aldeburgh.localConnect to scott identified by tigerUsing ‘db9’;Notice how the tnsnames.ora alias goes inside single quotes, but nothing else does.Using the Database LinkNow that the link exists, we can select data across it. In our case, whilst still connected tothe DB8 database, we can issue the following command:Select * from emp@db9.aldeburgh.local;The rows you see returned will be those coming from the DB9 database. Notice the syntaxhere. Firstly, I haven’t needed to qualify whose EMP table we’re selecting from, becausethe Link itself was created as pointing directly to Scott’s schema. Second, the fulldatabase link name is then supplied after an “@” symbol.Now let’s try some simple DML:SQL> update emp@db9.aldeburgh.local set sal=7000 where empno=7369;1 row updated.SQL> commit;Commit complete.So DML commands follow the same rule: fully qualify the object names you are updating,deleting from or inserting into, with an “@” and the link name. Commits, as you notice,are perfectly happy to work across the link too. (Incidentally, just in case you’rewondering, all the rollback and redo generated by this transaction was raised in the DB9database, not the DB8 one. In other words, the command was processed exactly as if ithad been issued whilst connected normally to the DB9 database).What about DDL? Let’s try this:SQL> truncate table emp@db9.aldeburgh.local;truncate table emp@db9.aldeburgh.local *ERROR at line 1:ORA-02021: DDL operations are not allowed on a remote databaseSo no DDL commands of any type are permitted across the link. Try a “create index”, a“create table newemp@db9.aldeburgh.local as select * from emp@db9.aldeburgh.local”, a“drop table” or any other piece of DDL you can think of, and the same error message willCopyright © Howard Rogers 2002 3/3/2002 Page 5 of 10
  6. 6. Database Links Advanced Administration Tipsappear. (Again, in case you were wondering, a “create table newemp as select * fromemp@db9.aldeburgh.local” will work fine: the DDL bit of the statement is taking place inthe local DB8 database, and only the select is taking place across the link).So the general rule is that queries and DML across a link are permitted, but DDL isn’t.When DML is performed, by the way, all referential integrity constraints are checked andapplied as normal (though if it happens that the parent table, say, is in a different schemathan the one referred to in the ‘create database link’ command you’ll have trouble).Finally, what does the link look like as far as the DB9 database is concerned? If we queryv$session after the link is created, but before it is actually used, we get this sort of result:SQL> connect system/manager@db9Connected.SQL> select sid, serial#, username from v$session 2 where username is not null; SID SERIAL# USERNAME---------- ---------- ------------------------------ 8 12 SYSTEM1 row selected.Here we see only SYSTEM’s session, in which this query has just been issued. If we now (ina different session) connect as SYSTEM on the DB8 database, and issue a select across thedatabase link, we’ll see this: SID SERIAL# USERNAME---------- ---------- ------------------------------ 7 5 SCOTT 8 12 SYSTEMNotice the new session here: it’s listed as Scott’s even though I just stressed the fact thatI’d connected to the DB8 database as SYSTEM. The reason for that again lies in the way weissued the ‘create database link’ command. To remind you, it was:Create database link db9.aldeburgh.localConnect to scott identified by tigerUsing ‘db9’;So the link itself dictates that, whoever we happen to be connected as on DB8, theconnection to the DB9 database must be made as Scott.Copyright © Howard Rogers 2002 3/3/2002 Page 6 of 10
  7. 7. Database Links Advanced Administration TipsThings also get interesting when you select the OSUSER column from v$session, instead ofthe plain old USERNAME:USERNAME OSUSER-------- ----------------------SCOTT ALDEBURGHMONTEVERDI$SYSTEM ALDEBURGHhowardjrNotice that the OSUSER column contains the name of the Windows 2000 machine hostingthe DB8 database (MONTEVERDI), not (as in the last line displayed) the actual operatingsystem name of an individual user. This is about the only way to spot the differencebetween a ‘real’ user connected to the remote database in the normal fashion and a userconnecting to it via a database link.Managing Database LinksHaving created a Database Link, you need to be able to find out which links have beencreated, and how to modify them or get rid of them altogether.To view which links exist, select from the DBA_DB_LINKS views (there are equivalentUSER_ and ALL_ views, of course):SQL> select * from dba_db_links;OWNER DB_LINK USERNAME HOST CREATED------- --------------------- ----------- --------- ---------SYSTEM DB9.ALDEBURGH.LOCAL SCOTT db9 03/MAR/02Notice that the ‘host’ column doesn’t tell you the host at all (not in the sense of themachine being connected to, at least). Rather, it tells you the tnsnames alias being usedto make the connection.Be aware that selecting from the same view in the DB9 database produces no rows at all.In other words, you can’t tell from within a database what other databases might havelinks connecting to it (unless those links are used, of course, at which point –as we’veseen- it becomes obvious in v$session).You can’t actually modify a Database Link once it’s been created. Instead, you have todrop the entire thing, and re-create it from scratch:SQL> drop database link db9.aldeburgh.local;Database link dropped.Copyright © Howard Rogers 2002 3/3/2002 Page 7 of 10
  8. 8. Database Links Advanced Administration TipsSQL> create database link db9.aldeburgh.local 2 connect to hr identified by hr 3 using db9;Database link created.Finally, you need to know how to close down a database link once it’s been finished with –remember that v$session shows the link from DB8 however many hours have passed sincethe last ‘select * from emp@db9.aldeburgh.local’! That means there’s a Server Processticking away on DB9, chewing up some memory and CPU cycles, which we might prefer notto waste.Issue this command (again, this is done on the database to which you are directlyconnected –in our case, DB8):Alter session close database link db9.aldeburgh.local;That closes the link (but obviously doesn’t drop it from the database altogether). Linksare re-opened by performing some select or DML activity across them again. One minornasty with this: you can’t close a link (hopefully for obvious reasons) if someone is in themiddle of doing some work across it. If you try, you’ll get an ORA-02080: database link isin use error message. What’s a bit tricky about this is that a select statement counts asdoing some work –and selects have to be committed before the link is determined not tobe in use.As a simple example:SQL> select empno, ename, sal from emp@db9.aldeburgh.local; EMPNO ENAME SAL---------- ---------- ---------- 7698 BLAKE 2850 7839 KING 5000 7844 TURNER 1500 7900 JAMES 950 7902 FORD 3000 7934 MILLER 1300 9999 ROGERS 88887 rows selected.SQL> Alter session close database link db9.aldeburgh.local;ERROR:ORA-02080: database link is in useSQL> commit;Commit complete.Copyright © Howard Rogers 2002 3/3/2002 Page 8 of 10
  9. 9. Database Links Advanced Administration TipsSQL> Alter session close database link db9.aldeburgh.local;Session altered.That could prove a bit awkward to remember if, like me, you’ve grown accustomed toordinary select statements not requiring commits to make them do their stuff! Obviously,it’s much less of a hassle with ordinary DML statements.Notice, too, that the command is an ‘alter session’ one. That means the User wishing toclose the link has to possess the alter session privilege. It also means that a link that oneUser happens to be using to perform a substantial piece of DML cannot be summarily closedby someone else (thus causing general consternation, transaction failure and massiverollback all round!). The link is session-specific, and only your own session can be used toclose it.Making Links Easier to UseOne final point I’ll mention briefly here. It’s frankly a bit of a pain always to have toqualify your select statements (or DML) with long-winded fully qualified link names.Remember that public synonyms and views created in the local database can come to yourrescue:SQL> create view fred as 2 select empno, ename, job from 3 emp@db9.aldeburgh.local 4 where sal>500;View created.SQL> select * from fred; EMPNO ENAME JOB---------- ---------- --------- 7499 ALLEN SALESMAN 7521 WARD SALESMAN…is one approach. You might not like having to create lots of views in DB8 to referencetables in the DB9 database, however.Instead, you could try this:SQL> create public synonym ginger 2 for emp@db9.aldeburgh.local;Synonym created.Copyright © Howard Rogers 2002 3/3/2002 Page 9 of 10
  10. 10. Database Links Advanced Administration TipsSQL> select * from ginger where rownum<4; EMPNO ENAME JOB MGR HIREDATE---------- ---------- --------- ---------- --------- 7369 SMITH CLERK 7902 17/DEC/80 … 7499 ALLEN SALESMAN 7698 20/FEB/81 … 7521 WARD SALESMAN 7698 22/FEB/81 …Both of these approaches to what is laboriously known as ‘location transparency’ meanthat Users don’t get RSI everytime they want to access remotely-stored data!Copyright © Howard Rogers 2002 3/3/2002 Page 10 of 10