ODI: Parameter für OdiStartLoadPlan

-

aus der Doku:

Usage

OdiStartLoadPlan -LOAD_PLAN_NAME=<load_plan_name> [-LOG_LEVEL=<log_level>]
[-CONTEXT=<context_code>] [-AGENT_URL=<agent_url>]
[-AGENT_CODE=<logical_agent_code>] [-ODI_USER=<ODI User>] 
[-ODI_PASS=<ODI Password>] [-KEYWORDS=<Keywords>]
[-<PROJECT_CODE>.<VARIABLE>=<var_value> ...] [-SYNC=<yes|no>] [-POLLINT=<msec>]

Parameters

Parameters Mandatory Description

-LOAD_PLAN_NAME=<load_plan_name>

Yes

Name of the load plan to start.

-LOG_LEVEL=<log_level>

No

Level of logging information to retain. All sessions with a defined log level lower than or equal to this value are kept in the session log when the session completes. However, if object execution ends abnormally, all tasks are kept, regardless of this setting.

Note that log level 6 has the same behavior as log level 5, but with the addition of variable and sequence tracking. See Tracking Variables and Sequences in Developing Integration Projects with Oracle Data Integrator for more information.

[-CONTEXT=<context_code>]

Yes

Code of the execution context. If this parameter is omitted, the load plan starts in the execution context of the calling session, if any.

[-AGENT_URL=<agent_url>]

No

URL of the remote agent that starts the load plan.

[-AGENT_CODE=<logical_agent_code>]

No

Code of the logical agent responsible for starting this load plan. If this parameter and -AGENT_URL are omitted, the current agent starts this load plan. This parameter is ignored if -AGENT_URL is specified.

[-ODI_USER=<ODI user>]

No

Oracle Data Integrator user to be used to start the load plan. The privileges of this user are used. If this parameter is omitted, the load plan is started with the privileges of the user launching the parent session.

[-ODI_PASS=<ODI Password>]

No

Password of the Oracle Data Integrator user. This password must be encoded. This parameter is required if -ODI_USER is specified.

-KEYWORDS=<keywords>

No

Comma-separated list of keywords attached to this load plan. These keywords make load plan execution identification easier.

-<VARIABLE>=<value>

No

List of project or global variables whose value is set as the default for the execution of the load plan. Project variables should be named <project_code>.<variable_name> and global variables should be named GLOBAL.<variable_name>. This list is of the form -<variable>=<value>.

-SYNC=<yes|no>

No

Specifies whether the load plan should be executed synchronously or asynchronously.

If set to Yes (synchronous mode), the load plan is started and runs to completion with a status of Done or Error before control is returned.

If set to No (asynchronous mode), the load plan is started and control is returned before the load plan runs to completion. The default value is No.

-POLLINT=<msec>

No

The time in milliseconds to wait between polling the load plan run status for completion state. The -SYNC parameter must be set to Yes. The default value is 1000 (1 second). The value must be greater than 0.

 

 

Quelle: https://docs.oracle.com/middleware/122126/odi/reference/GUID-49BACA0A-54F1-4D0C-92C8-21A762B9F6BF.htm#ODIRF199

 

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

trunc(sysdate) - nette Spiele mit dem Datum

-
Über die trunc-date Funktion läßt sich ausgehend von einem Datumswert sehr einfach ein abgeleiteter Datumswert ermittelt: bspw. der Jahres-, Quartals-, Monats- oder Wochenanfang. Die 11g Doku erläutert dies an zwei Stellen: http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions209.htm#SQLRF06151 bzw. http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/functions242.htm#sthref2718 So liefert select trunc(to_date('06.02.2011'),'q') from dual; das DATUM des Quartalsersten (im Bsp. den 01.01.2011). Wichtig ist, dass trunc immer ein Datum zurückliefert, keinen String. Einige Beispiele anhand des 20.Feb 2011 (ein Sonntag in der 07 KW in 2011): select trunc(to_date('20.02.2011'),'d') from dual; select trunc(to_date('20.02.2011'),'dd') from dual; select trunc(to_date('20.02.2011'),'ddd') from dual; select trunc(to_date('20.02.2011'),'mm') from dual; select trunc(to_date('20.02.2011...
Mehr anzeigen

Zufallszahlen und -text generieren - DBMS_RANDOM

-
Um für Testzwecke etc. "zufällige" Zahlen / Strings zu erzeugen, gibt es in Oracle die Funktion dbms_random . In Verbindung mit connect by kann so sehr einfach eine beliebige Menge an Zeilen mit Zufallswerten erzeugt werden: SELECT dbms_random.value(1,1000) Z       , dbms_random.string('a',20) Txt   FROM DUAL CONNECT BY level < 101; * DBMS_RANDOM.VALUE(low, high)   + low -> untere Grenze   + high -> obere Grenze * DBMS_RANDOM.STRING(opt, len)   + opt -> Definiert, was für ein String erzeugt wird   + len -> Länge des String   + Details zu opt: 'u', 'U' - returning string in uppercase alpha characters 'l', 'L' - returning string in lowercase alpha characters 'a', 'A...
Mehr anzeigen

Laufzeiten umrechnen, Sekundenangaben lesbar darstellen

-
Hintergrund: Laufzeiten von diversen Prozessen werden (Tool-)intern in Sekunden gemessen und meist auch so dargestellt. Für Weiterberechnungen und Auswertungen ist das Ideal. Der Lesbarkeit für den geneigten Nutzer nur bedingt dienlich. Wer erkennt schon auf den ersten Blick, wie lange 14.738sec sind? Lang halt. Lösungsansätze: Für die Lesbarkeit, kann man diese Werte natürlich entsprechend umrechnen. Aber wie? 14.738sec vermutlich am Besten in Stunden: 14.738/60/60 = 4,0939 Stunden -> Aha. Aber was ist mit 249sec? 249/60/60 = 0,069 Stunden - Wie lang bitte sind 0,069Std? 249sec also besser in Minuten umrechnen: 249/60 = 4,15 Min -> schon besser Also per CASE-Statement die unterschiedliche großen Sekundenangaben passend umrechnen? Nicht schön und umständlich. Netterweise bietet Oracle mit der to_date()-Funktion auch den Formatstring 'sssss' (5x kleines 's'). Per to_char( to_date(14768,'sssss') ,'HH24:MI:SS') werden aus den Sekunden ...
Mehr anzeigen