Did anything change in the window function. I see a query that ran yesterday looked as below
Today it looks as below
If you grab some QUERY_IDs for that query on recent runs, you can see the Snowflake version when they ran. You can run that for some recent ones to see if the version changed around the time you saw the change in behavior:
select RELEASE_VERSION from "SNOWFLAKE"."ACCOUNT_USAGE"."QUERY_HISTORY"
where QUERY_ID = '01920978-00b4-2a98-0000-00009d1d81f5';
Edit: I decided that it might be helpful to anyone reading this to have a general-purpose query to see their Snowflake version history:
select to_date(min(START_TIME)) as START_DATE,
to_date(max(START_TIME)) as END_DATE,
RELEASE_VERSION as SNOWFLAKE_VERSION
from "SNOWFLAKE"."ACCOUNT_USAGE"."QUERY_HISTORY"
group by RELEASE_VERSION
order by START_DATE desc;
Came to know this is because of a corruption in the query profile. have reported this issue and this is being worked upon
Related
So I am new in SQL DEVELOPER tools and I have written a simple select statement like:
SELECT * FROM employee;
it worked fine but there was a yellow warning mark underneath SELECT and I clicked on that and my query changes into the following query:
SELECT "A1"."EMPLOYEE_ID" "EMPLOYEE_ID","A1"."FIRST_NAME" "FIRST_NAME","A1"."LAST_NAME" "LAST_NAME","A1"."SALARY" "SALARY", "A1"."DEPARTMENT_ID" "DEPARTMENT_ID","A1"."MANAGER_ID" "MANAGER_ID","A1"."HIRE_DATE" "HIRE_DATE"
FROM "INTRO_USER"."EMPLOYEE" "A1";
My Quest is what is the difference between these two queries? although their output is the same
The glob * has been expanded to all column of the table. The table name EMPLOYEE is aliased to A1 to make it shorter.
The feature you are seeing is called 'SQL Text Expansion,' and it's setup to allow you to see what your query would look like if you were working with one or more VIEWS.
For example, SELECT * FROM ALL_TABLES is quite complicated. This feature allows you to see what's actually involved when running that SQL.
https://www.thatjeffsmith.com/archive/2014/12/sql-developer-and-a-12c-magic-trick/
There is probably no change or expected delta in the performance or execution plan of the 2 versions of your query.
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
?
CR XI Developer R2. Version 11.5.12.1838, talking to Oracle 11.2.0.3 64bit
A report is driven by an SQL Command. It is (necessarily) a complex report consisting of 7 separate SELECT statements UNION ALLed together. The report also starts with a CTE (or whatever they're called in Oracle)
WITH MYCTE AS (
SELECT x, y, z
FROM N)
SELECT ....
The SQL Command was edited thousands of times when under development. It was last changed six months ago.
Now when I edit the SQL Command, (Database Expert - Right click on Command - Edit Command - Close I am greeted by the 'Map Fields' screen
which is telling me that my query doesn't have any columns in it, and well, proceeding further is useless.
It turns out that if the first line of the report is anything other than SELECT ... then this condition occurs. My environment hasn't changed, this report used to work, and now doesn't.
And it's a general thing as well. From scratch I created a report fed by an SQL Command that was
SELECT * FROM DUAL
and it worked fine. Then I created another report fed by an SQL Command that was
/*This is perfectly valid SQL*/
SELECT * FROM DUAL
Result was that no fields were found. I tried again (expecting failure, I wasn't disappointed) with
WITH STUFF AS (
SELECT * FROM DUAL)
SELECT * FROM STUFF
Does anyone know what's going on? I wouldn't mind if SQL Commands didn't support CTEs, but they clearly do, because I managed to create / edit the existing report in the first place ....
Thanks in advance
Wow. It turns out it's a bug in the 11.2.0.3 Version of the oracle client installer. It OLEDb provider correctly. The fix is simply to run
C:\Windows\SysWOW64\regsvr32 <PathToYourOracleClientInstallFolder>\Client32bin\OraOLEDB11.dll
Actually found the answer at https://scn.sap.com/thread/3382251
I am facing a strange problem , when I connecting Oracle from SSIS and running below query it is not applying filter criteria
SELECT * FROM Table_Schema.Table_Name where trunc(Date_Column) >='01-APR-14'
but this is giving me data older than 01 April also. But when I am running same query in Oracle it is working absolutely fine.
What is wrong here?
Have you tried applying a format mask to the date you are passing in - you should always do this by default. You could substitute your date for sysdate (or getdate() in sqlserver) and see if it performs correctly. Also try removing the trunc.
Today, someone in my system has updated unexpected statement. So that makes my system run incorrect.
Now, I would like to see log who (or which session) did it. May I find it in AWR report ? And if I can find it in AWR report, where is it particularly ?
Thanks so much !
The change could be in many sources, depending on how it was made. Only the last option, Log Miner, will give you exactly everything you want. But it also requires the most effort. Some sources won't tell you the session, but maybe just seeing the relevant SQL will be enough to figure out who did it.
V$SQL - All SQL statements go in there, but they age out of the shared pool so you need to search quickly. If they used a unique query you may be able to find it with something like select * from v$sql where lower(sql_text) like '%table_name%';.
AWR - You may be able to find the SQL in select * from dba_hist_sqltext where lower(sql_text) like '%table_name%';, and then if you're lucky you can find out some session information from select * from dba_hist_active_sess_history where sql_id = '<sql id>';. Active Session History only samples activity, if the query ran very quickly there's a good chance it won't be in there.
Flashback query - If you're lucky the UNDO is still around and you can see exactly how it changed from a flashback query. This may give you the exact time, and what changed. select VERSIONS_STARTSCN, VERSIONS_STARTTIME, VERSIONS_ENDSCN, VERSIONS_ENDTIME, VERSIONS_XID, VERSIONS_OPERATION, your_table.* from your_table versions between scn minvalue and maxvalue;
Log Miner - I haven't used this, but supposedly it's the perfect tool for this job. Read more about it in the documentation.