Let's say I have main database called db1. There is also another database called db2. Sometimes I need to get data from db2. Is it better to directly get data from db2 or to make view in db1?
If you're getting data from db2 you should create views in db2 for each query. Why? To create interfaces.
If someone will make changes in db2 he don't know your queries which are executed from db1. Your queries can stop working. If you create views for your queries in db2 and from db1 query view#db2 anyone who change structure in db2 will see invalid view in case his changes damaged your queries.
Of course I mean situation when your queries are embedded in packages or views. If you just query for analytic purpose it make no difference if you do it directly, with view on db1 or view on db2 just do as it is suitable for you. But good practice is setting interfaces so I would recommend to create view on db2 for datasets your later querying from db1. It can also make sense to create additional view or synonym on db1 side to have both side interface.
You will first need to set up a driver for connectng to DB2, a TNS connection entry for Oracle to connect with and a database link in Oracle to point to the connection.
The important thing is that you try, as far as possible, to insulate changes in one DB from the other.
I've this done different ways but this has worked for me;
For each table you are querying in DB2 create a DB2 view of JUST the columns you want from that table.
Create a view in Oracle that queries DB2_VIEW#DB2_database. Although not strictly necessary just query the columns you want - its good practice.
Create a synonym for the view and query through that. If the source of the data changes and the view is replaced by a different one you can switch the synonym to point at the new view instead of changing your code.
Summary:
Unless I've misunderstood you seem to be asking should I query the table directly in DB2 or should I go through views? I suggest that going through views insulates you from changes at either end to some extent so use the views.
Related
How does the view actually keep its data up to date? I mean does it execute the query each time that the view is queried or used for something? Also how does this affect performance, if the view queries a SQL Server - Oracle linked server.
A simple view is nothing but a stored query that is executed each time you call it. There is no performance benefit here.
You might want to have a look at stored procedures and materialized views if you need to optimize.
I need to do some data migration between two oracle databases that in different servers. I've thought of some ways to do it like writing a jdbc program but i think the best way is to do it in SQL itself. I can also copy the entire table over to the database I am migrating to but these tables are big and doesnt seem like a "elegant" solution.
Is it possible to open a connection to one DB in SQL developer then connect to the other one using SQL and writing update/insert functions on tables as if they were both in the same connection?
I have read some examples on creating linked tables but none seem to be oracle specific or tell me how to open the external connection by supplying it the server hostname/port/SID/user credentials.
thanks for the help!
If you create a Database Link, you can just select a from different database by querying TABLENAME#dblink.
You can create such a link using the CREATE DATABASE LINK statement.
It depends if its a one time thing or a normal process and if you need to do ETL (Extract, Transform and Load) or not, but ill help you out based on what you explained.
From what i can gather from your explanation, what you attempt to accomplish is to copy a couple of tables from one db to another, if they can reach one another then its really simple, you could just create a DBLINK (http://www.dba-oracle.com/t_how_create_database_link.htm) and then do a SELECT AS INSERT from either side using the DBLINK for one of the tables and the local table as the receiver or sender. Its pretty straight forward.
But if its a one time thing i would just move the table with expdp and impdp since that will be a lot faster and a lot less strain on the DB.
If its something you need to maintain and keep updated, why not just add the DBLINK and use that on both sides, this will be dependent on network performance though.
If this is a bit out of you depth or you cant create dblinks due to restrictions, SQL Developer has had a database copy option for a while and you can go as far a copying individual tables, but its very heavy on the system where its being run (http://deepak-sharma.net/2014/01/12/copy-database-objects-between-two-databases-in-oracle-using-sql-developer/).
Is it possible to create view in my database server of another servers database table?
Let's say you have a database called Testing on server1 and you have another database Testing2 on server2. Is it possible to create view of Testing2's table Table2 in server1's database Testing?
Also, I am using SQL Server 2008.
Please let me know if you have any questions.
Thanks,
Yes, you can. First, you need to link to the other server, using something like sp_addlinkedserver.
Then you can access the data using 4-part naming. Here is an example:
create view v_server1_master_tables as
select *
from server1.master.information_schema.tables;
It is possible through linked servers. However, I wouldn't encourage you to create views based on tables from another server, as it's likely that entire table will be selected from linked server every time you use this view - optimizer may not know about this table structure to issue any filters.
I've seen it at work, where nobody knew where select * from queries on large table come from that were slowing down the database, and it appeared that it was being used somwhere in another server, in a simple query.
At least you should check if your solution won't cause the above problem. Maybe someone else could elaborate on how optimizer behave when dealing with linked servers?
Am querying a remote database using DBLink. Now am wondering to speed up the query, how can i add indexes to few columns in the remote table.
Would appreciate if anyone can provide any recommendations around the same.
You could use DBMS_JOB or DBMS_SCHEDULER packages on the remote database to schedule a job, executing DDL.
But consider this, if Oracle throws an exception for DDL over databse links, there must be a good reason for it, right? You don't want anyone messing with your schema remotely over a database link. So instead, talk to the remote DBA and try to figure out solutions with him/her.
it can't be done over the dblink (even if your dblink is using the owning schema) you will see
ORA-02021: DDL operations are not allowed on a remote database
You could create a Materialized View in the remote database based in your query, add your prefered indexes to it, and then, if you need it, create a synonym for that materialized view.
John,
A good place to start would be the following Oracle documentation on "Tuning Distributed Queries".
http://download.oracle.com/docs/cd/B28359_01/server.111/b28310/ds_appdev004.htm
you could create the indexes in the remote database and build up your query in a view form (in the remote database of course).
that way the remote database will complete the query using all the methods he got (like indexes) and bring you back only the wanted resultes.
I have a table in a SQL Server database that needs to be visible to an oracle database. We have tried using a normal view over sqllink, but we are not able to create an onUpdate triggers on that view.
I have read that we can create the trigger if it is a materialised view, but is unable to find any information on whether it can be done across different databases. (all the example are for oracle to oracle tables)
Can someone tell me if it is possible? and what issues I might need to look out for if I used materialised views?
Thanks
I do something similar and ended up using Oracle's HS gateway to handle it. Created an MV based of tables or queries to establish a staging area in Oracle. Followed up with logic to meet requests.