I'm using the Jdbc input in LogStash to retrieve data from MS SQL database once in a minute.
Usually it works fine. But we know database performance is not very reliable thing and sometime it's takes longer than one minute to a query to return. Sometime event 5 minutes.
But the Jdbc scheduler still run a query once a minute so there situations when multiple queries run at the same time. This creates additional pressure on a database and after some time there are 20 almost same queries run at the same time.
I assume I'm not the first person which encounter this problem. I'm sure there is some way to make Jdbc to run next query a minute after the previous once is finished. Am I right?
I would like to know why I am getting different SCN number for the below quires
SELECT TIMESTAMP_TO_SCN(SYSDATE) FROM DUAL - I USE this for POINT IN TIME RECOVER FOR TABLESPACE .
SELECT CURRENT_SCN FROM V$DATABASE. - I use this for Database Recovery(RMAN)
WHY I AM GETTING TWO DIFFERENT SCN ?
I know the basic of SCN , but still I am confused .
Can anyone clarify what is the exact meaning of the query
timestamp_to_scn gives an approximate result. In any given second, a database is likely to go through thousands of SCNs so the result cannot be exact. And it would be terribly expensive to maintain a table that associated a timestamp with every SCN that the system had ever encountered. Under the covers, Oracle maintains a table that stores the current SCN every few seconds and keeps that data for a few days. In recent versions, the granularity of that table is 1 SCN every 3 seconds though that may change over time.
When you call timestamp_to_scn, therefore, you get an SCN that was created within a few seconds of the date you're interested in but it's never going to be exact and it's not going to work forever. That's generally close enough for a point in time recovery-- you know that you want to restore to May 20, 2015 at 12:05:00 am but you don't really care if you restore to a state a second or two earlier or later. If you're identifying a particular bad transaction that you want to restore the system to (or to just before), you wouldn't want to use timestamp_to_scn.
It not about 2 different queries , even if you try with any one of the query the SCN is different every time as it get generated every real time second.Even running of your query forces the database to create the new SCN evry time.Hence Every time you fires the query you get different SCN number of Database.
I wrote an application that queries oracle v$sqlarea and dumps data to my own database for further analysis. I noticed something very strange - sometimes data in the v$sqlarea shows less executions than before. I'm pretty sure that the oracle cache was not cleaned (the first load time of query is still the same, and since I query oracle each minute I dont believe that in this one minute the query was executed 100k+ times).
Can anybody explain how this is possible?
Ok, so I asked this on Oracle forum as well, and I believe that the correct answer is this one
https://community.oracle.com/message/12980175#12980175
I'm trying to run a query against an Oracle database. The first time I run it, it takes about 7 seconds. The second time I try to run it, it doesn't seem to ever actually complete. This is in both Oracle SQL developer and in the application I am developing (using JDBC Oracle Thin).
If I add a space to the query somewhere where I haven't done before, the query takes 7 seconds again.
I'm assuming this is because Oracle thinks it is a new query. Is there any way I can force Oracle to treat a query as one it hasn't seen before, even though it has?
I am working with Sybase 15 in my application and there is performance issue related with nested joins. I have stored procedure which selects 2 columns from 2 tables and compares equalities of over 10 columns between this 2 tables. But when I run this stor. proc., the result takes 40 minutes. I added "set merge-join off" statement to top of my proc then the result takes 22 seconds. but I need one more solution without that. I was using sybase 12.5 before and there was no any issue like that and my proc was take 3 mins for the result.
I have compared server configurations with sp_configure between 15 and 12.5 and sybase15 server configurations (I/O and memory configuration settings) are bigger than sybase12.5 server.
Info: sybase15 located pc's system resources are really good.
Same as the others, I have commiseration rather than a real answer! We are seeing a problem where the ASE 15 query planner massively underestimates the cost of a table scan and similarly overestimates the cost of using the clustered index. This results in a merge join being the suggested plan. Disabling merge joins or setting the allrows_oltp optgoal sometimes results in a better query plan. The estimated costs are still way off, but by taking one option off the table the query planner may find a good solution - albeit via the wrong analysis.
ASE 15 documents say that it has a much cleaner set of algorithms whereas the ASE 12 planner had a bunch of special cases. Perhaps a special case that says "if you have the clustered index column in the join it's going to be faster than a table scan" wouldn't be such a bad idea ... :(
I have just spent 14 hours at work debugging critical performance issues that arose from a Sybase 15 migration on the weekend.
The query optimiser has been making (for us) some very odd decisions.
Take an example,
select a, b, c from table1, table2, table3 where ...
versus
create table #temp (col1 int, col2 int, ... etc)
insert #temp
select a, b, c from table1, table2, table3 where ...
We had the first run in good time, and could not get it to make the correct decision in the 2nd instance, despite extensive reworking. We even took the query apart into temporary tables, but still got unusual results.
In the end we resorted to SET FORCEPLAN ON for some queries - this is after 10 hours of having our DBAs and Sybase on the line. The solution came from the application developers also rather than any advice from the Sybase engineers.
So to save yourself some time, take this route is my suggestion.
Sybase effectively rewrote the query engine for version 15 which means that queries that ran super-fast on 12.x may run much slower on the newer version, and vice versa. The only way to debug this is to compare the 12.x query plan to the 15 query plan and see what's being done differently.
Everyone concerned with this issue should read this doc:
http://www.sybase.com/files/White_Papers/ASE15-Optimizer-Best-Practices-v1-051209-wp.pdf
It has a candid warning about migrating from Sybase 12 to Sybase 15.
Quoteth:
... don't treat ASE 15 as "just
another release". As much as we would
like to say that you could simply
upgrade and point your applications at
the upgraded servers, the depth and
breadth of change in one of the most
fundamental areas of a database, query
execution, necessitates a more focused
testing regimen. This paper is meant
to provide you with the clear facts
and best practices to reduce this
effort as much as practically
possible.
It goes on to talk about the new ASE 15 Query Optimizer, vis-a-vis OLTP queries and DSS (Decision Support System) queries.
However, there's good news: in March 2009, Sybase 15.0.3 introduced a compatibility mode. See the following doc:
http://www.sybase.com/detail?id=1063556
With this mode, you need not analyze queries to decide if they fit OLTP or DSS profiles.