| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4941.1 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Tue Jan 21 1997 10:17 | 6 |
| 4941.2 | MMi | NOVA::SMITHI | Don't understate or underestimate Rdb! | Tue Jan 21 1997 10:28 | 5 |
| 4941.3 | Table & cache definitions | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Tue Jan 21 1997 12:51 | 38 |
| 4941.4 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Tue Jan 21 1997 13:28 | 37 |
| 4941.5 | Don't forget padding bytes | NOVA::MCGEE | Oracle Rdb Mission Critical Engineering | Tue Jan 21 1997 14:06 | 5 |
| 4941.6 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Thu Jan 23 1997 06:25 | 7 |
| 4941.7 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Thu Jan 23 1997 06:59 | 6 |
| 4941.8 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Thu Jan 23 1997 09:52 | 27 |
| 4941.9 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Thu Jan 23 1997 10:19 | 4 |
| 4941.10 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Thu Jan 23 1997 11:22 | 16 |
| 4941.11 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Fri Jan 24 1997 08:13 | 7 |
| Try linking the storage area that contains the SITE_PARENT table to the
SITE_PARENT cache & see if the cache starts getting used.
Also, try running SHOW STATS first, THEN try to insert rows into the SITE_PARENT
table. There might be a problem creating the cache from SQL...
Rick
|
| 4941.12 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Mon Jan 27 1997 05:43 | 12 |
| I created a cache for the site_parent storage area.
The row cache screen for the SITE_PARENT cache still doesn't change,
however, the storage area cache does get used.
I ran show stats first, then loaded the records, then did a select. The
load showed up, but not the select.
Bascially, inserts/updates/deletes do get shown in show stats, selects
don't.
Louise.
|
| 4941.13 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Mon Jan 27 1997 11:01 | 10 |
| is the select via an index?
to get to a row in the row cache you must be doing select by DBKEY. Either
using SELECT ... WHERE DBKEY =... or the query must be using an index which
will indirectly select by DBKEY.
Sequential access will have to scan the base table on disk because there is no
knowledge that the rows are all in cache.
Ian
|
| 4941.14 | index is the key | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Mon Jan 27 1997 12:36 | 12 |
| It's doing index only retrieval using SITE_PARENT_SORT1.
This index uses all the columns in the table. I redefined it with just
one, and now it works.
I also tried this on mf_personnel. I created a table with employee_id &
last_name, then an index using both these columns, and it does the same
thing.
So it's something to do with all columns being used in an index.
Louise.
|
| 4941.15 | | NOVA::SMITHI | Don't understate or underestimate Rdb! | Mon Jan 27 1997 23:22 | 4 |
| Right, what is the strategy used for the query? If it is INDEX ONLY RETRIEVAL
then it never fetches the row from the table.
Ian
|
| 4941.16 | | ukvms3.uk.oracle.com::LWILES | Louise Wiles, UK Rdb support | Tue Jan 28 1997 04:30 | 8 |
| Got it now.
Thanks very much for the help.
I've created a cache for the index, and see that that's being used.
Feeling suitably sheepish,
Louise.
|
| 4941.17 | | NOVA::R_ANDERSON | Oracle Corporation (603) 881-1935 | Tue Jan 28 1997 06:32 | 5 |
| Vindicated!!!
:-)
Rick
|