They are the same -- when you understand whats going on under the covers, this'll be an "ah hah" sort of question.
See
http://docs.oracle.com/docs/cd/A87860_01/doc/server.817/a76961/ch3.htm#5014
which says in part:
<quote>
About Dynamic Performance Views
Oracle contains a set of underlying views that are maintained by the server and accessible to the database administrator user SYS. These views are called dynamic performance views because <b>they are continuously updated </b>while a database is open and in use, and their contents relate primarily to performance.
Although these views appear to be regular database tables, <b>they are not.</b> These views provide data on internal disk structures and memory structures. You can select from these views, but you can never update or alter them.
Notes:
* You can query the dynamic performance views to extract information from them. However, <b>only simple queries are supported.</b> If sorts, joins, GROUP BY clauses and the like are needed, you should copy the information from each V$ view into a table (for example, using a CREATE TABLE ... AS SELECT statement), and then query from those tables.
* Because the information in the V$ views is dynamic, <b>read consistency is not guaranteed for SELECT operations on these views.</b>
....
</quote>
That last part -- about read consistency -- is the kicker. I've modified your queries a tad so we can see the stats that were different:
ops$tkyte@ORA817DEV.US.ORACLE.COM> column sid new_val s
ops$tkyte@ORA817DEV.US.ORACLE.COM> select sid from v$mystat where rownum=1;
SID
----------
18
ops$tkyte@ORA817DEV.US.ORACLE.COM>
ops$tkyte@ORA817DEV.US.ORACLE.COM>
ops$tkyte@ORA817DEV.US.ORACLE.COM> select a.name, b.value
2 from v$statname a, v$sesstat b
3 where a.statistic# = b.statistic#
4 and b.sid = &S
5 MINUS
6 select a.name, b.value
7 from v$statname a, v$mystat b
8 where a.statistic# = b.statistic#
9 /
old 4: and b.sid = &S
new 4: and b.sid = 18
NAME VALUE
------------------------------ ----------
session pga memory 119152
session pga memory max 119152
session uga memory 53456
session uga memory max 57900
sorts (memory) 0
sorts (rows) 0
6 rows selected.
<b>what that is saying is the when we processed the v$sesstat table, we were using 119,152 bytes of PGA memory. When we processed v$mystat -- we had some DIFFERENT amount of PGA memory -- by the time we got there, it was different, hence the minus shows us the row from v$sesstat.
Now, the sorts are just the same -- you KNOW a minus needs a sort right (no indexes here). Well, when we scanned v$sesstat, we hadn't sorted yet. By the time we got to v$mystat -- WE HAD</b>
ops$tkyte@ORA817DEV.US.ORACLE.COM> select a.name, b.value
2 from v$statname a, v$mystat b
3 where a.statistic# = b.statistic#
4 MINUS
5 select a.name, b.value
6 from v$statname a, v$sesstat b
7 where a.statistic# = b.statistic#
8 and b.sid = &S
9 /
old 8: and b.sid = &S
new 8: and b.sid = 18
NAME VALUE
------------------------------ ----------
session uga memory 53456
sorts (memory) 6
sorts (rows) 1416
ops$tkyte@ORA817DEV.US.ORACLE.COM>
<b>what that shows us is the memory usage sort of settled down, little different UGA numbers but that is it. Again the sort numbers come out but that is expected -- the first query must have done 4 sorts of 1,416 rows and by the time we got to v$sesstat in this query -- we had done more!
Sort of 'neat', unexpected maybe -- but 'neat'.
Here is the topper:</b>
ops$tkyte@ORA817DEV.US.ORACLE.COM> select a.statistic#, a.value, b.value
2 from v$mystat a, v$mystat b
3 where a.statistic# = b.statistic#
4 and a.value != b.value;
STATISTIC# VALUE VALUE
---------- ---------- ----------
15 61728 53456
188 13 12
190 3072 2832
<b>Hmmmm</b>