Oracle Exp/Imp Utility

Here are the main topics for this article:
  1.  What is the Import/ Export Utility ?
  2.  Which are the Import/ Export modes ?
  3.  Is it possible to exp/ imp to multiple files ?
  4.  How we can use exp/ imp when we have 2 different Oracle database versions?
  5. What I have to do before importing database objects ?
  6.  Is it possible to import a table in a different tablespace ?
  7.  In which cases imp/exp is used ?
  8.  How we can improve the EXP performance ?
  9.  How we can improve the IMP performance ?
10. Which are the EXP options ? 
11. Which are the IMP options ? 
12. Which are the common IMP/EXP problems ? 

1.  What is the Import/ Export Utility ?

Export (exp), Import (imp) are Oracle utilities which allow you to write data in an ORACLE-binary format from the database into operating system files and to read data back from those operating system files.

2.  Which are the Import/ Export modes ?

a) Full export/export

       The EXP_FULL_DATABASE & IMP_FULL_DATABASE, respectively, are needed to perform a full export. Use the full export parameter for a full export. 

b) TablespaceUse the tablespaces export parameter for a tablespace export.

c) User
This mode can be used to export and import all objects that belong to a user. Use the owner export parameter and the fromuser import parameter for a user (owner) export-import. 

d) TableSpecific tables (or partitions) can be exported/imported with table export mode. Use the tables export parameter for a table export/ import mode. 

3. Is it possible to exp/ imp to multiple files ?

Yes, is possible. Here is an example:  

exp SCOTT/TIGER FILE=C:\backup\File1.dmp,C:\backup\File2.dmp LOG=C:\backup\scott.log

4.  How we can use exp/ imp when we have 2 different Oracle database versions?

• exp must be of the lower version
• imp must match the target version

5. What I have to do before importing database objects ?

Before importing database objects, we have to drop or truncate the objects, if not, the data will be added to the objects. If the sequences are not dropped, the sequences will generate inconsistent values.  If there are any constraints on the target table, the constraints should be disabled during the import andenabled after import.
  

6.  Is it possible to import a table in a different tablespace ?

By default, NO. Because is no tablespace parameter for the import operation.

However this could be done in the following manner:

• (re)create the table in another tablespace (the table will be empty)
• import the table using INDEXFILE parameter (the import is not done, but a file which contains the indexes creation is generated)
• modify this script to create the indexes in the tablespace we want
• import the table using IGNORE=y option (because the table exists)
• recreate the indexes

Here is an example of INDEXFILE:

7.  In which cases imp/exp is used ?

• Eliminate database fragmentation
• Schema refresh (move the schema from one database to another)
• Detect database corruption. Ensure that all the data can be read (if the data can be read that means there is no block corruption)
• Transporting tablespaces between databases
• Backup database objects

8.  How we can improve the EXP performance ?

• Set the BUFFER parameter to a high value (e.g. 2M)
• If you run multiple export sessions, ensure they write to different physical disks. 

9.  How we can improve the IMP performance ?

• Import the table using INDEXFILE parameter (the import is not done, but a file which contains the indexes creation is generated), import the data and recreate the indexes
• Store the dump file to be imported on a separate physical disk from the oracle data files
• If there are any constraints on the target table, the constraints should be disabled during the import and enabled after import
• Set the BUFFER parameter to a high value (ex. BUFFER=30000000 (~30MB)  ) and COMMIT =y  or set COMMIT=n (is the default behavior: import commits after each table is loaded, however, this use a lot of the rollback segments or undo space for huge tables.)
• use the direct path to import the data (DIRECT=y)
• (if possible) Increase DB_CACHE_SIZE (DB_BLOCK_BUFFERS prior to 9i) considerably in the init.ora file
• (if possible) Set the LOG_BUFFER to a big value and restart oracle.

10.  Which are the EXP options ? 

EXP Option	Default value	Description
buffer		Specifies the size, in bytes, of the buffer (array) used to insert the data
compress	N	When “Y”, export will mark the table to be loaded as one extent for the import utility.  If “N”, the current storage options defined for the table will be used.  Although this option is only implemented on import, it can only be specified on export.
consistent	N	Specifies the set transaction read only statement for export, ensuring data consistency.  This option should be set to “Y” if activity is anticipated while the exp command is executing.  If ‘Y’ is set, confirm that there is sufficient undo segment space to avoid the export session getting the ORA-1555 Snapshot too old error.
constraints	Y	Specifies whether table constraints should be exported with table data.
direct	N	Determines whether to use direct or conventional path export.  Direct path exports bypass the SQL command, thereby enhancing performance.
feedback	0	Determines how often feedback is displayed.  A value of feedback=n displays a dot for every n rows processed.  The display shows all tables exported not individual ones.
file		The name of the export file. Multiple files can be listed, separated by commas.  When export fills thefilesize, it will begin writing to the next file in the list.
filesize		The maximum file size, specified in bytes.
flashback_scn		The system change number (SCN) that export uses to enable flashback.
flashback_time		Export will discover the SCN that is closest to the specified time.  This SCN is used to enable flashback.
full		The entire database is exported.
grants	Y	Specifies object grants to export.
help		Shows command line options for export.
indexes	Y	Determines whether index definitions are exported.  The index data is never exported.
log		The filename used by export to write messages.
object_consistent	N	Specifies whether export uses SET TRANSACTION READ ONLY to ensure that the data being exported is consistent.
owner		Only the owner’s objects will be exported.
parfile		The name of the file that contains the export parameter options.  This file can be used instead of specifying all the options on the command line for each export.
query		Allows a subset of rows from a table to be exported, based on a SQL where clause.
recordlength		Specifies the length of the file record in bytes.  This parameter affects the amount of data that accumulates before it is written to disk.  If not specified, this parameter defaults to the value specific to that platform.  The highest value is 64KB.
resumable	N	Enables and disables resumable space allocation.  When “Y”, the parameters resumable_name andresumable_timeout are utilized.
resumable_name		User defined string that helps identify a resumable statement that has been suspended.  This parameter is ignored unless resumable = Y.
resumable_timeout	2h	The time period in which an export error must be fixed.  This parameter is ignored unless resumable = Y.
rows	Y	Indicates whether or not the table rows should be exported.
statistics	ESTIMATE	Indicates the level of statistics generated when the data is imported.  Other options include COMPUTE and NONE.
tables		Indicates that the type of export is table-mode and lists the tables to be exported.  Table partitions and sub partitions can also be specified.
tablespaces		Indicates that the type of export is tablespace-mode, in which all tables assigned to the listed tablespaces will be exported.  This option requires the EXP_FULL_DATABASE role.
transport_tablespace	N	Enables the export of metadata needed for transportable tablespaces.
triggers	Y	Indicates whether triggers defined on export tables will also be exported.
tts_full_check	FALSE	When TRUE, export will verify that when creating a transportable tablespace, a consistent set of objects is exported.
userid		Specifies the userid/password of the user performing the export.
volsize		Specifies the maximum number of bytes in an export file on each tape volume.

Example: exp system/s              file=C:\emp.dmp tables=scott.emp log=C:\emp.log   (Windows)

      or      exp userid=system/s file=C:\emp.dmp tables=scott.emp log=C:\emp.log   (Windows)

USERID must be the first parameter on the command line.

11.  Which are the IMP options ?

IMP Option	Default value	Description
buffer		Specifies the size, in bytes, of the buffer (array) used to insert the data
commit	N	Specifies whether import should commit after each array insert. By default, import commits after each table is loaded, however, this use a lot of the rollback segments or undo space for huge tables.
compile	Y	Tells import to compile procedural objects when they are imported.
constraints	Y	Specifies whether table constraints should also be imported with table data.
datafiles (only with transport_tablespace)		This parameter lists data files to be transported to the database.
destroy	N	Overwrite tablespace data file
feedback	0	Determines how often feedback is displayed. A value of feedback=100 displays a dot for every 100 rows processed. This option applies to the total tables imported, not individual ones. Another way to measure the number of rows that have been processed is to execute the following query while the import is active: SELECT rows_processed    FROM v$sqlarea    WHERE sql_text like 'INSERT %INTO "%'        AND command_type = 2        AND open_versions > 0;
file		The name of the export file to import. Multiple files can be listed, separated by commas. When export reaches the filesize it will begin writing to the next file in the list.
filesize		Maximum size of each dump file
fromuser		A comma delimited list of schemas from which to import. If the export file contains many users or even the entire database, the fromuser option enables only a subset of those objects (and data) to be imported.
full		The entire export file is imported.
grants	Y	Specifies to import object grants.
help		Shows command line options for importimp -help   or   imp help=y
ignore	N	Specifies how object creation errors should be handled. If a table already exists and ignore=y, then the rows are imported to the existing tables, otherwise errors will be reported and no rows are loaded into the table.
indexes	Y	Determines whether indexes are imported.
indexfile		Specifies a filename that contains index creation statements. This file can be used to build the indexes after the import has completed.
log		The filename used by import to write messages.
parfile		The name of the file that contains the import parameter options. This file can be used instead of specifying all the options on the command line.
recordlength		Specifies the length of the file record in bytes. This parameter is only used when transferring export files between operating systems that use different default values.
resumable	N	When “Y”, the parameters resumable_name and resumable_timeout are utilized.
resumable_name		User defined string that helps identify a resumable statement that has been suspended. This parameter is ignored unless resumable = Y.
resumable_timeout	2h	The time period in which an error must be fixed. This parameter is ignored unless resumable=Y.
rows	Y	Indicates whether or not the table rows should be imported.
show	N	When show=y, the DDL within the export file is displayed.
skip_unusable_indexes	N	Determines whether import skips the building of indexes that are in an unusable state.
statistics	ALWAYS	Determines the level of optimizer statistics that are generated on import. The options include ALWAYS, NONE, SAFE and RECALCULATE. ALWAYS imports statistics regardless of their validity. NONE does not import or recalculate any optimizer statistics. SAFE will import the statistics if they appear to be valid, otherwise they will be recomputed after import. RECALCULATE always generates new statistics after import.
streams_configuration	Y	Determines whether or not any streams metadata present in the export file will be imported.
streams_instantiation	N	Specifies whether or not to import streams instantiation metadata present in the export file
tables		Indicates that the type of export is table-mode and lists the tables to be exported. Table partitions and sub partitions can also be specified.
tablespaces		When transport_tablespace=y, this parameter provides a list of tablespaces.
to_user		Specifies a list of user schemas that will be targets for imports.
transport_tablespace	N	When Y, transportable tablespace metadata will be imported from the export file.
tts_owners		When transport_tablespace=Y, this parameter lists the users who own the data in the transportable tablespace set.
userid		Specifies the userid/password of the user performing the import.

Example:  imp system/manager file=/APPS/x.dmp tables=x fromuser=cs touser=cs     (Unix)

   or          imp userid=system/manager file=/APPS/x.dmp tables=x fromuser=cs touser=cs   (Unix)

Note: USERID must be the first parameter on the command line.

12. Which are the common IMP/EXP problems?

• ORA-00001: Unique constraint ... violated - Perhaps you are importing duplicate rows. Use IGNORE=N to skip tables that already exist (imp will give an error if the object is re-created) or the table could be dropped/ truncated and re-imported if we need to do a table refresh..
• IMP-00015: Statement failed ... object already exists... - Use the IGNORE=Y import parameter to ignore these errors, but be careful as you might end up with duplicate rows.
• ORA-01555: Snapshot too old - Ask your users to STOP working while you are exporting or use parameter CONSISTENT=NO (However this option could create possible referential problems, because the tables are not exported from one snapshot in time).
• ORA-01562: Failed to extend rollback segment - Create bigger rollback segments or set parameter COMMIT=Y (with an appropriate BUFFER parameter ) while importing.

Difference between Rollback & Undo Segments

Till Oracle 8i the undo that was generated, used to be handled by the Rollback tablespace, which was dictionary managed. In this case we have to first create a Rollback tablespace, then (according to our needs) create rollback segments and assign it to the rollback tablespace.

Now, from Oracle 9i the new concept of undo tablespace is introduced, which helps the DBAs in the following ways:

1) It is locally managed.
2) The undo segments are created by oracle itself ( whereas in the case of rollback segments we create it).
3) The number of undo segments are generated by oracle itself.

The purpose of undo segment and rollback segment is the same except the creation and maintenance part. Both will do the same functionality,but in oracle 9i they made it simplify, because if rollback segments are used, we need to put them online in init.ora and needs to take care space management etc.

So in oracle 9i they introduced undo tablespaces on that we can create undo segments and space management will be take care by oracle managed files ,so its reduces the burden of DBA.

Security - Managing Audit Trails

Relocate the audit trail to a different tablespace and set up an automatic purge process to keep its size under control.

One of the most significant aspects of database security involves setting up auditing to record user activities. The very knowledge that a user’s actions are being recorded can act as a significant deterrent to prevent wrongdoers from committing malicious acts.

When auditing is enabled, the audit output is recorded in an audit trail, which is usually stored in the database in a table under the SYS schema called AUD$. It can also reside as files in the file system, and the files can optionally be stored in XML format. For more-precise control, the Fine Grained Auditing feature of Oracle Database 11g provides granular control of what to audit, based on a more detailed set of policies. Fine Grained Auditing audits are usually stored in another table, FGA_LOG$, under the SYS schema.

These various audit trails can quickly grow out of control when database activity increases. As audit trails grow, two main challenges must be addressed: 

1. Trails need to be kept to a manageable size (and old records purged) if they are to be used effectively in forensic analysis.
2. Because database-resident trails are typically stored in the SYSTEM tablespace, they can potentially fill it up—bringing the database to a halt. 

Fortunately, the new auditing features in Oracle Database 11g Release 2 can help address these challenges. These capabilities, implemented in a package called DBMS_AUDIT_MGMT, enable you to move audit trails from the SYSTEM tablespace to one of your choice.

The new auditing features also let you set up one-time and automated purge processes for each of your audit trail types. Historically, to purge an audit trail, you were generally forced to stop auditing (which may have required bouncing the database), truncate, and then restart auditing (and bouncing the database again).

In this article, you will learn how to use the new features in Oracle Database 11g Release 2 to manage your audit trails. 

Relocating the Audit Trail Tables

Let’s first examine how to relocate an audit trail from the default SYSTEM tablespace to a new one. In case you don’t already have a suitable target tablespace, the code below shows how to create one: 

create tablespace audit_trail_ts
datafile '+DATA'
size 500M
segment space management auto
/
 

For moving an audit trail to the new tablespace, Oracle Database 11g Release 2 provides a procedure in DBMS_AUDIT_MGMT called SET_AUDIT_TRAIL_LOCATION. Listing 1 shows how to move a “standard” audit trail, which is the Oracle Database audit recorded in the AUD$ table.

Code Listing 1: Relocating a standard audit trail 

begin
 dbms_audit_mgmt.set_audit_trail_location(
  audit_trail_type            => dbms_audit_mgmt.audit_trail_aud_std,
  audit_trail_location_value  => 'AUDIT_TRAIL_TS');
end;
/
 

This move operation can be performed even when the database is up and an audit trail is being written. The target tablespace (AUDIT_TRAIL_TS in this case) must be available and online. If the tablespace is not available, auditing will stop, also stopping the database in the process. You should therefore be very careful about where you create the tablespace. The location should be permanent (and not on a temporary file system such as /tmp), and the underlying hardware should be resilient against failures (using RAID-1, for example).

The procedure can also be used for Fine Grained Auditing audit trails. To move a Fine Grained Auditing audit trail, simply replace the value of the audit_trail_type parameter in Listing 1 with dbms_audit_mgmt.audit_trail_fga_std. If you want to move both the standard and Fine Grained Auditing audit trails to the new tablespace, use the dbms_audit.audit_trail_db_std value as the audit_trail_type parameter. 

Purging Old Data

Next, let’s examine how to purge audit trails. The audit management package includes a procedure that automatically performs the purge for you. But before you can actually use it, you must call a one-time initialization procedure—INIT_CLEANUP—to set up the audit management infrastructure. Listing 2 shows how to perform the initialization. 

Code Listing 2: Initializing cleanup of audit entries 

begin
  dbms_audit_mgmt.init_cleanup(
    audit_trail_type            => dbms_audit_mgmt.audit_trail_db_std,
    default_cleanup_interval    => 24 );
end;
 

The INIT_CLEANUP procedure takes two parameters, neither of which takes a default value: 

• audit_trail_type—designates the type of audit trail being initialized. For instance, audit_trail_aud_std indicates the standard database audit trail (the AUD$ table). Table 1 lists the possible values for this parameter and the audit trail types they represent.
• default_cleanup_interval—designates the default interval in hours between executions of automatic purge jobs (to be discussed later in this article).

Parameter	Description
audit_trail_aud_std	The standard AUD$ audit trail in the database
audit_trail_fga_std	The FGA_LOG$ table, for Fine Grained Auditing
audit_trail_db_std	Both standard and FGA audit trails
audit_trail_os	The OS audit trail
audit_trail_xml	The XML audit trail
audit_trail_files	Both OS and XML audit trails
audit_trail_all	All of the above

 Table 1: Types of audit trails for audit_trail_type

In addition to setting the default cleanup frequency, the INIT_CLEANUP procedure moves the audit trail out of the SYSTEM tablespace. If the FGA_LOG$ and AUD$ tables are in the SYSTEM tablespace, the procedure will move them to the SYSAUX tablespace. Needless to say, you should ensure that the SYSAUX tablespace has sufficient space to hold both of these tables. The process of moving data from one tablespace to the other can have an impact on performance, so you should avoid calling the procedure during peak hours.

If you have already relocated these two tables to another tablespace (as described in the previous section), they will stay in the new location and the procedure will execute much more quickly.

After calling the initialization procedure, you can perform the actual audit trail cleanup, but you likely wouldn’t just remove an audit trail blindly. In most cases, you would archive the trail first before performing a permanent purge. When doing so, you can call another procedure—SET_LAST_ARCHIVE_TIMESTAMP—to let the purge process know the time stamp up to which an audit trail has been archived. This procedure accepts three parameters: 

• audit_trail_type—the type of audit trail you are about to purge.
• last_archive_time—the last time the audit trail was archived for this type.
• rac_instance_number—with an Oracle Real Application Clusters (Oracle RAC) database, OS audit trail files exist on more than one server. It’s possible to archive these files at different times, so this parameter tells the purge process the archive time of each node (or instance number) of the cluster. This parameter is applicable to Oracle RAC databases only; it has no significance for single-instance databases. Furthermore, this parameter is irrelevant for database audit trails, because they are common to all Oracle RAC instances. 

After you set the archive time stamp, you can check its value from a data dictionary view, DBA_AUDIT_MGMT_LAST_ARCH_TS. Listing 3 shows how to set the cutoff time stamp to September 30, 2009 at 10 a.m. and subsequently check its value from the view.

Code Listing 3: Setting the last archived time 

begin
   dbms_audit_mgmt.set_last_archive_timestamp(
     audit_trail_type  => dbms_audit_mgmt.audit_trail_aud_std,
     last_archive_time => 
        to_timestamp('2009-09-30 10:00:00','YYYY-MM-DD HH24:MI:SS'),
     rac_instance_number  => null
   );
end;
/

SQL> select * from DBA_AUDIT_MGMT_LAST_ARCH_TS;

AUDIT_TRAIL           RAC_INSTANCE
——————————————————————————————————
LAST_ARCHIVE_TS
——————————————————————————————————
STANDARD AUDIT TRAIL  0
30-SEP-09 10.00.00.000000 AM +00:00
 

Now you can execute the purge. To do so, run the code shown in Listing 4. The CLEAN_AUDIT_TRAIL procedure in the listing accepts two parameters. The first one is audit_trail_type. The second parameter—use_last_arch_timestamp—specifies whether the purge should be performed, depending on the last archive time stamp. If the parameter is set to TRUE (the default), the purge will delete the records generated before the time stamp (September 30, 2009 at 10 a.m. in this case). If it is set to FALSE, all audit trail records will be deleted.

Code Listing 4: Purging a standard database audit trail 

begin
  dbms_audit_mgmt.clean_audit_trail(
   audit_trail_type        =>  dbms_audit_mgmt.audit_trail_aud_std,
   use_last_arch_timestamp => TRUE
  );
end;
/
 

This same procedure is also used to purge file-based audit trails such as OS file audit trails and XML trails. To purge those trails, just specify the appropriate value for the audit_trail_type parameter (as shown in Table 1). However, note that for file-based audit trails, only the files in the current audit directory (as specified by the audit_file_dest initialization parameter) will be deleted. If you have audit trail files in a different directory from the one specified in audit_file_dest, those files will not be deleted.

Note that in Microsoft Windows, audit trails are entries in Windows Event Viewer and not actual OS files. So purging OS-based audit trails on that platform will not delete the trails. 

Setting Up Automatic Purge

The foregoing process is good for a one-time purge of audit trails. To ensure that audit trails do not overwhelm their tablespace, you may want to institute an automatic purge mechanism. The DBMS_AUDIT_MGMT package has another procedure—CREATE_PURGE_JOB—to do just that. This procedure takes four parameters: 

• audit_trail_type—the type of the audit trail
• audit_trail_purge_interval—the duration, in hours, between executions of the purge process
• audit_trail_purge_name—the name you assign to this job
• use_last_arch_timestamp—an indication of whether the job should delete audit trail records marked as archived. The default is TRUE. If the parameter is set to FALSE, the procedure will delete the entire trail. 

Listing 5 shows how to create a purge job that deletes standard audit trail records every 24 hours. As with one-time purges, you can create different jobs for each type of trail—such as standard, Fine Grained Auditing, OS files, and XML—simply by specifying different values for audit_trail_type when calling CREATE_PURGE_JOB. You can even set different purge intervals for each audit trail type to suit your archival needs. For instance, you can use a simple database-link-based script to pull database audit trail records to a different database while using a third-party tool to pull the OS audit trails. The execution time of each approach may be different, causing the database records to be pulled every day while the OS files are being pulled every hour. As a result, you might schedule purge jobs with an interval of 24 hours for database-based trails and with an interval of one hour for OS-file-based trails.

Code Listing 5: Creating a purge job for a standard audit trail 

begin
   dbms_audit_mgmt.create_purge_job (
   audit_trail_type            => dbms_audit_mgmt.audit_trail_aud_std,
   audit_trail_purge_interval  => 24,
   audit_trail_purge_name      => 'std_audit_trail_purge_job',
   use_last_arch_timestamp     => TRUE
   );
end;
/
 

You can view information about automatic purge jobs by accessing the DBA_AUDIT_MGMT_CLEANUP_JOBS data dictionary view. It shows all the important attributes of the job, such as the name, the type of audit trail being cleaned, and the frequency. 

Setting Audit Trail Properties

Next Steps  READ more about  the audit management package database security

When setting up a purge job, you should always remember one very important fact. It performs a DELETE operation—not TRUNCATE—on database-based trails, so the purge operation generates redo and undo records, which may be quite significant, depending on the number of trail records deleted. A large deletion can potentially fill up the undo tablespace. To reduce the redo size of a transaction, the purge job deletes in batches of 1,000 and performs commits between them. If the database is very large, it may be able to handle much more redo easily. You can change the delete batch size by using the SET_AUDIT_TRAIL_PROPERTY procedure. Listing 6 shows how to set the delete batch size to 100,000. 

Code Listing 6: Setting the deletion batch size 

begin
 dbms_audit_mgmt.set_audit_trail_property(
  audit_trail_type            => dbms_audit_mgmt.audit_trail_aud_std,
  audit_trail_property        => dbms_audit_mgmt.db_delete_batch_size,
  audit_trail_property_value  => 100000);
end;
/
 

In addition to the db_delete_batch_size property referenced in Listing 6, you can use SET_AUDIT_TRAIL_PROPERTY to set several other important properties. They include the following: 

• file_delete_batch_size specifies how many OS audit trail files will be deleted by the purge job in one batch.
• cleanup_interval specifies the default interval, in hours, between executions of a purge job.
• os_file_max_age specifies how many days an OS file or an XML file can be left open before a new file is created.
• os_file_max_size specifies the maximum size of an audit trail file (in kilobytes). 

To find the current value of a property, you can check the data dictionary view DBA_AUDIT_MGMT_CONFIG_PARAMS. 

Conclusion

Audit trails establish accountability. In Oracle Database 11g, there are several types of audit trails—standard, fine-grained, OS-file-based, and XML. In this article, you learned how to relocate a database-based audit trail from its default tablespace—SYSTEM—to another one designated only for audit trails. You also learned how to purge audit trails of various types to keep them within a manageable limit, and you finished by establishing an automatic purge process.

Informatica PowerC Installation and Configuration Complete Gide

This article provides complete step by step instruction for installation and configuration of Informatica PowerCenter 9.x. This includes  the installation of server components, configuration of different Informatica services and client installation and configuration.

• Download Installation Pack.
• Unpack the Installation Package.
• Install Informatica PowerCenter Server.
• Domain Configure.
• Configure Repository Service.
• Configure Integration Service.
• Client Installation.

Download Installation Pack

Step : 1
Informatica PowerCenter trail version can be downloaded from https://edelivery.oracle.com
Log on to https://edelivery.oracle.com and accept the Terms and Conditions.

Step : 2
Choose the Product package as shown below and Click Continue.



Step : 3
Locate the download package as shown in below image.



Step : 4
Download the packages to D:\INFA9X

Unpack the Installation Package

Step : 1

Unzip all the the four downloaded zip files into D:\INFA9X. Hint : Use the program WinRAR to unzip all the files. After unzipping you will see below files and folders.

Step : 2

Unzip dac_win_101314_infa_win_32bit_910.zip into the the same folder D:\INFA9X. After unzipping you will see below files and folders.

Install Informatica PowerCenter Server

Step : 1
To locate install.exe, Navigate to D:\INFA9X\dac_win_101314_infa_win_32bit_910 as shown in below image. double click on the install.exe.

Step : 2
Installation wizard Starts.  Choose the installation type.
Click Next.



Step : 3
Installation Pre-requisites will be shown before the installation starts as below.
Click Next.



Step : 4

Enter the license key. You can locate the license key from D:\INFA9X\EXTRACT\Oracle_All_OS_Prod.key.

Click Next.



Step : 5

Pre-installation summery will give the items installed during the installation process based on the license key.

Click Next

Step : 6
Installation Begins. It takes couple of minutes to finish. Soon after completion of this step, Configuring Domain window opens. Continue the steps from Domain Configuration.

Domain Configuration.

Step : 1

• Choose “Create a Domain” radio button.
• Check “Enable HTTPS for Informatica Administrator”
• Leave the Port number as it is and choose “Use a keystore file generated by the installer”

Click Next.



Step : 2
Provide the Repository database details as below.

• Database Type : Choose your Repository database (Oracle/SQL Server/Sybase)
• Database user ID : Database user ID to connect database.
• User Password  : Password.
• Schema Name : If Schema name is not provided default schema will be used.
• Database Address and Port : Machine on which database in installed and default port number.
• Database Service Name :  Database Name.

Below image shows the configuration using SQL Server.
Click Next.



Step : 3
You can give the Domain details, Admin user details now.

• Domain Name : Name of your Domain.
• Node Host Name : Machine name on which Informatica Server is running.
• Node Name : Name of the Node.
• Node Port Number : Leave the default port Number.
• Domain user name : This is the Administrator user
• Domain password : Administrator password

Note : Remember your Admin User ID, Password to log on to Admin Console later in the installation.



Step : 4
Use the default configuration and Click Next.



Step : 5
Installation is complete and you get the post-installation summery. You get a link to the installation log file and a link to Admin console.
Click Done.

Configure Repository Service

Step : 1
Go to Start menu and Click on “Informatica Administrator Home Page”. This will open up the Admin Console in a web browser.



Step : 2
Log on to Admin console using your Admin User ID and Password. You set your Admin User ID and Password in “Domain Configuration” section Step 3

 

Step : 3
Once you Log on you will see the Screen just like shown below.



Step : 4
Choose your Domain Name from “Domain Navigator”, Click on “Actions”, Choose “New” and “PowerCenter Repository Service”.



Step : 5
A new screen will appear, Provide the details as shown below.

• Repository Name : Your Repository Name.
• Description :  An optional description about the repository.
• Location : Choose the Domain you have already created. If you have only one Domain, this value will be pre populated.
• License : Choose the license key from the drop down list.
• Node : Choose the node name from the drop down list.

Click Next.



Step : 6
A new screen will appear, Provide the Repository database details.

• Database Type : Choose your Repository database (Oracle/SQL Server/Sybase)
• Username : Database user ID to connect database.
• Password : Database user Password.
• Connection String : Database Connection String.
• Code Page : Database Code Page
• Table Space : Database Table Space Name
• Choose “No content exists under specified connection string. Create new content”

Click Finish



Step : 7
It takes couple of minutes create Repository content. After the repository creation below screen will be seen.



Step : 8
The repository service will be running in “Exclusive” mode as shown below. This needs to be change to “Normal” before we can configure Integration service.
Click “Edit” Repository Properties.



Step : 9
A pop up window appears, Set the properties

• Operation Mode : Normal
• Security Audit Trail : No

Click OK.

Click OK for the next two pop up windows which confirms the Repository Restart to change the Repository Operating Mode.

Configure Integration Service

Step : 1
Choose your Domain Name from “Domain Navigator”, Click on “Actions”, Choose “New” and “PowerCenter Integration Service”.



Step : 2
A new window will appear, Provide the details as shown below.

• Name : Your Integration Service Name.
• Description :  An optional description about the repository.
• Location : Choose the Domain you have already created. If you have only one Domain, this value will be pre populated.
• License : Choose the license key from the drop down list.
• Node : Choose the node name from the drop down list.

Click Next.



Step : 3
A new window will appear, Provide the details as shown below.

• PowerCenter Repository Service : Choose your Repository Service Name from the drop down list.
• Username :  Admin user name.
• Password : Admin password.
• Data Movement Mode : ASCII.

Click Finish.



Step : 4
A pop up window will appear, Choose the Code Page as ANSI.
Click OK.



Step : 5
Window will be closed and you can see all the configured services in the “Domain Navigator”



With that we are all done with the installation and configuration for Informatica PowerCenter Server.

Client Installation.

Step : 1
Go to D:\INFA9X  as shown in below image. Click on the install.bat.

Step : 2
Installation wizard Starts.
Click Start.



Step : 3
Installation wizard Starts.  Choose the installation type as in the below image.
Click Next.



Step : 4
Installation Pre-requisites will be shown before the installation starts as below.
Click Next.



Step : 5
Choose the client tools you need. Only PowerCenter  Client is mandatory.
Click Next.



Step : 6
Choose the client installation directory.
Click Next.


Step : 7
You can choose the type of Eclipse installation in this step. This window will be available if you choose to install “Informatica Developer” or “Data Transformation Studio”.
Click Next.



Step : 8
Pre-installation summery will give the items installed during the installation process.
Click Next.


Step : 9
Installation Begins. It takes one or two minutes to complete this step.



Step : 10
Installation is complete and you get the post-installation summery.



With that we are all done with the installation and configuration for Informatica PowerCenter Client.

Hope you enjoy this tutorial, Please let us know if you have any difficulties during your installation process, we will be more than happy to help you.