I'm having some troubles with ODI logs.
I'm trying to get the logs from the Snp_session, using the session number from this:
select <%=odiRef.getSession("SESS_NO")%> from dual
Unfortunately, it's not always right, and actualy it get the wrong session number quite often, like 1 every 10 times.
Is it an expected behaviour, or is there another way to get the right session?
Edit:
Corrected mistyping error
Not sure why this is working at all… Last time I checked (ODI 11g) this syntax required extra = character (passing over output from ODI Substitution API directly). Can you try:
SELECT <%=odiRef.getSession("SESS_NO")%> FROM dual
?
Related
I've gotten to one of those places where I've been toying with something for a little while trying to figure out why its not working and figured I would ask here. I am currently in the middle of making adjustments to a batch process that involves creating an external table A used for staging and then transferring the data from that table over to Table B for further processing.
There's a step in the batch that was there before to load all that data and it goes like this:
INSERT INTO TABLE B SELECT * FROM TABLE A
Upon running this statement in batch and outside of it in Oracle Developer I get the following error:
Run query ORA-00932: inconsistent datatypes: expected DATE got NUMBER
I went through my adjustments line by line and made sure I had the right data types. I also went over the data itself the best I could and from what I can tell it seems normal also. In an effort to find which individual field could have been having the error, I attempted to load data from Table A to Table B one column at a time...Doing this I received no errors which shocked me somewhat. If I use the SQL below and have all the fields listed out individually, the load of all the data works flawlessly. Can someone explain why this might be? Does the below function perform an internal Oracle working that the previous one does not?
insert into TABLE B (
COLUMN_ONE,
COLUMN_TWO,
COLUMN_THREE
.
.
.)
select
COLUMN_ONE,
COLUMN_TWO,
COLUMN_THREE
.
.
.
from TABLE A;
Well, if you posted description of tables A and B, we could see it ourselves. As it is now, we have to trust what you're saying, i.e. that everything matches (but Oracle disagrees), so I don't know what to say.
On the other hand, I've learnt that using
INSERT INTO TABLE B SELECT * FROM TABLE A
is a poor way of handling things (unless that's a quick & dirty testing). I try to always name all columns I'm working with, no matter how many of them are involved in that very operation. As you noticed, that seems to be working well for you too, so I'd suggest you to keep doing it.
I am a developer with SQL Server experience. We have one legacy application which uses SQR and Oracle to perform a weekly duplicate record search. We got an error while performing this search after 14 years. It says 'ORA-01438: value larger than specified precision allows for this column'. When I googled that error, I found out that it is related to a numeric field and the value passed is larger than it can hold. I can increase the size but don't know for which one. Since no one supports Oracle here, I am trying to trouble shoot this error and found people using
alter system set events='1438 trace name Errorstack forever,level 10';
I would like to know if this is the right way to find out which sql is failing?
Also what does it alter and what is level 10? Anything that I should consider before running this query in production? Is there something I need to roll back after performing this query? I was told that if I do SQL> insert into test values (100000000000000000,'test','test'); where 10000000000000000 is invalid then it will throw generic Oracle message ORA-01438. But in the trace file, it would show ORA-01438: value larger than specified precision allowed for this column. So, where would the trace file be generated?
Current SQL statement for this session:
insert into test values (100000000000000000,'test','test').
Please let me know if I am not in the right path.
Use DBMS_MONITOR to enabling trace for the session affected. This will contain all SQL and errors and bind variables, if you enable it.
Situation is following:
I have identified sql injection attack vector, and have following information about target table:
It has six columns. (Identified using "order by").
I can see output of 3 of them (table is displayed). two seems kind of enum value (integer in database?), and one is a date. I have very strong suspicion that col #6 is date column.
I'm almost sure the database is oracle. (ROWNUM works and LIMIT gives error).
I don't have error messages (always generic text is returned - "something went wrong").
Frontend is PHP if that matters. But there might be middle layer between it and database (e.g. java service), so I'm not sure where the query is being constructed.
E.g. following search query works as expected:
test' AND ROWNUM <= 5 ORDER BY 6--
EDIT-FROM-HERE:
Ok after help from comments, following query works:
test' UNION ALL SELECT null,null,null,null,null,null FROM dual--
(I was missing FROM dual part. Thank you #kordirko very much!)
This query adds one empty record in the output table (it is visually visible), so I'm definitely on the right track!
Now following line also works:
test' UNION ALL SELECT null,null,null,n't',null,null FROM dual--
I correctly identified 4th column and now it displays uppercase(?) letter T where I expected it to appear. So far so good. But it gives error when I input any string longer than 1 char! So following gives an error:
test' UNION ALL SELECT null,null,null,n'test',null,null FROM dual--
I'm no expert in SQL injection, and especially ORACLE (though have experience with MsSql).
I think the problem is something unicode-ansi-whateverencoding-related. For other rows (selected by original query before my UNION ALL SELECT addition) the 4th column gives multi-character normal strings. But when I try to inject desired string, it only works if it's one character, and also misteriously displays it in uppercase. I think this must be some encoding problem. I just discovered I needed n prefix for unicode string after 1 hour of searching and struggling. Maybe some Oracle gurus can quickly spot what mistake do I have in my query?
I have a query that is longer than 8000 in length I tried to execute it following way but it wouldn't. I used this link for help.
Declare #query1 As varchar(8000)
Declare #query2 As varchar(8000)
SELECT TOP 1000 *
FROM OPENQUERY(OPTIMA,#query1+#query2)
The Error:
Msg 102, Level 15, State 1, Line 74
Incorrect syntax near '#query1'.
I am not allowed to create view or stored procedure in remote server.
OPENQUERY() has a builtin limitation of 8KB on your #query, you also are not allowed to use variables for the inputs (in attempt to circumvent the 8KB limit).
I will still recommend creating a stored proc on your target server and calling it with OPENQUERY() that way.
Reference: http://msdn.microsoft.com/en-us/library/ms188427.aspx
Make a new view to the Oracle DB of the your query so you can decrease query length.
I had the same problem a couple of days ago, basically i was using 'UNION ALL' to union multiple queries inside the openquery.
My solution to this was to union on the local server instead of the remote server, it didn't increase the number of rows being pulled thought the wire because i was using union all anyway, it just forced me to use multiple openquery statements instead of a single one.
It did the job (since I'm not authorized to do anything on the remote server).
If you can, both hkf and Jokke Heikkilä have the correct answers, just do an sp or view on the remote server.
I have a weird problem right now that if a ref cursor returned from a stored procedure that has only 1 record in it, the fetch operation will hang and freeze. The stored procedure execution was really fast, just the fetching process hangs. If the ref cursor has more than 1 record, then everything is fine. Does anyone have similar issues before?
The Oracle server is 11g running on Linus. The client is Windows Server 2003. I'm testing this using the generic Oracle sqlplus tool on the Windows Server.
Any help and comments would be greatly appreciated. thanks.
When you say hangs, what do you mean ?
If the session is still active in the database (status in V$SESSION), then it is probably waiting on some event (eg SQL*Net from client means it is waiting for the client to do something).
It may be that the query is taking a long time to find that there aren't any more rows. Consider a table of 10,000,000 rows with no indexes. The query may full scan the table and find the first row matches the criteria. It still has to scan the next 9,999,999 rows to find that they don't. That can take a while.
Since you are saying that the process hangs, Is there a chance that your cursor does a "select for Update" instead of "Select " ? Since you are saying that the fetch of multiple records does not cause this error, that might not be the case.
Can you show us the code (or a reproducible small test/sample) for your select and the fetch.
Also, you can check the v$locked_objects using the following query and giving in your table name(s) to see if the object in question is being locked. Again, unless your current query has "for update" this fetch should not hang.
select do.*
from v$locked_objects vo,
dba_objects do
where vo.object_id = do.object_id
and vo.object_name = '<your_table_name>'