In this brief post we will see how RTD provides information about performances.
The RTD server logs all the statistical information related with performances in its server log directory and precisely in the following file: ds_perf.csv
This file is a tab-separeted values file, pretty unreadable if opened with a common text editor.
Fortunately RTD provides us a Ms Excel spreadsheet that is able to parse all the information contained in the csv file into a readable format.
Finally I am publishing my first article about Oracle Real Time Decisions.
It’s not a huge post, just a tip about how to perform a deployment in production environment following the best practice.
In fact, using Decision Studio is not the only way RTD provide us to deploy Inline Services within RTD.
Effectively, in a real situation, it’s common that the deployment phase it’s not a developer’s responsability; it’s more usual that the IT departement from the customer side is in charge of performing the deployment by following the guidelines provided by the developer.
So in most cases we don’t want the customer’s IT departement to access the Decision Studio, but it’s easier to give them a way to execute a script performs the deployment automatically.
In the last months I have been working for a customer with a huge ETL logic built with Informatica Power Center.
Many times I had to import/export the repository in different environments and I faced the following issue at least once: after an import action I have found a duplicated Integration Service entry. One Integration Service was working and the other one was invalid.
Googling around for the solution, I have found useful the following information.
As first action, try to truncate the repository log files by running the following command:
pmrep truncatelog -t all
If this doesn’t fix the problem, follow these steps:
1. Check the OPB_SERVER_INFO Informatica repository database schema table for any duplicated rows. If any, execute the following sql command:
DELETE FROM OPB_SERVER_INFO WHERE SERVER_ID = [ID]; COMMIT;
Where [ID] identifies the old Integration Service that has been duplicated.
2. In Workflow Manager, right click on the invalid Integration Service and then delete.
3. Restart the Informatica services.
In this brief post I will describe what looks to be one of the most common problems you may face while executing Informatica Power Center’s workflows.
I have got exactly this problem while working for a customer and it took me long to figure out the reason.
Usually an Informatica mapping that takes data from multiple sources starts with the usage of the Source Qualifier operator that does basically a join between the input tables (in the screenshot we qualify only one input table).
The join query could be user-defined or auto-generated.
While using a user-defined query we have to take care of the number of columns we specify in the select statement that must match the number of columns linked from the Source Definition to the Source Qualifier.
Whenever these numbers mismatch, we get an ORA-01007 at runtime, even if the query itself it’s syntactically and logically correct.
A typical scenario in which you might face this problem could be the following: someone updates a source table metadata definition by adding new columns and then updates the related ETL mapping to include the new columns in the ETL logic. Then asks you to import the new stuff in production.
If the workflow that execute the modified mapping has an overwritten SQL in the Source Qualifier definition and we forget to update it, we may face the problem as well, even if the number of columns specified in the select statement of the related mapping’ Source Qualifier matches the number of linked columns from the Source Definition.
Infact when an overridden SQL is used in the worflow, Informatica executes the overridden script instead of the one from the mapping. So if the worflow is part of a previous release of the software, it still has the old number of columns in the select statement that might not correspond to the numbers of the linked columns from the source definition.
1. Introduction
I want to introduce a new feature that has been added to PHP Analytics: the variables.
In PHP Analytics, variables are keywords that can be used in your queries by using the following syntax: $variable_name
2. Create a Variable
In order to use a variable, first we have to define it trough the administration panel; to define a variable we just have to specify it’s own name and a default value.
At the time of the query execution, every variable that has been previously defined in the administration tool, is replaced with the values passed trough a GET or a POST method; if none of them is used, a default value (specified at the variable definition phase) is used.
