Same Query...Same DB Instance....Different results

Hi,
I'm running into an issue in which I'm seeing
inconsistent results. If I run a query against a
static table (fully committed) sometimes I receive
one result set and at other times I receive another
result set.This does not seem to be limited to a
particular table or query. The database has been
setup for a data warehouse for a client using the
following init params....
There have been bugs in 10g which have this effect - and I came across one quite recently. I wasn't aware of any that were still around in 10.2.0.4, though. Raise an SR with Oracle.
cursor_space_for_time=true
db_file_multiblock_read_count=32
db_writer_processes=[number of CPUs]
statistics_level=ALLProbably not relevant to your problem but these are all slightly suspect settings. You don't usually need to lock cursor frames in a data waarehouse - getting the right execution plan is usually more important than sharing existing cursors.
10gR2 the ideal is to reset db_file_multiblock_read_count and let the Oracle maximise the efficiency of multiblock reads by itself.
db_writers > 1 is rarely needed, and setting it to match the CPU_COUNT can be positively counter-productive (see http://kevinclosson.wordpress.com for further commentary).
Statistics_level = all enables rowsource execution statistics and can, depending on the cost of calling the system timer, be extremely CPU intensive. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for an example).
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." (Stephen Hawking)

Similar Messages

Execute the same query twice, get two different results

I have a query that returns two different results:
Oracle Version : 10.2.0.1.0
I am running the following query on the Oracle server in SQL*Plus Worksheet.
SELECT COUNT(*)
FROM AEJOURNAL_S1
WHERE CHAR_TIME BETWEEN TO_DATE('12-AUG-10 01:17:39 PM','DD-MON-YY HH:MI:SS AM') AND
TO_DATE('13-AUG-10 14:17:34','DD-MON-YY HH24:MI:SS')
AND DESC2 LIKE '%'
AND DESC1 LIKE '%'
AND DESC2 LIKE '%'
AND ETYPE LIKE '%'
AND MODULE LIKE '%'
AND LEVELL = '11-WARNING'
ORDER BY ORDD DESC;
The very first time the query is run, it will return a count of 259. The next time the query is run, lets say, 10 seconds later, it will return a count of 260. The above query is exemplary of the kind of thing I'm trying to do. It seems like the more fields filtered against '%', the more random the count return becomes. Sometime you have to execute the query three or four times before it levels out to a consistent number.
I'm using '%' as the default for various fields, because this was the easiest thing to do to support a data-driven Web interface. Maybe I have to 'dynamically' build the entire where clause, instead of just parameterizing the elements and having default '%'. Anyway, to eliminate the web interface for the purpose of troubleshooting the above query was run directly on the Oracle server.
This query runs against a view. The view does a transpose of data from a table.
Below is the view AEJOURNAL_S1
SELECT
CHAR_TIME,
CHAR_INST,
BATCH_ID,
MIN(DECODE(CHAR_ID,6543,CHAR_VALUE)) AS ORDD,
MIN(DECODE(CHAR_ID,6528,CHAR_VALUE)) AS AREAA,
MIN(DECODE(CHAR_ID,6529,CHAR_VALUE)) AS ATT,
COALESCE(MIN(DECODE(CHAR_ID,6534,CHAR_VALUE)),'N/A') AS CATAGORY,
MIN(DECODE(CHAR_ID,6535,CHAR_VALUE)) AS DESC1,
MIN(DECODE(CHAR_ID,6536,CHAR_VALUE)) AS DESC2,
MIN(DECODE(CHAR_ID,6537,CHAR_VALUE)) AS ETYPE,
MIN(DECODE(CHAR_ID,6538,CHAR_VALUE)) AS LEVELL,
MIN(DECODE(CHAR_ID,6539,CHAR_VALUE)) AS MODULE,
MIN(DECODE(CHAR_ID,6540,CHAR_VALUE)) AS MODULE_DESCRIPTION,
MIN(DECODE(CHAR_ID,6541,CHAR_VALUE)) AS NODE,
MIN(DECODE(CHAR_ID,6542,CHAR_VALUE)) AS STATE,
MIN(DECODE(CHAR_ID,6533,CHAR_VALUE)) AS UNIT
FROM CHAR_BATCH_DATA
WHERE subbatch_id = 1774
GROUP BY CHAR_TIME, CHAR_INST, BATCH_ID
So... why does the query omit rows on the first execution? Is this some sort of optimizer issue. Do I need to rebuild indexes? I looked at the indexes, they are all valid.
Thanks for looking,
Dan

user2188367 wrote:
I have a query that returns two different results:
Oracle Version : 10.2.0.1.0
I am running the following query on the Oracle server in SQL*Plus Worksheet.
SELECT COUNT(*)
FROM AEJOURNAL_S1
WHERE CHAR_TIME BETWEEN TO_DATE('12-AUG-10 01:17:39 PM','DD-MON-YY HH:MI:SS AM') AND
TO_DATE('13-AUG-10 14:17:34','DD-MON-YY HH24:MI:SS')
AND DESC2 LIKE '%'
AND DESC1 LIKE '%'
AND DESC2 LIKE '%'
AND ETYPE LIKE '%'
AND MODULE LIKE '%'
AND LEVELL = '11-WARNING'
ORDER BY ORDD DESC;
The very first time the query is run, it will return a count of 259. The next time the query is run, lets say, 10 seconds later, it will return a count of 260. The above query is exemplary of the kind of thing I'm trying to do. It seems like the more fields filtered against '%', the more random the count return becomes. Sometime you have to execute the query three or four times before it levels out to a consistent number.
I'm using '%' as the default for various fields, because this was the easiest thing to do to support a data-driven Web interface. Maybe I have to 'dynamically' build the entire where clause, instead of just parameterizing the elements and having default '%'. Anyway, to eliminate the web interface for the purpose of troubleshooting the above query was run directly on the Oracle server.
This query runs against a view. The view does a transpose of data from a table.
Below is the view AEJOURNAL_S1
SELECT
CHAR_TIME,
CHAR_INST,
BATCH_ID,
MIN(DECODE(CHAR_ID,6543,CHAR_VALUE)) AS ORDD,
MIN(DECODE(CHAR_ID,6528,CHAR_VALUE)) AS AREAA,
MIN(DECODE(CHAR_ID,6529,CHAR_VALUE)) AS ATT,
COALESCE(MIN(DECODE(CHAR_ID,6534,CHAR_VALUE)),'N/A') AS CATAGORY,
MIN(DECODE(CHAR_ID,6535,CHAR_VALUE)) AS DESC1,
MIN(DECODE(CHAR_ID,6536,CHAR_VALUE)) AS DESC2,
MIN(DECODE(CHAR_ID,6537,CHAR_VALUE)) AS ETYPE,
MIN(DECODE(CHAR_ID,6538,CHAR_VALUE)) AS LEVELL,
MIN(DECODE(CHAR_ID,6539,CHAR_VALUE)) AS MODULE,
MIN(DECODE(CHAR_ID,6540,CHAR_VALUE)) AS MODULE_DESCRIPTION,
MIN(DECODE(CHAR_ID,6541,CHAR_VALUE)) AS NODE,
MIN(DECODE(CHAR_ID,6542,CHAR_VALUE)) AS STATE,
MIN(DECODE(CHAR_ID,6533,CHAR_VALUE)) AS UNIT
FROM CHAR_BATCH_DATA
WHERE subbatch_id = 1774
GROUP BY CHAR_TIME, CHAR_INST, BATCH_ID
So... why does the query omit rows on the first execution? Is this some sort of optimizer issue. Do I need to rebuild indexes? I looked at the indexes, they are all valid.
Thanks for looking,
DanIn fact you the first time you ran the query the data has been retrived from disk to memory , in the second time the data is already in memory so the respnse time should be faster ,but if you chagne any condition or column or letter case the optimizer will do the first step (data will be retrived from disk to memory )

Same code gives different results in Matlab Script in Labview and Matlab

I am implemeting a Matlab code into a LabVIEW application using Matlab script. When I import the exactly same code to the Matlab Script in LabVIEW it gives a different result than it is in Matlab. This code is a simulation code including first kind bessel functions. Using LabVIEW 7.1 and Matlab R14 service pack 3.

Labview 8.5
Matlab R2009b
Attached are the graphs produced by matlab script in labview and in matlab.
The minimum of graph produced by matlab code is below 1 and that in labview is above 1.
Thanks a lot for your reply.
Sorry, I haven't quantified the "sometimes" yet.
Attachments:
matlabsResult.jpg ‏29 KB
LV.png ‏84 KB

Strange query plans, and so different results from a view.

In my database (11g), I have a currency exchange rate table, which contains all currencies and their exchange rate to USD. I need to have a number of different exchange rates - To GBP, EUR, etc...
To accomplish this I have created a view, which has one union statement of all the USD exchange rates, with the same data joined back on itself to give the exchange rates based on their exchange rate to USD - ie: SELECT b1.Date, b1.Currency AS FromCurrency, b2.Currency as ToCurrency, b1.Rate/b2.Rate as Exchange Rate FROM Rates b1, Rates b2 on b1.Date = b2.Date
This view works fine when I query it, and returns the data as I expect.
I have a second view that is joined to this view to give a return of the amount in each currency for reporting. This view seems to work correctly when I narrow down the search requirements and have a small set of data.
The issue I am having is when I query the second view and get it to return all the data. Instead of receiving 4 rows per transaction (I am only interested in 4 exchange rates for display) I typically receive up to 2 rows. The first record is for the conversion to USD, the second record is for the conversion to the supplied currency. The issue is that this exchange rate actually includes the aggregate for all 3 other requested currencies (not the USD).
So instead of getting something like:
Amt RC BC (Amt = Amount, RC = Reporting Currency. BC = Base Currency)
60 GBP GBP
80 EUR GBP
100 USD GBP
1000 ZAR GBP
60 GBP USD
80 EUR USD
100 USD USD
1000 ZAR USD
I get the following set of results:
1140 GBP GBP
100 USD GBP
100 USD USD
Has anyone come accross something similar or have any ideas on how I can resolve this?
Thanks
PS: I can get both sets of results from the same view depending on the filter criteria. Also if I convert the exchange rates into a table, it then returns the correct results as expected.

943081 wrote:
The idea is to seek help in solving the problem. I was hoping that perhaps someone had experienced the same thing - different results for "effectively" the same query:Well, that's the issue... without additional info, it's not clear what issue you were seeing.
SELECT * FROM view WHERE Date = '01 January, 2012'
verse
SELECT * FROM view WHERE Date > '31 December, 2011' ORDER BY DateNow it's a bit clearer. That second query is not "effectively" the same as the first query. If the date column is in DATE format, then you ought to have a to_date() around the date string to explicitly convert it into a date so you can do date-to-date comparisons correctly. Also, DATE datatype stores times as well as dates, so asking for data matching midnight of a specific date is different than asking for data greater than midnight of the previous day.
If the date string is a string, then ... well, the string "31 December 2011" is greater than the string "31 August 2013", despite it being an earlier date. This is why making sure you're using the right datatype for the job is important - a date is different to a string that just happens to contain a date.
DateID
I have no objection to using a Date but always struggle to understand what someone means when they tell me "06/07/2012" - granted if the day is above 12 or the same day and month I don't have a problem - but it still leaves 121 days a year that are confusing. sure, but just because you find outputting the display (or rather, someone else's output) confusing doesn't mean you still shouldn't use the correct datatype. Store things as a date, and you can then output it in whatever format you like. Try doing that with a string or a number.
Don't say it doesn't happen as I got a birthday card from a company in May this year when I have specifically entered my date of birth as being the 5 of a month (name drop down box on their website)!Just because someone else doesn't understand how to work with dates correctly doesn't mean you can't! It's not exactly rocket science, after all!*{;-)

Same Query returning different result (Different execution plan)

Hi all,
To day i have discovered a strange thing: a query that return a different result when using a different execution plan.
The query :
SELECT *
FROM schema.table@database a
WHERE     column1 IN ('3')
       AND column2 = '101'
       AND EXISTS
              (SELECT null
                 FROM schema.table2 c
                WHERE a.column3 = SUBSTR (c.column1, 2, 12));where schema.table@database is a remote table.
when executed with the hint /*+ ordered use_nl(a c) */ these query return no result and its execution plan is :
Rows     Row Source Operation
      0 NESTED LOOPS (cr=31 r=0 w=0 time=4894659 us)
   4323   SORT UNIQUE (cr=31 r=0 w=0 time=50835 us)
   4336    TABLE ACCESS FULL TABLE2 (cr=31 r=0 w=0 time=7607 us)
      0   REMOTE (cr=0 r=0 w=0 time=130536 us)When i changed the execution plan with the hint /*+ use_hash(c a) */
Rows     Row Source Operation
   3702 HASH JOIN SEMI (cr=35 r=0 w=0 time=497839 us)
22556   REMOTE (cr=0 r=0 w=0 time=401176 us)
   4336   TABLE ACCESS FULL TABLE2 (cr=35 r=0 w=0 time=7709 us)It seem that when the execution plan have changed the remote query return no result.
It'is a bug or i have missed somthing ?
PS: The two table are no subject to insert or update statement.
Oracle version : 9.2.0.2.0
System version : HP-UX v1
Thanks.

H.Mahmoud wrote:
Oracle version : 9.2.0.2.0
System version : HP-UX v1Hard to say. You're using a very old and deprecated version of the database, and one that was known to contain bugs.
9.2.0.7 was really the lowest version of 9i that was considered to be 'stable', but even so, it's old and lacking in many ways.
Consider upgrading to the latest database version at your earliest opportunity. (or at least apply patches up to the latest 9i version before querying if there is bugs in your really low buggy version)

HT4207 Archiving gmail e-mails on MacBook Pro vs iPhone: Same action, different results

The core issue:
The same action yields different results.
The details:
First, I'm on my laptop looking at an e-mail sent to my gmail account and want to archive it so I hit archive and it goes to the archive folder; Second, I'm on my iPhone looking at an e-mail sent to my gmail account and want to archive it so I hit archive and it goes to the "All Mail" folder in my gmail account. The second part doesn't make me happy because it doesn't make any sense. In other words the same action results in two different results.
Ideal solution:
Please tell me how to make the archive icon on my iPhone act like its righteous twin does on my MacBook Pro.
Thanks!

Same question, but the reverse. I want Apple Mail on Mountain Lion to work like iOS with regard to archiving Gmail messages.

Same Sequence# with different applied value in v$archived_log

Hi everyone,
I have an issue with one of the dataguard servers here.
Basically, looking at the v$managed_standby, it is still applying the latest archived log sequence.
However when I checked for unapplied archived log from v$archived_log, I found at least 1 sequence# which was quite old (around a few days old) not applied.
my query to check this is:
SELECT sequence# from v$archived_log where applied = 'NO';result:
SEQUENCE#
    40154
    40546with a different query I found an interesting result
select sequence#, recid, stamp, status, applied from v$archived_log where sequence# in (40154, 40546);result:
SEQUENCE#      RECID      STAMP S APP
    40154       8093 777156019 D NO
    40154       8095 777156053 D YES
    40546       8486 777673729 D NO
    40546       8487 777673734 D YESAt the time I ran this query, the v$managed_standby are as follow:
select process, status, sequence# from v$managed_standby;result:
PROCESS   STATUS        SEQUENCE#
ARCH      CLOSING           40562
ARCH      CLOSING           40557
MRP0      APPLYING_LOG      40563
RFS       IDLE                  0
RFS       IDLE              40563A simple solution to get those un-applied archived log to be applied is to restart the standby database instance.
Another finding from the production database:
select recid, stamp, sequence#, creator, registrar, standby_dest from v$archived_log where sequence# in (40154, 40546);result:
RECID      STAMP SEQUENCE# CREATOR REGISTR STA
45446 777156011      40154 ARCH    ARCH    NO
45447 777156017      40154 LGWR    LGWR    YES
45450 777156051      40154 ARCH    ARCH    YES
46231 777673709      40546 ARCH    ARCH    NO
46232 777673728      40546 LGWR    LGWR    YES
46233 777673733      40546 ARCH    ARCH    YESThe question is of course, why is this happening?
Can this be prevented?
Thank you,
Adhika

CKPT wrote:
I have an issue with one of the dataguard servers here.
Basically, looking at the v$managed_standby, it is still applying the latest archived log sequence.
However when I checked for unapplied archived log from v$archived_log, I found at least 1 sequence# which was quite old (around a few days old) not applied.
my query to check this is:
SELECT sequence# from v$archived_log where applied = 'NO';result:
SEQUENCE#
40154
40546
Even if old archives applied or not, it will keep transfer the archivelogs from primary. Please confirm that you been executed above query in standby.. is it?Yes I ran it from the standby database
CKPT wrote:
with a different query I found an interesting result
select sequence#, recid, stamp, status, applied from v$archived_log where sequence# in (40154, 40546);result:
SEQUENCE#      RECID      STAMP S APP
40154       8093 777156019 D NO
40154       8095 777156053 D YES
40546       8486 777673729 D NO
40546       8487 777673734 D YES
How many remote/standby destinations you have in your DR setup?
Might this query you have executed in primary, You should always use DEST_ID when executing from primary (or) do check in standby database, Because the applied column you have to check in standby , If you see above the same sequence showing applied in one destination & not applied on other instance, so please do select for dest_2 or in standby.I have only 1 standby destination.
The query above was executed in the standby database server as well as to show that the same sequence# has different result in the applied column.
CKPT wrote:
The question is of course, why is this happening?
Can this be prevented?What is your Online redo log file size (or) how much average archive log file size?
This issue happens when Network glitch while transferring archives from primary to standby RFS , So when is big enough in such conditions it will be in status can be WAIT_FOR_LOG.
BTW, which redo transport you are using? -- recommended to use LGWR
Is there any network problem?
check for exact problem either from primary alert log file or from below query,
SQL> select severity,error_code,message,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status;
SQL> select sequence#, to_char(completion_time,'DD-MON-YYYY HH24:MI:SS') from v$archived_log where sequence# in (40154, 40546);
HTH.The redolog file size is 100MB and so does the archive log file size.
I'm using LGWR ASYNC
these are the result of the query which I modified slightly:
query:
select severity,error_code,message,to_char(timestamp,'DD-MON-YYYY HH24:MI:SS') from v$dataguard_status where message like '%40154%' or message like '%40546%';result:
SEVERITY ERROR_CODE MESSAGE                                                                                              TIMESTAMP
Warning           0 LNS: Standby redo logfile selected for thread 1 sequence 40546 for destination LOG_ARCHIVE_DEST_2    11-MAR-2012 20:28:44
Warning           0 ARC1: Standby redo logfile selected for thread 1 sequence 40546 for destination LOG_ARCHIVE_DEST_2   11-MAR-2012 20:28:49The message for the 40154 must have been purged.
It appeared to me that sequence 40546 has been sent twice, by LNS and ARC1.
query:
select sequence#, registrar, creator, standby_dest, dest_id, to_char(completion_time,'DD-MON-YYYY HH24:MI:SS') completion_time from v$archived_log where sequence# in (40154, 40546);result:
SEQUENCE# REGISTR CREATOR STA    DEST_ID COMPLETION_TIME
    40154 ARCH    ARCH    NO           1 05-MAR-2012 20:40:11
    40154 LGWR    LGWR    YES          2 05-MAR-2012 20:40:17
    40154 ARCH    ARCH    YES          2 05-MAR-2012 20:40:51
    40546 ARCH    ARCH    NO           1 11-MAR-2012 20:28:29
    40546 LGWR    LGWR    YES          2 11-MAR-2012 20:28:48
    40546 ARCH    ARCH    YES          2 11-MAR-2012 20:28:53This query proved that the primary database is actually trying to send twice with a different completion time.
Why does the primary database has to send twice?
Thanks for replying,
Adhika

Analytic function should produce different results

Hi All
My question is derived by a usage of the analytic functions with "sliding window". Let's say you have a table as
GROUP_ID SEQ VALUE
1 1 1
1 1 2
2 2 3
2 3 4
Then the query
select sum( value ) over ( partition by group_id order by group_id, seq ) from a_table
should produce different values for different runs because rows 1,2 have the same value of SEQ. One run may produce 2 then 1 another one may produce 1 then 2.
I need to prove it if the statement above is true. Oracle caches data so if run it several times you will see the same result.
Thanks.

Why are you using group_id twice, in partition and order by? And why would several "runs" on the same data provide different results?
C.

Different results on a SQL sort depending on the tool?

Hi,
i've a problem with sorting a column, getting different results depending on the tool.
Environment:
Oracle 8.1.6 on Solaris, Oracle Client on NT 4.0 (SP5)
The Query:
SELECT * FROM mytable ORDER BY mycolumn ASC
This is the result of a query by SQL Plus Worksheet:
0000000006
0000100100
A00000
A06015
A06016
This is the result of a query by SQL*Plus (and Oracle ODBC 32Bit Test and a jdbc query) :
A00000
A06015
A06016
0000000006
0000100100
Why has the same SQL statement different results?
Why are there different collating orders?
How can this be solved?
Can anyone help me?
Regards Stefan
null

At this point I think you should get Applejack...
http://www.macupdate.com/info.php/id/15667/applejack
After installing, reboot holding down CMD+s, (+s), then when the DOS like prompt shows, type in...
applejack AUTO
Then let it do all 6 of it's things.
At least it'll eliminate some questions if it doesn't fix it.
The 6 things it does are...
Correct any Disk problems.
Repair Permissions.
Clear out Cache Files.
Repair/check several plist files.
Dump the VM files for a fresh start.
Trash old Log files.
First reboot will be slower, sometimes 2 or 3 restarts will be required for full benefit... my guess is files relying upon other files relying upon other files! :-)
Disconnect the USB cable from any Uninterruptible Power Supply so the system doesn't shut down in the middle of the process.
Then... Try putting these numbers in Network>TCP/IP>DNS Servers, for the Interface you connect with...
208.67.222.222
208.67.220.220
Then Apply. For 10.5/10.6 Network, highlight Interface>Advanced button>DNS tab>little + icon.
DNS Servers are a bit like Phone books where you look up a name and it gives you the phone number, in our case, you put in apple.com and it comes back with 17.149.160.49 behind the scenes.
These Servers have been patched to guard against DNS poisoning, and are faster/more reliable than most ISP's DNS Servers.
The Interface that connects to the Internet, needs to be drug to the top of System Preferences>Network>Show:>Network Port Configurations and checked ON.
10.5.x/10.6.x instructions...
System Preferences>Network, click on the little gear at the bottom next to the + & - icons, (unlock lock first if locked), choose Set Service Order.
The interface that connects to the Internet should be dragged to the top of the list.

Same query giving different results

Hi
I m surprised to see the behaviour of oracle. I have two different sessions for same scheema on same server. In both sessions same query returns different results. The query involves some calculations like sum and divisions on number field.
I have imported this data from another server using export / import utility available with 9i server. Before export every thing was going fine. Is there some problem with this utility.
I m using Developer 6i as the front end for my client server application. The behaviour of my application is very surprizing as once it shows the correct data and if I close the screen and reopen, it shows wrong data.
I m really stucked with the abnormal behaviour. Please tell me the possiblities and corrective action for these conditions.
Regards
Asad.

There is nothing uncommitted in both the sessions. But still different results are returned.
I m sending u the exact query and result returned in both sessions.
Session 1:
SQL> rollback;
Rollback complete.
SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
3 WHERE G.COURSE_CDE=CC.COURSE_CDE
4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
6 /
CREDIT_HRS GRADE_PTS
3 4
4 3.33
4 3.33
3 4
3 4
3 4
3 4
7 rows selected.
SQL>
SESSION 2:
SQL> rollback;
Rollback complete.
SQL> SELECT CC.CREDIT_HRS,GP.GRADE_PTS
2 FROM GRADE G, COURSE_CODE CC, GRADE_POLICY GP
3 WHERE G.COURSE_CDE=CC.COURSE_CDE
4 AND G.SELECTION_ID=45 AND G.GRADE_TYP=GP.GRADE_TYP
5 AND G.TERM_PROG_ID=17 AND GP.TERM_ID=14
6 /
CREDIT_HRS GRADE_PTS
3 4
4 3.33
3 4
3 4
3 4
3 4
6 rows selected.
SQL>
U can see in session 1, seven rows are returned while in session 2 six rows are returned. I have issued a rollback before query to be sure that data in both sessions is same.

SQL Server 2012 Physical vs. Hyper-V Same Query Different Results

I have a database that is on physical hardware (16 CPU's, 32GB Ram).
I have a copy of the database that was attached to a virtual Hyper-V server (16 CPU's, 32GB Ram).
Both Servers and SQL Servers are identical OS=2008R2 Standard, SQL Server 2012R2 Standard same patch level SP1 CU8.
Same query run on both servers return same data set, but the time is much different 26 Sec on Physical, 5 minutes on virtual.
Statistics are identical on both databases, query execution plane is identical on both queries.
Indices are identical on both databases.
When I use set statistics IO, I get different results between the two servers.
One table in particular (366k rows) on physical shows logical reads of 15400, on Hyper-V reports logical reads of 418,000,000 that is four hundred eighteen million for the same table.
When the query is run on the physical it uses no CPU, when run on the Hyper-V it takes 100% of all 16 processors.
I have experimented with Maxdop and it does exactly what it should by limiting processors but it doesn't fix the issue.

A massive difference in logical reads usually hints at differences in the query plan.
When you compare query plans, it is essential that you look at actual query plans.
Please note that if your server / Hyper-V supports parallelism (which is almost always nowadays), then you are likely to have two query plans: a parallel and a serial query plan. Of course the actual query plan will make clear which one is used in which
case.
To say this again, this is by far the most likely reason for your problem.
There are other (unlikely) reasons that could be the case here:
runaway parallel threads or other bugs in the optimizer or engine. Make sure you have installed the latest service pack
Maybe the slow server (Hyper-V) has extreme fragmentation in the relevant tables
As mentioned by Erland, you have much much more information about the query and query plan than we do. You already know whether or not parallelism is used, how many threads are being used in it, if you have no, one or several Loop Joins in the query (my
bet is on at least one, possibly more), etc. etc.
With the limited information you can share (or choose to share), involving PSS is probably your best course of action.
Gert-Jan

Different results for same query on different servers

1. database being converted from 7.3.4 to 9.2
2. query is executed on both servers
3. different results!
The tables and data are the same, and indexes are setup on new server. EXPLAIN PLAN was run on both but with (predictably) widely different results.
I know, not much detail here, but has anyone ever ran into anything like this?
Thanks,
Pat

Folks,
Here is the relevant information for this problem. The attributes have been changed for confidentiality. If you need any other information let me know.
Thanks,
Pat
Query:
SELECT
one,two,three,four,a.five,six,seven,
a.eight,a.nine,
to_char(ten,'99999.99'),to_char(eleven,'99999.99'),
to_char(twelve,'99999.99'),to_char(thirteen,'99999.99'),
fourteen,fifteen,sixteen,seventeen,eighteen,
nineteen,twenty,twentyone
FROM
table1 a,
table2 b
WHERE
a.five = b.five
AND one = 'X'
AND six = ' '
AND three != 12345
AND three IN
(SELECT DISTINCT
three
FROM table3
WHERE
one = 'X'
AND twentytwo = 'XYZ'
AND twentythree != 0
AND twentyfour != 0
AND twentyfive = 'Y'
AND (a.five IN
(SELECT DISTINCT
five
FROM table1
WHERE
one = 'X'
AND three IN (12345)
Table1:
one          varchar2(1)     not null     PK
two          varchar2(20)     not null     PK
three          number(5)     not null     PK
four          number(2)     not null     PK
five          number(6)     not null     PK
six          varchar2(4)     not null     PK
seven          number(4)     not null
eight          varchar2(8)     not null
nine          date          not null
ten          number(7,2)
eleven     number(7,2)
twelve     number(7,2)
thirteen     number(7,2)
Table2:
five          number(6)     not null     PK
fourteen     varchar2(5)     not null
fifteen     varchar2(5)     not null
sixteen     varchar2(2)     not null
seventeen     varchar2(35)     not null
eighteen     varchar2(4)     not null
nineteen     varchar2(2)
twenty     varchar2(1)
twentyone     number(6)
Table3:
one          varchar2(1)     not null     PK
twentytwo     varchar2(12)     not null     PK
two          varchar2(20)     not null     PK
three          number(5)     not null     PK
four          number(2)     not null     PK
twentysix     number(2)     not null     PK
twentyfive     varchar2(1)     not null
nine          date          not null
twentythree     number(13,8)     not null
twentyfour     number(12,8)     not null
twentyseven     varchar2(1)     not null
eight          varchar2(8)     not null
Explain - Oracle9i (default, with CBO):
SELECT STATEMENT
RECURSIVE EXECUTION SYS_LE_3_0
RECURSIVE EXECUTION SYS_LE_3_1
TEMP TABLE TRANSFORMATION
HASH JOIN
HASH JOIN
HASH JOIN
TABLE ACCESS FULL SYS_TEMP_0FD9D6603_AB874A
TABLE ACCESS BY INDEX ROWID TABLE1
BITMAP CONVERSION TO ROWIDS
BITMAP AND
BITMAP MERGE
BITMAP KEY ITERATION
TABLE ACCESS FULL SYS_TEMP_0FD9D6603_AB874A
BITMAP CONVERSION FROM ROWIDS
INDEX RANGE SCAN TABLE1INDEX03
BITMAP MERGE
BITMAP KEY ITERATION
TABLE ACCESS FULL SYS_TEMP_0FD9D6602_AB874A
BITMAP CONVERSION FROM ROWIDS
INDEX RANGE SCAN TABLE1INDEX04
TABLE ACCESS FULL SYS_TEMP_0FD9D6602_AB874A
TABLE ACCESS FULL TABLE2
Query results - Oracle9i (with CBO):
X|A | 1| 0| 22| | 1|08-MAR-02|XYZ | | 24.00| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|B | 2| 1| 22| | 7|04-DEC-01|XYZ | | 3.25| 8.00| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|C | 3| 1| 22| | 1|14-AUG-02|XYZ | | 10.35| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|D | 4| 1| 22| | 6|11-JUL-02|XYZ | | .00| 13.90| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
(approximately 4550 rows returned)
Explain - Oracle9i (ALTER SESSION SET OPTIMIZER_METHOD=RULE;):
SELECT STATEMENT
MERGE JOIN
SORT JOIN
NESTED LOOPS
NESTED LOOPS
VIEW VW_NSO_1
SORT UNIQUE
TABLE ACCESS BY INDEX ROWID TABLE3
INDEX RANGE SCAN TABLE3INDEXPK
TABLE ACCESS BY INDEX ROWID TABLE1
INDEX RANGE SCAN TABLE1INDEX03
TABLE ACCESS BY INDEX ROWID TABLE2
INDEX UNIQUE SCAN TABLE2INDEXPK
SORT JOIN
VIEW VW_NSO_2
SORT UNIQUE
TABLE ACCESS BY INDEX ROWID TABLE1
INDEX RANGE SCAN TABLE1INDEX03
Explain - Oracle 7.3.4:
SELECT STATEMENT
MERGE JOIN
SORT JOIN
NESTED LOOPS
NESTED LOOPS
VIEW
SORT UNIQUE
TABLE ACCESS BY ROWID TABLE3
INDEX RANGE SCAN TABLE3INDEX03
TABLE ACCESS BY ROWID TABLE1
INDEX RANGE SCAN TABLE1INDEX03
TABLE ACCESS BY ROWID TABLE2
INDEX UNIQUE SCAN TABLE2INDEXPK
SORT JOIN
VIEW
SORT UNIQUE
TABLE ACCESS BY ROWID TABLE1
INDEX RANGE SCAN TABLE1INDEX03
Query results - Oracle 7.3.4:
X|A | 1| 0| 22| | 1|08-MAR-02|XYZ | | 24.00| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|B | 2| 1| 22| | 7|04-DEC-01|XYZ | | 3.25| 8.00| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|C | 3| 1| 22| | 1|14-AUG-02|XYZ | | 10.35| | |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|D | 4| 1| 22| | 6|11-JUL-02|XYZ | | .00| 13.90| |ABCDE|FGHIJ|AB|ABCDEFG |ABC | | | |
X|E | 5| 5| 23| | 1|22-FEB-01|XYZ | | 211.80| | |ABCDE|EFGHI|AB|HIJKLMN |DEF | | | |
(approximately 1150 rows returned)
Indexes (used):
TABLE1INDEX03     (three)
TABLE1INDEX04     (five)
TABLE2INDEXPK     (five)
TABLE3INDEXPK     (one,twentytwo,two,three,four,twentysix)
Discussion:
Notice the repeating result for X,E,5,5,23,.... in the Oracle9i retrieval using CBO.
The execution of this query returned approximately four times the number of rows as
Oracle 7.3.4 using RBO. This is a function of how many "fours" there are in table3
that have matching "threes and fours" in table1. If you put a DISTINCT clause at the
very front of the query (SELECT DISTINCT one,two,three ....) then the result is
accurate and the same as Oracle 7.3.4. In one execution of this query, 27,000 rows
are expected to be returned, but the server returned over 1 million rows!
When RBO was used on Oracle9i, the results were identical to the ones on Oracle 7.3.4.

Different result from same SQL statement

The following SQL statement brings back records using query
analyzer on the SQL server. However when I run it in a cold fusion
page it comes back with no results. Any idea why????????
SELECT COUNT(h.userID) AS hits, u.OCD
FROM dbo.tbl_hits h INNER JOIN
dbo.tlkp_users u ON h.userID = u.PIN
WHERE (h.appName LIKE 'OPwiz%') AND (h.lu_date BETWEEN
'05/01/07' AND '06/01/07')
GROUP BY u.OCD
ORDER BY u.OCD

Anthony Spears wrote:
> That didn't work either.
>
> But here is something interesting. If we use the dates
05/01/2007 and
> 06/01/2007 we get results in SQL Server Query Analyzer
but not using a cold
> fusion page. But if we use the dates 05/01/2007 and
09/01/2007 both get back
> the same results.
>
Are you absolutely, 100% sure that you are connecting to the
same
database instance with both CF and Query Analyzer? That kind
of symptom
is 9 out of 10 times because the user is looking at different
data. One
is looking at production and the other development or an
backup or
recent copy or something different.

PreparedStatement & regular Statement - different results for same select

I was wondering if someone could either
i) try this out for me to confirm my results or
ii) let me know what I am doing wrong
I'm one of the developers on a product and am currently investigating localization for the Thai language...just checking to see that Java and Swing have no problems with it. The only bewildering thing which has happened is noticing that some values which are fetched from the database display in Thai perfectly and other values display as a garble. Sometimes the exact same column is displayed correctly in one part of the program but is not OK in another part. I think I've figured out what it going on and suspect a bug in Oracle's JDBC:
Some selects were configured as PreparedStatements and those return the Thai properly. The more common case however was for programmers to use a simple Statement object for their select and it is in those that the multi-byte strings don't get returned properly.
The following code shows the problem that I am experiencing. I am basically executing the exact same select in 2 different ways and they are both giving different results as long as the column being queried contains a Thai character. If someone could grab and check it out and let me know if they see the same thing, I'd appreciate it. Just change the column/table name and the username/password/databaseIP to get it to run.
<code>
import java.sql.*;
public class SelectTest {
public static void main(String[] args) {
try {
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection( "jdbc:oracle:thin:@10.4.31.168:1524:ora8",
"dms_girouard",
"girouard");
String sqlCommand = "select C0620_Title from T0620_SwSheet";
Statement statement = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet resultSet1 = statement.executeQuery(sqlCommand);
while (resultSet1.next()) {
if (resultSet1.getString("C0620_Title") != null) {
System.out.println("resultSet1 Title = " + resultSet1.getString("C0620_Title"));
PreparedStatement preparedStatement = conn.prepareStatement(sqlCommand);
ResultSet resultSet2 = preparedStatement.executeQuery();
while (resultSet2.next()) {
if (resultSet2.getString("C0620_Title") != null) {
System.out.println("resultSet2 Title = " + resultSet2.getString("C0620_Title"));
catch (Exception e) {
System.out.println(e.getMessage());
</code>

Hi Peter,
Are you using NCHAR column for Thai , or is your database character set set for Thai.
If you are using a NCHAR column for holding Thai data, then you have to use the
OraclePreparedStatement.setFormOfUse(...) before executing the select.
Regards
Elango. Hi Elangovan,
Thank you for answering.
The datatype on the column is VARCHAR2.
I did my initial tests without doing anything special to make sure the database is localized for Thai, and I was happy to find that almost everything still worked fine - I was able to save and retrieve Thai strings to the database almost perfectly.
The only problem I discovered was the difference between Statement and PreparedStatement selects on a column containing Thai. Colleagues of mine have said they see the same thing when testing on a Oracle database which has been configured specifically for the Thai customer.
I read somewhere that the current JDBC drivers are using an older version of the Unicode standard than the most current version of the Java SDK and that it was causing some problems with Korean. I'm wondering if maybe it's the same problem with Thai.

Same infoprovider, different results

Hello together,
here it is my problem: I have one infoprovider and two queries based on it. In both queries I have one identical formula, but the result is different ..
Could you please help me? Where could be the problem?
Thank you,
Iuliana

Please chacek all the InfoObjects in rows and columns in both Queries and Formulas/CKFs/RKFs/ and variavles too....Definetly there will be a difference..so you are getting different results...all calculated kfs in both Queries using same formulas?
There is no rule that both Queries should display same result if both are on Same infoProvider unless and until both are similar(one Query is copy of another one)...
i don't think in u r case it is same..
Please don't forget to assign points if it is helpfulu.its the way of saying thnaks here in SDN.

Same sql statement two different results?

Hi,
I was wondering if anyone knows why I am getting different
results on the same query.
Basically... when I run this query in "view" in sql server, I
get the results I need, however when I run in Coldfusion, I am
getting totally different results.... It is a totally different
result...
the query:
SELECT DISTINCT
tbl_employees.indexid, tbl_employees.[Employee ID] as
employeeid, tbl_employees.[First Name] as firstname,
tbl_employees.[Last Name] as lastname,
tbl_employees.[Supervisor ID] as supervisorid,
tbl_workaddress_userdata.firstname,
tbl_workaddress_userdata.lastname,
tbl_workaddress_userdata.supervisorid,
tbl_workaddress_userdata.location,
tbl_workaddress_userdata.employeeid,
tbl_workaddress_userdata.locationdescription
FROM tbl_employees FULL OUTER JOIN
tbl_workaddress_userdata ON tbl_employees.[Employee ID] =
tbl_workaddress_userdata.employeeid
WHERE (tbl_employees.[Supervisor ID] = 7) AND
(tbl_workaddress_userdata.location IS NULL)

I suspect you and your CF DSN are looking at two different
DBs...
Adam

Same Query...Same DB Instance....Different results

Similar Messages

Maybe you are looking for