| copyright |
|
||
|---|---|---|---|
| lastupdated | 2018-07-18 | ||
| keywords | |||
| subcollection | Db2whc |
{:new_window: target="_blank"} {:shortdesc: .shortdesc} {:codeblock: .codeblock} {:screen: .screen} {:tip: .tip} {:important: .important} {:note: .note} {:deprecated: .deprecated} {:pre: .pre}
{: #data_virt_fed}
Db2 data virtualization (also known as federation) is supported by {{site.data.keyword.dashdbshort_notm}}. Data virtualization gives you single-query access to all of your data that is on multiple distributed databases anywhere in your organization. You can access data that is on any of your Db2 or Informix data sources, both in the cloud and on premises. {: shortdesc}
This function is supported on all versions of {{site.data.keyword.dashdbshort_notm}}, except for the Entry plan. However, you can use the Entry plan as a target from which you can pull data.
{: #use_cases}
By federating your data sources that are located both in the cloud and on premises anywhere in your organization, your virtualized data appears to be retrieved from a single source. Data virtualization eliminates the burdensome and costly data migration process, giving you the ability to analyze all of your data efficiently and cost effectively.
Users of products in the Db2 family can federate data from {{site.data.keyword.Db2_on_Cloud_short}} and {{site.data.keyword.dashdbshort_notm}} databases. From a common interface to access the data, you can easily add, query, and analyze your data without complex ETL processes and without any additional code.
Federation gives you the ability to increase the capacity of an on-premises database by federating with a database on the cloud. Data virtualization in this case is a great option if your on-premises database is running out of storage. Increasing the capacity of a database with federation is useful for new development because developers don't need to change a database already in production. You can also federate between two {{site.data.keyword.dashdbshort_notm}} databases to increase the database capacity beyond the current limits of the Flex plan.
{: #getting_started}
The following steps are an example of how you go about federating your disparate data sources to appear as if the data is retrieved from a single source. The following example illustrates the federation of two {{site.data.keyword.dashdbshort_notm}} databases:
{: #targ}
Host name: targetdotcom
-
Create a table
testdatain schemaadmin2. -
From the {{site.data.keyword.dashdbshort_notm}} console, load the
testdatatable with data as useradmin2with passwordYYYY.
{: #fed_src}
From the {{site.data.keyword.dashdbshort_notm}} console:
-
Create a server to talk to the target machine:
create server <server_name> type dashdb version 11 wrapper drda authorization "<admin_user_on_target>" password "<admin_password_on_target>" options (host '<target_host_name>', port '50000', dbname 'bludb')For example:
create server db2server type dashdb version 11 wrapper drda authorization "admin2" password "YYYY" options (host 'targetdotcom', port '50000', dbname 'bludb') -
Create the user mapping for admin2:
create user mapping for <admin_user> server db2server options (remote_authid '<admin_user_on_target>', remote_password '<admin_password_on_target>')For example:
create user mapping for admin1 server db2server options (remote_authid 'admin2', remote_password 'YYYY') -
Create a nickname for the database:
create nickname <nickname> for <server_name>.<schema_name>.<table_name>For example:
create nickname ntest1 for db2server.admin2.testdata -
Test that you can pull data from the target server:
select * from <nickname>For example:
select * from ntest1
For more information about data virtualization (federation), see: Federation {:new_window}.
For information about the data sources supported by federation, see: Federation Supported Data Sources {:new_window}.