I have two companies using same application running in Oracle Database. Now the companies are merging and making a single company. The databases are huge with an approximate size of 10 TB.
We wanted to have the application in two databases to be merged and have a single application pointed to both the databases with minimal work.
Help is highly appreciated.
Regards
Bjm
Using DB Links feature in Oracle
For more information you can use below link regarding Database Links:
https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts002.htm#ADMIN12083
It would enable you to build a SQL statement that references tables from the two different databases.
If you want to access the data in instance B from the instance A, you can use below query and edit the details accordingly:
CREATE DATABASE LINK dblink_example
CONNECT TO xxusernamexx IDENTIFIED BY xxpasswordxx
USING
'(DESCRIPTION=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=xxipaddrxx / xxhostxx )
(PORT=xxportxx))
(CONNECT_DATA=
(SID=xxsidxx)))';
Now you can execute the below query to access the table:
SELECT * FROM tablename#dblink_example;
You can perform any operation DML, DDL, DQL using DB Link
We have one website currently being used by 3 clients. We have 3 different versions of the same source code which is calling 3 different databases. So,
1) Client A access "http://custA.weblink.com" will access "CustA" Database
2) Client B access "http://custB.weblink.com" will access "CustB" Database
3) Client C access "http://custC.weblink.com" will access "CustC" Database
All databases have the same structure, table design and stored procedures. Only the data is different.
The issue is, when I need to do deployment for stored procedures, I need to repeat the backup and perform deployment 3 times. It's not really hard even when there are lots of stored procedures need to be deployed but doesn't seems like a good practice.
Now I only have 3 clients, what if in the future I have 10? I need to repeat backup and deployment 10 times which is time consuming and it's hard to guarantee that all stored procedures in all databases will always be the same.
In this type of case where I have existing multi applications and databases, what could be the good practice or measurements to take to make the situation better? I don't think my company will allow making huge changes like merging all clients data into one database and re-write application flow to get the right data.
I thought about creating one main database without any data. All the Stored Procedures script will be deployed there. And each of the existing "CustA", "CustB" and "CustC" DB, I will use to EXEC method to call Stored Procedure from main database to process the data in the relevant DB. Like this:
1) Main database
USE [MainDatabase]
ALTER PROCEDURE USP_GetCustomerById
#CustId BIGINT
SELECT * FROM [Customer] WHERE Id = #CustId
2) CustA database (Same flow for CustB and CustC database)
USE [CustA]
ALTER PROCEDURE USP_GetCustomerById
#CustId BIGINT
EXEC MainDatabase.dbo.USP_GetCustomerById #CustId
Will there be any impact if I do so?
Have you ever considered to use visual studio to create an SQL Server Database Project? Here you can import for instance the first server ClientA settings for a single Database. It will import (schemas,objects,views,indexes and so on) And then you can setup different deployment servers. You can also compare Source and destination (A and B) to each other, to see if you have differences. (I
Example on deploying on Database to multiple servers
As you can see in my picture i have the whole structure for one database. In the bottom of the Solution Explorer you can see i have something called PROD and TEST. This is actually two different servers. You could create the 3 servers you need and then you can just press deploy.
Example on Schema compare
Here i have compared a source with my project. Then i can import my changes i made on ClientA and inject them to my project, so i can deploy them to the other servers.
in my company, we have several environments with MS SQL database servers (SQL 2008 R2, SQL 2014). For the sake of simplicity, let us consider just a TEST environment and a PROD environment and two sql servers in each. Let the servers be called srTest1, srTest2, srProd1, srProd2 and each be running a default MS SQL Server instance. We work with multiple databases, say DataDb, ReportDb, DWHDb.
We want to keep the same source code in T-SQL for both TEST and PROD, but the problem is the architecture or distribution of the above mentioned databases in each environment:
TEST:
srTest1 - DataDb
srTest2 - DWHDb, ReportDb
PROD:
srProd1 - DataDb, ReportDb
srProd2 - DWHDb
Now, say, in ReportDb, we write stored procedures with many SELECTs referencing tables and other objects in DataDb and DWHDb. In order to have source code as universal as possible, we decided to create linked servers for each database on each db server in each environment and name them with respect to the database they're created for. Therefore, there'll be these linked servers:
lnkDataDb, lnkReportDb and lnkDWHDb on srTest1,
lnkDataDb, lnkReportDb and lnkDWHDb on srTest2,
lnkDataDb, lnkReportDb and lnkDWHDb on srProd1,
lnkDataDb, lnkReportDb and lnkDWHDb on srProd2.
And we'll adjust the source in the stored procs accordingly. For instance:
Instead of
SELECT * FROM DataDb.dbo.Contact
We'll write
SELECT * FROM lnkDataDb.DataDb.dbo.Contact
The example above is reasonable for a situation where the database from which you execute the query (ReportDb) lies on a different server than that with the referenced table (DataDb). Which is the case for the TEST environment. But not so in PROD. It is performance I'm here concerned about. The SQL Server will treat that SELECT as a "remote query" no matter whether, in fact, it is a reference to a local object or not.
Now, it comes the most important part:
If you check these 3 queries for their actual execution plans, you'll see an interesting thing:
(1) SELECT * FROM DataDb.dbo.Contact
(2) SELECT * FROM srProd1.DataDb.dbo.Contact
(3) SELECT * FROM lnkDataDb.DataDb.dbo.Contact
The first two (query #1 and #2) have the same execution plan (the fastest possible) even if you use the four-part name manner of referencing the table Contact in #2.
The last query has a different plan (remote query, thus slower).
The question is:
Can you somehow create a linked server to self (the same sql server instance, the default instance actually) as an "alias" to the name of the host (srProd1) in order for the SQL server to be forced to understand it as local and not issue "remote execution" plans?
Thanks a lot for any hints
Pavel
Recently I found a workaround which seems to solve this kind of issues more efficiently and more elegantly than the solution with self-pointing linked servers.
If you work (making reports, for example) with multiple databases on multiple SQL servers and the physical distribution of the databases on the servers is a challenge since it may differ from one environment to another (e.g. TEST vs PROD), I suggest this:
Use three-part db object names whenever possible. If the objects are local, then execution plans are also local, and thus effective.
Example:
SELECT * FROM DataDb.dbo.Contact
If you happen to run the above query from within a different SQL server instance (residing on a different physical machine, for example, but this not necessarily, the other SQL server instance could be installed even on the same machine), briefly if you're about to use a four-part name:
SELECT * FROM lnkDataDb.DataDb.dbo.Contact
Then you can circumvent that using the following trick:
Let's assume lnkDataDb points to srTest2 and you're executing your queries from srTest1. Now, you'll create a "fake" database DataDb on your local server (srTest1). This fake DataDb shall contain no real db objects (no tables, no views, no stored procedures, no UDFs etc.). There shall only be synonyms defined in it. (And there also shall be the same schemas in it as those in the real DataDb on srTest2). These synonyms shall be named exactly the same way as their real db-object counterparts in DataDb on srTest2. Example:
-- To be executed on srTest1.
EXEC sp_addlinkedserver
#server = N'lnkDataDb',
#srvproduct = N'',
#provider = N'SQLNCLI',
#datasrc = N'srTest2'
;
GO
CREATE DATABASE [DataDb];
GO
USE [DataDb];
GO
CREATE SYNONYM dbo.Contact FOR lnkDataDb.DataDb.dbo.Contact;
GO
Now, if you want to SELECT rows from the table dbo.Contact residing in the database DataDb on srTest2 and you're executing your query from srTest1, you'll use a simple three-part table name:
SELECT * FROM DataDb.dbo.Contact
Of course, on srTest1, this is not a table, that's just a synonym referencing the same-named table on srTest2. However, that's the trick, you use the same query syntax as if you were executing it on srTest2 where the real db object resides.
There are disadvantages of this approach:
On the local server, at the beginning, there must not be a database
with the same name as the remote one. Because you're about to create
a "fake" database with that name to reflect the names of remote
db objects.
You're creating one database that is almost empty, thus
increasing the mess of various databases residing on your local
SQL server. This might provoke reluctance of your database admin
if they prefer having as few databases as possible.
If you're developing your T-SQL scripts in SQL Server Management
Studio, for example, using synonyms cuts you off from the convenience
of the IntelliSense feature.
Advantages outweigh the above-mentioned disadvantages, though:
Your scripts work in any environment (DEV, TEST, PROD) without
the need to change any part of the source code.
If the other database you're querying data from resides on the same
SQL server instance as your script, you also use the three-part name
convention and your SQL server evaluates the query in execution plan
as local which is OK. (This is what the original question of this
post was searching to solve.)
If the other database you're querying data from resides on another
SQL server instance, you still use a "local syntax manner" of a SQL
query (with the synonym) which, only at runtime, evaluates in
a remote execution plan. Which is also fine because the db object
actually is remote.
To summarize
The query executes as local if the referenced object is local, the query executes as remote if the referenced object is remote, but the T-SQL script is always the same. You don't have to change a letter in it.
I have a few instances of DB2 10.5 server running on one physical Linux machine, let name them INST1 and INST2.
All of them contain multiple schemas, however schema-naming is unique accross whole machine, for example
INST1_SCHEMA_A,
INST2_SCHEMA_A etc.
What I would like to do is to somehow create a user that can access all of those schemas as they were on one instance, so it would be possible to make a queries like:
SELECT ID
FROM INST1_SCHEMA_A
UNION
SELECT ID
FROM INST2_SCHEMA_A
How can I achieve that? Should I just link databases and alias schemas?
Federation
is the keyword for your request. DB2 LUW to DB2 LUW is included in the license and this could be done across multiple databases - not matter if they reside within the same instance, another instance on the same server or even a different server.
Set FEDERATED = YES in the DBM CFG, define a server and set up Nicknames for remote tables. For details refer to this article or this one or the IBM Knowledge Center.
I have just noticed that one of the views I create from Microsoft Access in SQL Server via a linked server is interpreted differently in different machines/setups etc.
Example:
EXEC sp_addlinkedserver acc465tghv, 'OLE DB Provider for Jet', 'Microsoft.Jet.OLEDB.4.0', 'C:\tester.mdb'
EXEC sp_addlinkedsrvlogin acc465tghv, TRUE
GO
CREATE VIEW TI265 AS SELECT * FROM acc465tghv...TI0CE
When I open the access database in a different machine/computer, the date is formatted differently and I am sure other data types may be formatted/interpreted different when you open the same database (.mdb file) in different machines/computers with different versions of Access and setups etc.
The question is, how can I create a view or a table that shows the access table exactly the same in SQL server?
What options or work arounds are there?
Thanks all
This is pretty standard SQL Server behaviour, based on some functions being deterministic and others non-deterministic. You can read up a bit more about the various functions here.
You can also use SET DATEFORMAT to specify the format in which strings are interpreted by SQL Server.
However, in this scenario, it's pretty likely that the client machine is the thing that is formatting the date differently, based on it's Locale.