SQL Loader mystery, OWB 9.0.4

Can someone please explain this to me? In my generated control file (from OWB 904) I get the following lines:
INFILE '{{LOC_SOURCE_FILES.RootPath}}DXMTFIL.435' "STR X'0A'"
BADFILE '{{LOC_SOURCE_FILES.RootPath}}com_com_mt_stg.bad'
INTO TABLE "{{LOCATION_DW04AX.Schema}}"."COM_ITEM_TYPE"
Why does it display RootPath and Schema instead of the locations that have been registered??? Is this interpreted correctly by the OWB if you execute from deployment manager? I cannot get my mapping to execute properly and wonder if this is the problem.
Thanks in advance,
Carey

Carey,
Warehouse Builder resolves the physical details of the mapping when it runs the script. I.e. the values within the curly brackets get resolved at runtime. Have you deployed the script before you try to execute the mapping?
Also, the flat file location has to have been registered with the folder separator at the end (i.e. on Windows: backslash). Check out the runtime audit browser for any problems.
Thanks,
Mark.

Similar Messages

Add "Trailing Nullcolls" to sql loader control files generated by OWB

Hi gurus,
I've got a problem loading data with SQL Loader. I need to add the parameter "trailing nullcols" into the SQL Loader control file generated by OWB. I don't want to do this by saving the skript on my hard disk and run it manually, so any ideas where I can put this parameter? I am using OWB 10.1 on a windows 2000 machine.
Thanks
Stephan

Hi,
I found the solution to problem.
1; Select the mapping where you map your source flat file to a table.
2; Right click on the mapping and select "configure"
3; Go Sources and Targets -> YOUR_TABLE_NAME -> SQL*Loader Parameters
4; Set Trailing Nullcols = true :-)
Thank you to anyone looking at this problem.
Greetings
Stephan

Importing already-made SQL*Loader control files in OWB 10g

Hi all,
Suppose that I have a certain amount of already hand-made SQL*Loader control files, say 50 or so.
Each of these control files have a variable quantity of fields.
I feel really lazy, so I would like to know if it is possible to import directly these control files instead of re-typing them in the design center. That would save me a lot of time.
Thanks !
Burgy

Hi Burgy
One option is to use the sqlloader option to generate an external table from the SQLLoader control file (search for generate_only in the sqlloader documentation). If you define the external table in the database you can reverse engineer this into OWB.
Cheers
David

OWB 10gR2 : How to configure ctl and log locations for Sql*Loader mappings?

Hi all,
I'm using OWB 10gR2 to load data in tables with Sql*Loader mappings.
In my project I have a datafile module and an Oracle module.
When creating an sql*loader mapping in the oracle module, there is two properties for this mappings that I want to modify. The first is Control File Location and the second is Log File Location. Values for those properties are equal to the data file module location. When trying to change those values I can only chose "Use module configuration location".
Somebody knows how to configure those properties with different locations as the one of the flat file module?
What I want to do is to store the data file in one directory, and control file and log file in other directories.
Thank you for your help.
Bernard

Hi,
You're right, my problem is that the dropdown only show the location associated with the flat file location even if I have other file locations created in the design repository.
The good news is that I have found the solution to solve the problem :
1) Edit the file module and in tab "Data locations", add the locations you want to use for control file and log file.
2) Open configuration window of the mapping and then the dropdown for properties Control File Location and Log File Location show new locations
I have tested my mapping after changing those properties and it's working.
Bernard

Loading pl/sql scripts into OWB and running it

Hi,
Does anyone have an example for loading and executing PL/SQL Scripts in OWB?.
Thanks
Mehdi

Hi Mehdi,
Can you be more specific about what you want to achieve?
Do you mean running a package that OWB generated as a mapping?
Or running some external code?
Please check the User Guide, especially chapters 6 (Creating Mappings), 9 (Using Oracle Warehouse Builder Transformations) and 11 (Deploying to Target Schemas and Executing ETL Logic).
Good luck, Patrick

OWB or SQL Loader?

Is there some way to create a SQL loader control file using the OWB tool?

Yes, OWB creates all of the ETL process, including sqlloader scripts, temporary tables, transformation. But the answer is pretty long. Creating sqlloader scripts is just one out of many functions OWB performs.
As previously stated, your thread will not have too much echo here as this is an RDBMS specialized forum. By the way, I suggest you to narrow the scope of your question, as the answer, even in the proper forum would be too wide too.

SQL Loader error number 1 in OWB 9.0.4

I'm trying to execute a flat-file to database table mapping (using SQL*Loader), having set up my locations & connectors. When I execute the mapping, I get the following message:
Starting Execution COM_COM_MT_STG
Starting Task COM_COM_MT_STG
RPE-1013-SQL_LOADER_ERROR SQL Loader reported error condition, number 1.
Completing Task COM_COM_MT_STG
Completing Execution COM_COM_MT_STG
What does that mean and how do I fix it?
Also, is there any detailed documentation on building such a mapping, that can take you through all the steps, from creating the flat file module to deployment?
Thanks,
Carey

Carey,
Use the runtime audit browser to access the error log. It will show you what went wrong. You may have to re-register your flat file location with a folder separator at the end... This is a bug.
Thanks,
Mark.

OWB 9.0.4 :SQL*Loader: Operator POSTMAPPING does not support

Hi,
While trying to poulate Analytical Workspace using WB_LOAD_OLAP_CUBE, I got the following validation error
The analysis of the mapping is not successful under all supported languages and operating modes. Detail is as follows:
SQL*Loader: Operator POSTMAPPING does not support SQL*Loader generation.
ABAP: Operator AWPARAMS does not support ABAP generation.
I dont know what that means. Your help will be appreciated. Do I need apply some post 9.2.0.3 patch?. If yes, please let me know the patch number if available.
FYI: I am using Oracle9i with 9.2.0.3 patch
Thanks
Panneer

Panneer,
Does the regular process load from a flat file into a table? This would be implemented as SQL loader mapping... in which case a PL/SQL call cannot be implemented.
What you could do:
- Use an external table to read from the flat file.
- Use the transformation in a process flow. I.e. you first execute the SQL loader mapping and then execute the transformation.
Mark.

SQL*Loader does not recognise the \ in directory

Hi there,
We have version OWB 9.2.0.2.8 and I am trying to run SQL*Loader. I have tried to use an external table and also got "cannot find file" which I suspect could be the same problem. I then tried to load the data with SQL*Loader and saw that the directory specification of the source data file has "mysteriously" lost the \'s.
Below is a copy of the .log file with data file specified incorrectly. It should be u:\bi\data\ocean_shipment.csv. Any ideas?
Data File: u:biocean_shipment.csv
Bad File: /opt/oracle/product/OWB/9.2.0/owb/temp/u:biocean_shipment.bad
Discard File: none specified
(Allow all discards)
Number to load: ALL
Number to skip: 0
Errors allowed: 50
Bind array: 200 rows, maximum of 50000 bytes
Continuation: none specified
Path used: Conventional
Table "DWHSTG"."S_SHIPMENT_TYPES", loaded from every logical record.
Insert option in effect for this table: TRUNCATE
Column Name Position Len Term Encl Datatype
"SHIPMENT_CD" 1 * , O(") CHARACTER
"SHIPMENT_NAME" NEXT * , O(") CHARACTER
"LOAD_DATE" SYSDATE
SQL*Loader-500: Unable to open file (u:biocean_shipment.csv)
SQL*Loader-553: file not found
SQL*Loader-509: System error: No such file or directory
SQL*Loader-2026: the load was aborted because SQL Loader cannot continue.

Jean-Pierre,
That was the first thing I checked - even put it in (with \'s on the configuration parameters of the mapping). ALso unregistered and re-registered the location, ensured I put the slashes in, but to no avail. But I do belief there might be a bug outstanding for the location with directory separators - will check on metalink and let you know.

Dynamic flat file loading in OWB 11g

Hi,
I'm working on owb 11g, i need to load multiple files into tables having the same file name where only the date and file sequence number changes. The files are of format:
FileA_2009_1
FileA_2009_2
FileA_2009_3,etc....
How can i dynamically change the files and load to one table. Can this be achieved through external tables or sql* loader? Is there any such new feature in OWB 11g?
Rgds
Rex

Hi
SQLLoader mappings have the data filename as an optional input parameter (a fully qualified name can be passed). So you could have a loop to get the names and call the mapping. If it was External table you'd have to do an alter table to set the data file. If the filenames are static you can configure the ext table and mapping with the names.
Cheers
David

Change the mapping generation code from sql*loader to pl/sql

I want to use a mapping with a flat file operator to generate pl/sql code even if a mapping generate sql*loader code as default.
I tried to change the Language generation property of the mapping but an API8548 error message is shown. The suggested solution by OWB is to change the language generation code in the property inspector of the mapping.
I can't use external table because I have to work with a remote machine.
What i have to do to change the generation code from SQL*Loader to PL/SQL?

How about breaking this out into 2 mappings? In the first mapping, map a flat file operator to an table using SQL*Loader code. Then define a second mapping using the table as source and therefore generate PL/SQL. Then use process flow to launch the 2nd map to run after completion of first.

SQL Loader choosing conventional path when direct path is requested

We have a mystery regarding SQL Loader choosing to load with conventional path even though direct path is requested.
We have a control file that produces direct-path loads and one which does not. The difference between them does not seem to account for the difference in behavior.
The following control file does not give us direct-path:
OPTIONS (
     SKIP=0,
     ERRORS=0,
     DIRECT=TRUE,
     NOLOGGING
LOAD DATA
INFILE "[file path]" "STR x'0A'"
BADFILE "[file path].bad"
DISCARDFILE "[file path].dsc"
DISCARDMAX 0
INSERT
INTO [schema name].[table name]
FIELDS TERMINATED BY X'2C'
OPTIONALLY ENCLOSED BY '?'
TRAILING NULLCOLS
     C1_ACD_LINE_CD     CHAR(2000),
[column specifications continue]
)When running with this control file, the log shows:
Number to load: ALL
Number to skip: 0
Errors allowed: 0
Bind array:     64 rows, maximum of 256000 bytes
Continuation:    none specified
Path used:      Conventional
Table [schema name].[table name], loaded from every logical record.
Insert option in effect for this table: INSERT
TRAILING NULLCOLS option in effectIf we use a control file that is modified as follows:
OPTIONS (
     SKIP=0,
     ERRORS=0,
     DIRECT=TRUE,
     PARALLEL=TRUE,
     NOLOGGING
     )Then we do get direct-path load:
Number to load: ALL
Number to skip: 0
Errors allowed: 0
Continuation:    none specified
Path used:      Direct
Table [schema name].[table name], loaded from every logical record.
Insert option in effect for this table: INSERT
TRAILING NULLCOLS option in effectSo there is nothing about the table (constraints, triggers, etc.) that is preventing direct-path loads.
Now, we stumbled into this PARALLEL thing by accident - we are not really trying to do parallel loads.
In my reading of the Utilities guide (http://docs.oracle.com/cd/E11882_01/server.112/e22490/ldr_modes.htm#autoId64 ), the PARALLEL option lets SQL Loader tolerate multiple sessions loading to the same segment at once, but does not perform parallel processing itself. So, is it possible there is some other lock on the table is causing SQL Loader to block direct-path loads to the table (because of a previous SQL Loader direct-path load, perhaps) unless the PARALLEL option is invoked? If so, how do we recognize that state and how do we resolve it?
Version information:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE     11.2.0.3.0     Production
TNS for Solaris: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
Any thoughts or suggestions would be appreciated.
Thanks,
Mike

From the same link
>
To use a direct path load (except for parallel loads), SQL*Loader must have exclusive write access to the table and exclusive read/write access to any indexes.
>
So I suspect that when using only DIRECT=TRUE, Oracle is not able to get an exclusive lock on the required objects, so it uses the conventional mode.
From a later section
>
- Segments to be loaded do not have any active transactions pending.
To check for this condition, use the Oracle Enterprise Manager command MONITOR TABLE to find the object ID for the tables you want to load. Then use the command MONITOR LOCK to see if there are any locks on the tables.
>
Would be interested in knowing what you find
HTH
Srini

SQL*Loader-273: READBUFFERS may be used only in direct path.

Hi,
I am trying to upgrade from OWB 10G to 11G. y map from flat file to stage maps work fine in 10G. when i upgrade the maps to 11G i get the error:
Error
RPE-01013: SQL Loader reported error condition, number 1.
SQL*Loader: Release 11.1.0.7.0 - Production on Fri May 8 15:10:20 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL*Loader-273: READBUFFERS may be used only in direct path.
SQL*Loader: Release 11.1.0.7.0 - Production on Fri May 8 15:10:20 2009
Copyright (c) 1982, 2007, Oracle. All rights reserved.
SQL*Loader-273: READBUFFERS may be used only in direct path.
if i go to configure and make the READBUFFERS to = 0 then the map works fine. this used to work fine in 10G. I compared the .CTL file of sql loder and i notice the 10G sql loader file did not care for this property being set. while in 11G .ctl file i see the readbuffer property being set. though i can make the map run in 11G i can not go to each map and then reset it. ...Please help.
Thanks

IN 10 G environment
a.)Direct path = False.
b.) Read buffers = 4 (defaults to 4)
10G Code generated :
-- Oracle Warehouse Builder
-- Generator Version : 10.1.0.4.0
-- Created Date : Mon May 11 10:16:31 CDT 2009
-- Modified Date : Mon May 11 10:16:31 CDT 2009
-- Created By : owb_repository
-- Modified By : owb_repository
-- Generated Object Type : SQL*Loader Control File
-- Generated Object Name : GFHGF
-- © 2003 Oracle Corporation. All Rights Reserved.
OPTIONS ( ERRORS=50, BINDSIZE=50000, ROWS=200, READSIZE=65536)
LOAD DATA
CHARACTERSET WE8MSWIN1252
INFILE 'C:\EAND.dat'
INTO TABLE "{{ORACLE10G.Schema}}"."EAND"
APPEND
REENABLE DISABLED_CONSTRAINTS
FIELDS
"PERSON_SSN_SOURCE" POSITION (3:3) CHAR
IN 11 G environment
a.)Direct path = False.
b.) Read buffers = 4 (for new maps crated defaults to 0)
-- Generator Version : 11.1.0.7.0
-- Created Date : Mon May 11 10:06:37 CDT 2009
-- Modified Date : Mon May 11 10:06:37 CDT 2009
-- Created By : OWB_WUSER
-- Modified By : OWB_WUSER
-- Generated Object Type : SQL*Loader Control File
-- Generated Object Name : "GFHGF"
-- Copyright © 2000, 2007, Oracle. All rights reserved.
OPTIONS (BINDSIZE=50000,ERRORS=50,ROWS=200,READSIZE=65536)
LOAD DATA
CHARACTERSET WE8MSWIN1252
INFILE '{{ETL_FILE_LOC.RootPath}}{{}}EAND.dat''
BADFILE '{{ETL_FILE_LOC.RootPath}}{{}}EAND'
READBUFFERS 4
CONCATENATE 1
INTO TABLE "STAG"."EAND"
TRUNCATE
REENABLE DISABLED_CONSTRAINTS
"PERSON_SSN_SOURCE" POSITION (3:3) CHAR
my question is even as both the properties in 10G and 11G are same why does .ctl file generated in 11G has statement "READBUFFERS 4" while this is neglected in owb 10G generated .ctl file? Please Help.
Edited by: user591315 on May 11, 2009 8:14 AM
Edited by: user591315 on May 11, 2009 8:16 AM

Deploy sql loader mapping

Hi,
I have a problem with OWB when I try to start a mapping (sql loader) after deploy. The problem is that when I start the execution of the mapping, the control file of the sql loader is created not in Unix (where I have defined the location of both input file and control file) but in the pc with my OWB client. For this reason the execution fail because it doesn't find the input file (that i have put in the unix machine).
Is there a configuration for the client or for the server?
Thanks

I start the control center from my pc, but with the credential of the server unix (Host, port, username, password and service name).
Is it correct or must i start the control center from the unix machine?
Thanks for the replay.

Execute SQL*Loader mapping

Hi all,
I'm trying to execute a deployed OWB SQL*Loader mapping, using the oem_exec_template.sql script. I've got the following error:
Stage 1: Decoding Parameters
| location_name=ORA_LOC_DWH
| task_type=SQLLoader
| task_name=MAP_SA_AGGK_FEVO
Stage 2: Opening Task
declare
ERROR at line 1:
ORA-20001: Task not found - Please check the Task Type, Name and Location are
correct.
ORA-06512: at line 268
I can execute the mapping out of the OWB client and I'm also have no problems to execute a PLSQL mapping via that script.
Did anybody use this script for a SQL*Loader mapping before?
Regards Uwe

Hi Jean-Perre,
the names of the location and the mapping should be OK. Only the mapping STEP_TYPE seems to be different (UPPERCASE) to the one which is used inside of your script.
OMB+> OMBRETRIEVE ORACLE_MODULE 'ORA_DWH_SA' GET REF LOCATION
ORA_LOC_DWH
OMB+> OMBCC 'ORA_DWH_SA'
Context changed.
OMB+> OMBLIST MAPPINGS
MAP_SA_AGGK_FEVO MAP_SA_AGGK_KK_KONTO MAP_SA_AGGK_KK_KUNDE MAP_SA_BCV_YT
OMB+> OMBRETRIEVE MAPPING 'MAP_SA_AGGK_FEVO' GET PROPERTIES (STEP_TYPE)
SQLLOADER
The mapping is deployed, otherwise i couldn't execute the mapping out of the OWB client.
Regards Uwe

SQL Loader mystery, OWB 9.0.4

Similar Messages

Maybe you are looking for