the indexes are unusable
HelloI am a beginner...
the indexes are unusable...
How can I do real state
You can rebuild the indexes.
Tags: Database
Similar Questions
-
Why the index are lost after recovering from a REPLICATE_PERSISTENT region?
GemFire Version V7.0.1.3 for region below specifications. java.lang.String com.foo.bar.Positon after recovery of the store persistent it is no markings on the region. All indexes are lost. CacheFactory cacheFactory = new CacheFactory(); cache = cacheFactory.create (); Ins ByteArrayInputStream = new ByteArrayInputStream (cachexmlstring); cache.loadCacheXml (ins);
OK I understood why the index get lost. Is that the way cache is initialized.
CacheFactory cacheFactory = new CacheFactory();
cache = cacheFactory.create (); Cache is created here without consideration of persistence pdx
Ins ByteArrayInputStream = new ByteArrayInputStream (cachexmlstring);
cache.loadCacheXml (ins); Now loading data it has no definition pdx index data.
So now even if I get the data loaded in the regions, when I probe through gfsh, there's no index.
I just changed the code of
FileOutputStream ops = new FileOutputStream ("cache.xml");
OPS. Write (cachexmlstring. GetBytes());
CacheFactory cacheFactory = new CacheFactory();
cache = cacheFactory.create ();
The indexes are coming fine...
-
The menus are unusable, even to turn off hardware acceleration to fix menus
I'm using Firefox under awesome on Ubuntu 13.04 on a MacBook Pro of the retina. Unfortunately, the menus are completely unusable. If I try to open the 'Tools' menu, for example, a small floating window appears which is barely big enough to show and down the scroll buttons, but no other text.
This problem has occurred on and off for many years. The recommended solution is usually to disable hardware acceleration... via a specific menu. Unfortunately, this does not work for me, since I can't navigate the menus. I looked into: config to see if there was an obvious option, but didn't fine anything.
I have a screenshot of what the menus look like, but unfortunately do not know how to fix it.
For unrelated reasons, I reinstalled ubuntu. I could try Firefox again, and the problem disappeared! Time to move from Chrome to Firefox! Unfortunately, I do not know what is specifically modified to correct the problem.
-
Journal of the fields on the site of the Bank are unusable
yesterday I went to log on the site of the Bank, but the number fields and password of the customer are not active. They work on IE. I also tried to update the plugin Adobe, but it fails
Clear the cache and cookies from sites that cause problems.
"Clear the Cache":
- Tools > Options > advanced > network > storage (Cache) offline: 'clear now '.
'Delete Cookies' sites causing problems:
- Tools > Options > privacy > Cookies: "show the Cookies".
Start Firefox in Firefox to solve the issues in Safe Mode to check if one of the extensions of the origin of the problem (switch to the DEFAULT theme: Firefox (Tools) > Add-ons > appearance/themes).
- Makes no changes on the start safe mode window.
- https://support.Mozilla.com/kb/safe+mode
- https://support.Mozilla.com/kb/troubleshooting+extensions+and+themes
-
What data dictionary view can tell me what columns in the index are compressed?
So I can create an index compressed on a table like this:
create index t23_idx on t23 (col3, col5, col1) compress 2;
This creates an index with a degree of compression of 2. So far so good.
But how do I know what columns are in fact, compressed at a later date? View USER_INDEX tells me that if COMPRESSION is enabled, but there is nothing on the view USER_IND_COLUMNS to say which columns are compressed.
Of course, I can retrieve information through DBMS_METADATA. GET_DDL but I'm really after receiving a request, because it is more convenient.
I had hopes for SYS. ICOL$. SPARE1, but that doesn't seem to be compatible with what I expect. However, if someone can confirm that this column is indeed the Badger so I gladly adjust my expectations.
Cheers, APCOK, I may not read your question.
DBA_INDEXES. PREFIX LENGTH is "the number of columns in the prefix of the compression key."http://docs.Oracle.com/CD/E11882_01/server.112/e24448/statviews_1106.htm#i1578369
Mike
-
Last night, our processor has been spilled and although he fell very hard, we have no audio data, we are unable to change the screen resolution, and we are unable to turn on our safety Center, among other things that bothers. We have access to the internet. I have checked the cables and connections but can't find nothing obvious. We need to operate the computer in safe mode. Any help would be most appreciated. Elen
Hi Elen,
1. what happens when you start in normal mode?
Safe mode starts Windows with a limited set of files and drivers. Startup programs do not work in safe mode, and only the basic drivers needed to start Windows are installed.
Start your computer in safe mode
http://Windows.Microsoft.com/en-us/Windows7/start-your-computer-in-safe-mode
This can also occur if the cables and cards are not connected correctly. You can check if the cables and cards are connected correctly.
Hope this information is useful.
-
When indexes are stored in the Oracle?
I just read that "the index blocks have been already in memory. Can someone explain this please? I thought that the indexes are waiting in the data file?
In other words, I'm learning the location of index.
Thanks for your help.
NightWing wrote:
EdStevens wrote:
Introduction to computing systems 101: (in other words, really, really basic and nothing to do with Oracle, or any other application)
The data are stored on a physical medium, such as disk or tape.
Data cannot be used (acted on, analyzed, etc.) until it is in memory.
For Oracle, this means a block of data (and an index is simply a particular piece of data) must be read (disk) storage and placed in memory (buffer) before it can be used for anything.
When you say "data cannot be used (acted on, analyzed, etc.) until it is in the memory." Then, please correct me if I'm wrong, the first operating system or get the expected data from disk to memory, then these data are used in memory.
Is there any document relating to this information.
Thank you for your remarkable knowledge.
Do you want to confirm? You know, it would be far too costly to try to read the disc things and process. That's why Oracle would bring the contents of the disc in its structure of memory (buffer cache) before he would let you access and process them.
Aman...
-
How the index data are managed within the cluster?
Hello
We are evaluating the consistency.
Regarding indexes, am I right in thinking that the data in the index are stored in a (managed internally) cache on the same node that the attendant at the following indexed values? I'm not interested in getting the data in the index, but rather just to understand how the data in the index itself are stored or processed within the cluster.
So in a 2 cluster node where an index is applied to a distributed cache that has only 2 entries, will there be a key cache on each node 1 {binary,} to enter key where the key points to the value that is stored on this same node? In other words, I'm sure that the index data to be spread out in the cluster in the case of a partitioned topology?
Concerning
Peteruser11279467 wrote:
HelloWe are evaluating the consistency.
Regarding indexes, am I right in thinking that the data in the index are stored in a (managed internally) cache on the same node that the attendant at the following indexed values? I'm not interested in getting the data in the index, but rather just to understand how the data in the index itself are stored or processed within the cluster.
So in a 2 cluster node where an index is applied to a distributed cache that has only 2 entries, will there be a key cache on each node 1 {binary,} to enter key where the key points to the value that is stored on this same node? In other words, I'm sure that the index data to be spread out in the cluster in the case of a partitioned topology?
Concerning
PeterHi Peter,.
up to 3.4.x index have been supported only on partitioned topology, and Yes, the index on each node contain only the data corresponding to the entries that have their main copy on this node (referred to as entered local subsequently).
The indexes are not stored in a cache, but they are managed under the information that maintains consistency in terms of backup (the map that contains local entries).
The indexes are in 2 parts:
-index to the front: this is a mapping of the cache key in an internal representation (Playback key card in the future) the value extracted with the extractor used to create the index of the entry to membership of the cache key (value extracted later)
-reverse index (aka. reversed card): this is a map of the value extracted from a backup set of the keys of the map of entries which we extract the index key reversed with the extractor used to create the index
The index can be sorted, which means that the index reversed a SortedMap (sort order is the order of the extracted values)
Let's see an example. Assuming you have the contents of the following cache within a particular extension storage node:
A--> Object (PositionX = 5,...)
B--> object (getA = 3,...)
C--> object (getA = 3,...)
D--> object (getA = 4,...)The index forward in this node will contain:
Binary (A)--> 5
Binary (B)--> 3
Binary (C)--> 3
Binary (D)--> 4The reverse index will contain:
3--> {Binary (B), Binary (C)}
4--> {Binary (D)}
5--> {Binary (A)}Where Binary (...) designates the internal representation (binary) of the... object.
If the index is not ordered, then the order of iteration over the entries in the index reversed are not deterministic.
If the index is ordered, the iteration of the entries into the inverted index will be as stated above. Also, you can convert the SortedMap inverted index in order to have the very useful headMap and tailMap and firstKey and lastKey methods.
I hope this helps.
Best regards
Robert
-
Why a method to create a constraint would allow the index to be used, but not another.
Hi all
With the help of:
Oracle Database 11 g Enterprise Edition Release 11.2.0.4.0 - 64 bit Production
SQL Developer Version 4.0.2.15
I had to do the following query on a table.
Select distinct chdrnum, tranno
of ractpf_pgr;
I ran the setup of SQL in SQL Developer, who told me that he was doing a full table scan,
(It's what you get using SEPARATE!)
After some research, I discovered that if I put in question on columns not null check constraints
and then recreated the index based on these columns, I'd get a full index scan instead of a table scan.
Good news - off, I went and tried using the following method (I think it's call a constraint of out-of-line)
and created one for each colmn using snytax below.
ALTER table RACTPF_PGR add constraint CS_CHDRNUM_NN check (CHDRNUM is not null) validate;
Ran my SQL Tuning Advisor again - no joy - a full table scan that was happening.
Did some more research and recreated the constraints with the help of an online method
ALTER TABLE RACTPF_PGR CHANGE (CHDRNUM CONSTRAINT CS_CHDRNUM_NN NOT NULL);
My SQL Tuning Advisor is represented - and yes the index was used.
But what I want to know why a method would cause the index to use another does not
Thanks in advance.
The second is a NOT NULL constraint.
The a ('is not null') is technically not a NOT NULL constraint.
Give me a moment to start my database, and I will demonstrate.
Edit: Here's the demo:
SQL> create table x (a number null, b number null); Table created. SQL> alter table x add constraint a_nn check(a is not null) validate; Table altered. SQL> alter table x modify (b constraint b_nn not null); Table altered. SQL> select column_name, nullable 2 from user_tab_cols 3 where table_name = 'X'; COLUMN_NAME ---------------------------------------------------------------------- N - B N A Y
The index does not store registrations for the lines where all components of the index are null, then the optimizer needs to see that the columns are not nullable to be able to use an index scan.
-
The identical query, unusable performance in an environment - please help
We strive to improve 10.2.0.4 to 11.2.0.2, but one of our considered requests is completely wrong (30 seconds in our current environment, 4000 in our upgraded environment).
Note that the caveat is that it will be very difficult for me to edit the SQL code (his coming of another group of TI, as well as their position is that he should not have to be changed given the fact that it works so well in the current production environment).
The query is exactly the same in both environments and transports the SQL_ID, but explain the plans are different.
The environment in which the application works is version 10.2.0.4 and time the trace is 30,15 seconds, 841 rows returned.
The new environment is 11.2.0.2, the elapsed time is 4035 seconds, 841 rows returned.
The environments are comparable in terms of CPU/memory/IO (the two are written for on our NetApp NFS mounts)
SGA_MAX/TARGET and PGA_AGGREGATE_TARGET are the same in both environments, as well as HASH_AREA_SIZE and SORT_AREA_SIZE.
The table database is identical, and all of the indexes are the same in both environments. His stats were collected and this behavior has persisted through several reboots of the databases.
I ran traces on statements in both environments and the performance difference seems to be due to direct path read/write temp:
The SQL
New environment (11.2.0.2), takes 4000 seconds according to tkprofSELECT DISTINCT a.emplid, a.name, rds.sa_get_stdnt_email_fn (a.emplid), a.req_term, a.req_term_ldesc, CASE WHEN (a.req_acad_plan = 'PKINXXXBBS' AND a.cum_gpa >= d.gpa) THEN NVL (c.num_met, 0) + 1 WHEN (b.gpa >= d.gpa AND a.req_acad_plan <> 'PKINXXXBBS') THEN NVL (c.num_met, 0) + 1 ELSE NVL (c.num_met, 0) END AS "Requirement Status", a.cum_total_passed AS "Cumulative Units", a.admit_term, a.admit_term_ldesc, a.acad_plan, a.acad_plan_ldesc, a.academic_level, a.academic_level_ldesc, TO_CHAR (a.rpt_date, 'MM/DD/YYYY') AS rpt_date, TO_CHAR (NVL (b.gpa, 0), '0.000') AS gpa, TO_CHAR (NVL (a.cum_gpa, 0), '0.000') AS cum_gpa FROM sa.rec_sm_stdnt_deg_completion a, ( SELECT DISTINCT CASE WHEN SUM (b_sub.units_earned) = 0 THEN 0 ELSE SUM (b_sub.grade_points) / SUM (b_sub.units_earned) END AS gpa, b_sub.emplid, b_sub.acad_career, b_sub.acad_plan, b_sub.req_acad_plan, b_sub.req_term, b_sub.academic_level, b_sub.rqrmnt_group FROM sa.rec_sm_stdnt_deg_completion b_sub, hrsa_extr.ps_rq_grp_tbl g3, hrsa_extr.ps_rq_main_tbl m3 WHERE b_sub.req_acad_plan IS NOT NULL AND b_sub.acad_career = 'UGRD' AND b_sub.acad_prog = 'UBACH' AND b_sub.acad_plan = b_sub.req_acad_plan AND b_sub.grade <> 'IP' AND b_sub.impact_flag = 'Y' AND g3.effdt = (SELECT MAX (g3_ed.effdt) FROM hrsa_extr.ps_rq_grp_tbl g3_ed WHERE g3_ed.rqrmnt_group = g3.rqrmnt_group AND g3_ed.effdt <= b_sub.req_term_begin_date) AND g3.rqrmnt_group = b_sub.rqrmnt_group AND m3.effdt = (SELECT MAX (m3_ed.effdt) FROM hrsa_extr.ps_rq_main_tbl m3_ed WHERE m3_ed.requirement = m3.requirement AND m3_ed.effdt <= b_sub.req_term_begin_date) AND m3.requirement = b_sub.requirement GROUP BY b_sub.emplid, b_sub.acad_career, b_sub.acad_plan, b_sub.req_acad_plan, b_sub.req_term, b_sub.academic_level, b_sub.rqrmnt_group) b, ( SELECT c_sub.emplid, c_sub.acad_career, c_sub.acad_plan, c_sub.req_acad_plan, c_sub.req_term, c_sub.academic_level, c_sub.rqrmnt_group, COUNT (*) AS num_met FROM sa.rec_sm_stdnt_deg_completion c_sub, hrsa_extr.ps_rq_grp_tbl g2, hrsa_extr.ps_rq_main_tbl m2 WHERE c_sub.rqrmnt_line_status = 'COMP' AND c_sub.grade <> 'IP' AND c_sub.impact_flag = 'Y' AND c_sub.acad_career = 'UGRD' AND c_sub.acad_prog = 'UBACH' AND c_sub.acad_plan = c_sub.req_acad_plan AND g2.effdt = (SELECT MAX (g2_ed.effdt) FROM hrsa_extr.ps_rq_grp_tbl g2_ed WHERE g2_ed.rqrmnt_group = g2.rqrmnt_group AND g2_ed.effdt <= c_sub.req_term_begin_date) AND g2.rqrmnt_group = c_sub.rqrmnt_group AND m2.effdt = (SELECT MAX (m2_ed.effdt) FROM hrsa_extr.ps_rq_main_tbl m2_ed WHERE m2_ed.requirement = m2.requirement AND m2_ed.effdt <= c_sub.req_term_begin_date) AND m2.requirement = c_sub.requirement GROUP BY c_sub.emplid, c_sub.acad_career, c_sub.acad_plan, c_sub.req_acad_plan, c_sub.req_term, c_sub.academic_level, c_sub.rqrmnt_group) c, hrsa_extr.ps_smo_rdr_imp_pln d, hrsa_extr.ps_rq_grp_tbl g, hrsa_extr.ps_rq_main_tbl m WHERE a.acad_career = 'UGRD' AND a.acad_prog = 'UBACH' AND a.req_acad_plan IN (N'NUPPXXXBBS', N'NURPBASBBS', N'NURPXXXBBS') AND a.academic_level IN (N'10', N'20', N'30', N'40', N'50', N'GR') AND a.acad_plan = a.req_acad_plan AND a.impact_flag = 'Y' AND g.effdt = (SELECT MAX (g_ed.effdt) FROM hrsa_extr.ps_rq_grp_tbl g_ed WHERE g_ed.rqrmnt_group = g.rqrmnt_group AND g_ed.effdt <= a.req_term_begin_date) AND g.rqrmnt_group = a.rqrmnt_group AND m.effdt = (SELECT MAX (m_ed.effdt) FROM hrsa_extr.ps_rq_main_tbl m_ed WHERE m_ed.requirement = m.requirement AND m_ed.effdt <= a.req_term_begin_date) AND m.requirement = a.requirement AND a.emplid = b.emplid(+) AND a.acad_career = b.acad_career(+) AND a.acad_plan = b.acad_plan(+) AND a.req_acad_plan = b.req_acad_plan(+) AND a.academic_level = b.academic_level(+) AND a.req_term = b.req_term(+) AND a.rqrmnt_group = b.rqrmnt_group(+) AND a.emplid = c.emplid(+) AND a.acad_career = c.acad_career(+) AND a.acad_plan = c.acad_plan(+) AND a.req_acad_plan = c.req_acad_plan(+) AND a.academic_level = c.academic_level(+) AND a.req_term = c.req_term(+) AND a.rqrmnt_group = c.rqrmnt_group(+) AND d.acad_plan = a.req_acad_plan ORDER BY 6 DESC, 2 ASC;
Explain planPLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------- Plan hash value: 4117596694 ------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 314 | 15231 (1)| 00:03:03 | | 1 | SORT UNIQUE | | 1 | 314 | 15230 (1)| 00:03:03 | | 2 | NESTED LOOPS OUTER | | 1 | 314 | 15227 (1)| 00:03:03 | | 3 | NESTED LOOPS OUTER | | 1 | 285 | 15216 (1)| 00:03:03 | | 4 | NESTED LOOPS | | 1 | 256 | 15205 (1)| 00:03:03 | | 5 | NESTED LOOPS | | 1 | 241 | 15204 (1)| 00:03:03 | | 6 | NESTED LOOPS | | 1 | 223 | 15203 (1)| 00:03:03 | | 7 | NESTED LOOPS | | 17 | 731 | 15186 (1)| 00:03:03 | | 8 | VIEW | VW_SQ_3 | 998 | 27944 | 15186 (1)| 00:03:03 | | 9 | HASH GROUP BY | | 998 | 62874 | 15186 (1)| 00:03:03 | | 10 | MERGE JOIN | | 29060 | 1787K| 15184 (1)| 00:03:03 | | 11 | SORT JOIN | | 26 | 1248 | 15180 (1)| 00:03:03 | | 12 | TABLE ACCESS BY INDEX ROWID | REC_SM_STDNT_DEG_COMPLETION | 26 | 1248 | 15179 (1)| 00:03:03 | |* 13 | INDEX SKIP SCAN | REC0SM_STDNT_DEG_IDX | 26 | | 15168 (1)| 00:03:03 | |* 14 | SORT JOIN | | 1217 | 18255 | 4 (25)| 00:00:01 | | 15 | INDEX FAST FULL SCAN | PS3RQ_GRP_TBL | 1217 | 18255 | 3 (0)| 00:00:01 | |* 16 | INDEX UNIQUE SCAN | PS_RQ_GRP_TBL | 1 | 15 | 0 (0)| 00:00:01 | |* 17 | TABLE ACCESS BY USER ROWID | REC_SM_STDNT_DEG_COMPLETION | 1 | 180 | 1 (0)| 00:00:01 | |* 18 | INDEX RANGE SCAN | PS_RQ_MAIN_TBL | 1 | 18 | 1 (0)| 00:00:01 | | 19 | SORT AGGREGATE | | 1 | 18 | | | | 20 | FIRST ROW | | 1 | 18 | 2 (0)| 00:00:01 | |* 21 | INDEX RANGE SCAN (MIN/MAX) | PS_RQ_MAIN_TBL | 1 | 18 | 2 (0)| 00:00:01 | |* 22 | INDEX FULL SCAN | PS0SMO_RDR_IMP_PLN | 1 | 15 | 1 (0)| 00:00:01 | |* 23 | VIEW PUSHED PREDICATE | | 1 | 29 | 11 (19)| 00:00:01 | | 24 | SORT GROUP BY | | 1 | 52 | 11 (19)| 00:00:01 | | 25 | VIEW | VM_NWVW_5 | 1 | 52 | 10 (10)| 00:00:01 | |* 26 | FILTER | | | | | | | 27 | SORT GROUP BY | | 1 | 165 | 10 (10)| 00:00:01 | |* 28 | FILTER | | | | | | | 29 | NESTED LOOPS | | 1 | 165 | 7 (0)| 00:00:01 | | 30 | NESTED LOOPS | | 1 | 147 | 6 (0)| 00:00:01 | | 31 | NESTED LOOPS | | 1 | 117 | 5 (0)| 00:00:01 | |* 32 | TABLE ACCESS BY INDEX ROWID | REC_SM_STDNT_DEG_COMPLETION | 1 | 90 | 4 (0)| 00:00:01 | |* 33 | INDEX RANGE SCAN | REC1SM_STDNT_DEG_IDX | 1 | | 3 (0)| 00:00:01 | |* 34 | INDEX RANGE SCAN | PS_RQ_GRP_TBL | 1 | 27 | 1 (0)| 00:00:01 | | 35 | SORT AGGREGATE | | 1 | 15 | | | | 36 | FIRST ROW | | 1 | 15 | 2 (0)| 00:00:01 | |* 37 | INDEX RANGE SCAN (MIN/MAX)| PS_RQ_GRP_TBL | 1 | 15 | 2 (0)| 00:00:01 | |* 38 | INDEX RANGE SCAN | PS_RQ_MAIN_TBL | 1 | 30 | 1 (0)| 00:00:01 | |* 39 | INDEX RANGE SCAN | PS_RQ_MAIN_TBL | 1 | 18 | 1 (0)| 00:00:01 | |* 40 | VIEW PUSHED PREDICATE | | 1 | 29 | 11 (19)| 00:00:01 | | 41 | SORT GROUP BY | | 1 | 32 | 11 (19)| 00:00:01 | | 42 | VIEW | VM_NWVW_4 | 1 | 32 | 10 (10)| 00:00:01 | |* 43 | FILTER | | | | | | | 44 | SORT GROUP BY | | 1 | 166 | 10 (10)| 00:00:01 | |* 45 | FILTER | | | | | | |* 46 | FILTER | | | | | | | 47 | NESTED LOOPS | | 1 | 166 | 7 (0)| 00:00:01 | | 48 | NESTED LOOPS | | 1 | 148 | 6 (0)| 00:00:01 | | 49 | NESTED LOOPS | | 1 | 118 | 5 (0)| 00:00:01 | |* 50 | INDEX RANGE SCAN | PS_RQ_GRP_TBL | 1 | 27 | 2 (0)| 00:00:01 | |* 51 | TABLE ACCESS BY INDEX ROWID | REC_SM_STDNT_DEG_COMPLETION | 1 | 91 | 3 (0)| 00:00:01 | |* 52 | INDEX RANGE SCAN | REC1SM_STDNT_DEG_IDX | 1 | | 2 (0)| 00:00:01 | |* 53 | INDEX RANGE SCAN | PS_RQ_MAIN_TBL | 1 | 30 | 1 (0)| 00:00:01 | |* 54 | INDEX RANGE SCAN | PS_RQ_MAIN_TBL | 1 | 18 | 1 (0)| 00:00:01 | | 55 | SORT AGGREGATE | | 1 | 15 | | | | 56 | FIRST ROW | | 1 | 15 | 2 (0)| 00:00:01 | |* 57 | INDEX RANGE SCAN (MIN/MAX) | PS_RQ_GRP_TBL | 1 | 15 | 2 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------------------------------call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 6.59 6.66 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 1521.36 4028.91 2256624 240053408 0 841 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 1527.95 4035.57 2256624 240053408 0 841
The current production (10.2.0.4), takes 30 secondsElapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 2 0.00 0.00 Disk file operations I/O 3 0.07 0.11 db file sequential read 10829 0.12 16.62 direct path write temp 72445 0.30 293.71 direct path read temp 72445 0.58 2234.14 asynch descriptor resize 22 0.00 0.00 SQL*Net more data to client 9 0.00 0.00 SQL*Net message from client 2 0.84 1.25 ********************************************************************************PLAN_TABLE_OUTPUT ------------------------------------------------------------------------------------------------------------------------- Plan hash value: 2178773127 ------------------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 331 | 89446 (2)| 00:17:54 | | 1 | SORT UNIQUE | | 1 | 331 | 89445 (2)| 00:17:54 | | 2 | NESTED LOOPS | | 1 | 331 | 89440 (2)| 00:17:54 | | 3 | NESTED LOOPS | | 1 | 316 | 89439 (2)| 00:17:54 | |* 4 | HASH JOIN OUTER | | 1 | 298 | 89438 (2)| 00:17:54 | |* 5 | HASH JOIN OUTER | | 1 | 240 | 59625 (2)| 00:11:56 | | 6 | NESTED LOOPS | | 1 | 182 | 29815 (2)| 00:05:58 | |* 7 | TABLE ACCESS FULL | REC_SM_STDNT_DEG_COMPLETION | 1 | 167 | 29814 (2)| 00:05:58 | |* 8 | INDEX FULL SCAN | PS0SMO_RDR_IMP_PLN | 1 | 15 | 1 (0)| 00:00:01 | | 9 | VIEW | | 1 | 58 | 29809 (2)| 00:05:58 | | 10 | HASH GROUP BY | | 1 | 71 | 29809 (2)| 00:05:58 | | 11 | VIEW | | 1 | 71 | 29809 (2)| 00:05:58 | |* 12 | FILTER | | | | | | | 13 | HASH GROUP BY | | 1 | 198 | 29809 (2)| 00:05:58 | | 14 | NESTED LOOPS | | 1 | 198 | 29806 (2)| 00:05:58 | |* 15 | HASH JOIN | | 1 | 171 | 29805 (2)| 00:05:58 | |* 16 | HASH JOIN | | 4 | 572 | 29802 (2)| 00:05:58 | |* 17 | TABLE ACCESS FULL | REC_SM_STDNT_DEG_COMPLETION | 4 | 452 | 29798 (2)| 00:05:58 | | 18 | INDEX FAST FULL SCAN | PS2RQ_MAIN_TBL | 1035 | 31050 | 3 (0)| 00:00:01 | | 19 | INDEX FAST FULL SCAN | PS2RQ_MAIN_TBL | 1035 | 28980 | 3 (0)| 00:00:01 | |* 20 | INDEX RANGE SCAN | PS_RQ_GRP_TBL | 1 | 27 | 1 (0)| 00:00:01 | | 21 | SORT AGGREGATE | | 1 | 15 | | | | 22 | FIRST ROW | | 1 | 15 | 2 (0)| 00:00:01 | |* 23 | INDEX RANGE SCAN (MIN/MAX)| PS_RQ_GRP_TBL | 1 | 15 | 2 (0)| 00:00:01 | | 24 | VIEW | | 1 | 58 | 29813 (2)| 00:05:58 | | 25 | HASH GROUP BY | | 1 | 45 | 29813 (2)| 00:05:58 | | 26 | VIEW | | 1 | 45 | 29813 (2)| 00:05:58 | |* 27 | FILTER | | | | | | | 28 | HASH GROUP BY | | 1 | 199 | 29813 (2)| 00:05:58 | | 29 | NESTED LOOPS | | 1 | 199 | 29810 (2)| 00:05:58 | |* 30 | HASH JOIN | | 1 | 172 | 29809 (2)| 00:05:58 | |* 31 | HASH JOIN | | 8 | 1152 | 29805 (2)| 00:05:58 | |* 32 | TABLE ACCESS FULL | REC_SM_STDNT_DEG_COMPLETION | 7 | 798 | 29802 (2)| 00:05:58 | | 33 | INDEX FAST FULL SCAN | PS2RQ_MAIN_TBL | 1035 | 31050 | 3 (0)| 00:00:01 | | 34 | INDEX FAST FULL SCAN | PS2RQ_MAIN_TBL | 1035 | 28980 | 3 (0)| 00:00:01 | |* 35 | INDEX RANGE SCAN | PS_RQ_GRP_TBL | 1 | 27 | 1 (0)| 00:00:01 | | 36 | SORT AGGREGATE | | 1 | 15 | | | | 37 | FIRST ROW | | 1 | 15 | 2 (0)| 00:00:01 | |* 38 | INDEX RANGE SCAN (MIN/MAX) | PS_RQ_GRP_TBL | 1 | 15 | 2 (0)| 00:00:01 | |* 39 | INDEX RANGE SCAN | PS_RQ_MAIN_TBL | 1 | 18 | 1 (0)| 00:00:01 | | 40 | SORT AGGREGATE | | 1 | 18 | | | | 41 | FIRST ROW | | 1 | 18 | 2 (0)| 00:00:01 | |* 42 | INDEX RANGE SCAN (MIN/MAX) | PS_RQ_MAIN_TBL | 1 | 18 | 2 (0)| 00:00:01 | |* 43 | INDEX RANGE SCAN | PS_RQ_GRP_TBL | 1 | 15 | 1 (0)| 00:00:01 | | 44 | SORT AGGREGATE | | 1 | 15 | | | | 45 | FIRST ROW | | 1 | 15 | 2 (0)| 00:00:01 | |* 46 | INDEX RANGE SCAN (MIN/MAX) | PS_RQ_GRP_TBL | 1 | 15 | 2 (0)| 00:00:01 | ------------------------------------------------------------------------------------------------------------------------call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 1.49 1.51 0 0 0 0 Execute 1 0.00 0.00 0 0 0 0 Fetch 2 18.25 28.63 463672 932215 0 836 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 19.75 30.15 463672 932215 0 836
Published by: ngilbert on June 26, 2012 16:40Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- ------------ SQL*Net message to client 2 0.00 0.00 db file scattered read 14262 0.31 13.13 latch: shared pool 1 0.01 0.01 db file sequential read 7 0.00 0.00 direct path write temp 493 0.00 0.00 direct path read temp 493 0.00 0.00 SQL*Net more data to client 40 0.00 0.00 SQL*Net message from client 2 0.83 1.23 ********************************************************************************
Published by: ngilbert on June 26, 2012 16:41Hello
as is almost always the case, your bad plan is the result of messed up the cardinality estimates. The biggest problem seems to be the cardinality in steps 12 and 13 of the bad plan:
| 12 | TABLE ACCESS BY INDEX ROWID | REC_SM_STDNT_DEG_COMPLETION | 26 | 1248 | 15179 (1)| 00:03:03 | |* 13 | INDEX SKIP SCAN | REC0SM_STDNT_DEG_IDX | 26 | | 15168 (1)| 00:03:03 |that is the estimated cardinality is 26. But if we look at the map, we see that the actual number of lines is 4 orders of magnitude (!) higher than that. So of course this goes wrong from there: the optimizer uses weird join methods, wrong join order etc.
And if we look at the predicate:
13 - access("A"."ACAD_CAREER"='UGRD' AND "A"."ACAD_PROG"='UBACH' AND "A"."IMPACT_FLAG"='Y') filter("A"."ACAD_PLAN"="A"."REQ_ACAD_PLAN" AND "A"."ACAD_PROG"='UBACH' AND "A"."IMPACT_FLAG"='Y' AND "A"."ACAD_CAREER"='UGRD')We can assume that the problem is related to the related predicates: you select lines of tables with 4 equality predicates, but 260 k lines survive this filtering. The optimizer thinks that it is closer to 26, not 260 k, but it's probably because the predicates are not really independent.
There is another thing that seems suspicious: filter predicate is redundant with the predicates of access. There is another discussion on OTN not so long ago, and it turned out to be a symptom of a bug (which makes it even more suspect, is that it was also a SKIP SCAN). See:
Re: CBO does not consider cheaper NL-Plan without guidance
Hope that was helpful.
Best regards
Nikolai -
calculate vs believe the index statistics
Hello
No one knows what criteria can be used to evaluate when it is necessary to calculate statistics vs statistical estimate on an index?
I'm in a situation where I'd like to collect statistics on all indexes of production DB. The indexes are on the tables that vary considerably in size from very small (< 10 records) to the very large (> 150 million records). Based on previous experience, I think stats estimate would be appropriate on the index of the largest tables and computer stats would be appropriate on the indexes of smaller tables. The reason to be here, it is that when I tried to compute statistics on major indexes, it took several hours to complete each. It was not ideal because I have a small window to calculate the index statistics. Alternatively, there are some indexes of average size that is currently estimated, and I'm fairly certain they would benefit calculation of stats.
I thought that I had read a few Oracle somewhere documentation that explains how to evaluate when it is appropriate to calculate the estimate of the vs, but I can't seem to find it.
EDIT: I should mention that it's in a DB 10 gr 2 (10.2.0.3)
Advice or assistance in this matter would be greatly appreciated.
Thank you very much.
Published by: x94qvi on November 14, 2010 19:02Hello
Please read these articles by Tom, who will give you a clear understanding between calculation vs estimate for any object can be a table or index
http://asktom.Oracle.com/pls/asktom/f?p=100:11:0:P11_QUESTION_ID:432169917482
http://download.Oracle.com/docs/CD/B19306_01/server.102/b14211/stats.htm
Thank you
Published by: CKPT November 15, 2010 08:21
-
Do not adjust despite the advice of the index
Hi allIts Oracle 10g Release 10.2.0.4.0
I have this query in which there are indexes on the instrument table like this:
I tried all possible ways, but none of the indices are used to causing complete this table table scans. I need advice on how can I avoid this FTS, so the query can run fast and use the index on the table of the Instrument:Instrument: idx 1 : (INSTRUMENT_ID, END_COB_DATE, CLOSE_ACTION_ID, PRODUCT_SUB_TYPE_ID, BEGIN_COB_DATE) idx 2 : ( INSTRUMENT_ID, INSTRUMENT_VN, END_COB_DATE, CLOSE_ACTION_ID) idx 3 : (CLOSE_ACTION_ID, END_COB_DATE)
query:
It is the execution planselect distinct i.instrument_id, i.name, case when (mn2.display_name != 'DEBT PRIORITY CLASS' and mn2.display_name is not null) then mn2.display_name else mn1.display_name end "DEBT_PRIORITY_CLASS" from instrument i, inst_debt id left join marsnode mn1 on (id.debt_priority_class_id = mn1.node_id and mn1.close_date is null and mn1.type_id = 58412926883279) left join marsnodelink mnl1 on (mn1.node_id = mnl1.node_id and mnl1.close_date is null and mnl1.begin_cob_date <= TO_DATE('27-Oct-2010', 'DD-Mon-YYYY') and mnl1.end_cob_date > TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')) left join marsnode mn2 on (mnl1.parent_id = mn2.node_id and mn2.close_date is null and mn2.type_id = 58412926883279) where i.instrument_id = id.instrument_id and i.instrument_vn = id.instrument_vn AND i.end_cob_date > TO_DATE('27-Oct-2010', 'DD-Mon-YYYY') AND i.close_action_id is null AND i.product_sub_type_id = 3 AND i.begin_cob_date <= TO_DATE('27-Oct-2010', 'DD-Mon-YYYY')
predicate info-------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| -------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 2026K| 407M| | 509K (20)| | 1 | HASH UNIQUE | | 2026K| 407M| 879M| 509K (20)| |* 2 | HASH JOIN RIGHT OUTER | | 2026K| 407M| | 426K (23)| |* 3 | TABLE ACCESS BY INDEX ROWID | MARSNODE | 501 | 23046 | | 239 (3)| |* 4 | INDEX RANGE SCAN | FKI_38576_TYPE_ID | 10159 | | | 34 (6)| |* 5 | HASH JOIN RIGHT OUTER | | 2026K| 318M| | 425K (23)| |* 6 | TABLE ACCESS FULL | MARSNODELINK | 330 | 15510 | | 6560 (16)| |* 7 | HASH JOIN RIGHT OUTER | | 2026K| 228M| | 419K (23)| |* 8 | TABLE ACCESS BY INDEX ROWID| MARSNODE | 501 | 23046 | | 239 (3)| |* 9 | INDEX RANGE SCAN | FKI_38576_TYPE_ID | 10159 | | | 34 (6)| |* 10 | HASH JOIN | | 2026K| 139M| 34M| 418K (23)| | 11 | TABLE ACCESS FULL | INST_DEBT | 1031K| 22M| | 1665 (30)| *|* 12 | TABLE ACCESS FULL | INSTRUMENT | 2062K| 96M| | 413K (23)|* --------------------------------------------------------------------------------------------------
Kind regards2 - access("MNL1"."PARENT_ID"="MN2"."NODE_ID"(+)) 3 - filter("MN2"."CLOSE_DATE"(+) IS NULL) 4 - access("MN2"."TYPE_ID"(+)=58412926883279) 5 - access("MN1"."NODE_ID"="MNL1"."NODE_ID"(+)) 6 - filter("MNL1"."CLOSE_DATE"(+) IS NULL AND "MNL1"."END_COB_DATE"(+)>TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "MNL1"."BEGIN_COB_DATE"(+)<=TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 7 - access("ID"."DEBT_PRIORITY_CLASS_ID"="MN1"."NODE_ID"(+)) 8 - filter("MN1"."CLOSE_DATE"(+) IS NULL) 9 - access("MN1"."TYPE_ID"(+)=58412926883279) 10 - access("I"."INSTRUMENT_ID"="ID"."INSTRUMENT_ID" AND "I"."INSTRUMENT_VN"="ID"."INSTRUMENT_VN") 12 - filter("I"."PRODUCT_SUB_TYPE_ID"=3 AND "I"."CLOSE_ACTION_ID" IS NULL AND "I"."END_COB_DATE">TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "I"."BEGIN_COB_DATE"<=TO_DATE(' 2010-10-27 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
AashishAashish S. wrote:
I tried all the possible ways but none of the indexes are getting used causing full table scans of this table. I need some guidance on how can I avoid this FTS so the query can run fast and use the index on Instrument table:I guess that the last part of the statement above is what you really need reach (i.e. improve the execution time of the query) and the query not using index is what you think as the 'cause' for the real "problem". I will try to answer the real 'problem '. Based on what you've posted, some comments/suggestions
(1) your plan shows that the query should recover 2026 K lines. Are you sure you want to recover as many files? You can come back here on the "requirement".
(2) continuous superior point-to-point, you can view the details of how long takes the query to run to the present and how long do you expect to take. Another of the most important details will be how will you measure the runtime of the query. With this large number of records, it is quite possible that more time is spent by simply transferring the results of the query to the 'client' that the actual time taken by server to run the query.
(3) if what you posted is the order of the columns in the index on the table with INSTRUMENTS, then what evidence do will help you to run the query and how? The order of the columns indicate that none of the clues will be good enough and that seems to be the right choice.
(4) your section descriptor States that filter the predicate on table to INSTRUMENTS generates 2062 K lines. The number of records exist in the table of the INSTRUMENT? You will need to have a record much more (not to mention other factors like the order of data in the table etc.) in the table to justify the indexed access to pick up these huge number of lines.
(5) Finally, you can check if the tables and indexes used by the query statistics are up to date.I hope this helps.
-
ways of optimizing bit every night it is still the index fragmentation
Nice day
I am fairly new to the Oracle text and have read a lot of documentation. I inherited, a system that is running the synchronization of the work every 5 minutes and the optimization of the text indexes every night. It seems that all is well until I do a check of the index with the CTX_REPORT. It seems that the indexes are fragmented again. We are running Oracle 10.2.0.4.1 on Solaris 10. I have rebuilt the index and which will remove fragmentation, but I thought that the optimization work this treat every night. I have attached a log of an index I on a training Server (sorry I can't post my production server data), but it is also the case on my production server as well (same hardware / software). This was improved to 8i a few years ago so I don't know if something is not respected during the upgrade or if this is normal behavior. I am now the validity of jobs sync as well. Any help at this point would be appreciated. I am looking to rebuild all indexes at this point (yes - I've read all the advantages and disadvantages). I also read that right. Should I be concerned with the fragmentation of line al all. I removed the display chips to save space.
Thanks in advance for your help
Ray
--------------------------------------------------------------------------------
SQL > declare
2 x clob: = null;
3. start
4 ctx_report.index_stats('ACIIS_AB00_USER.) CTX_REMARKS_IDX', x);
5. insert into output values (x);
6 validation;
7 dbms_lob.freetemporary (x);
8 end;
9.
PL/SQL procedure successfully completed.
SQL > set long 32000
SQL > set off head
SQL > set pagesize 10000
SQL > select * output;
===========================================================================
STATISTICS FOR THE 'ACIIS_AB00_USER '. "" CTX_REMARKS_IDX ".
===========================================================================
Indexing of documents: 154
allocated docids: 154
$I lines: 6 786
---------------------------------------------------------------------------
STATISTICS OF TOKEN
---------------------------------------------------------------------------
Let's take unique: 649
average $I by token lines: 10.46
chips with most $I lines:
statistics by type of token:
token of type: 0:TEXT
Let's take unique: 649
Total lines: 6 786
average lines: 10.46
total size: 36 528 (35,67 KB)
average size: 56
average frequency: 18.21
---------------------------------------------------------------------------
FRAGMENTATION STATISTICS
---------------------------------------------------------------------------
total area of data $I: 36 528 (35,67 KB)
$I lines: 6 786
$I lines considered if optimal: 652
estimated row fragmentation: 90%
garbage docids: 0
projected size of garbage: 0
more fragmented chips:
780 (0:TEXT) 100%
555 (0:TEXT) 1
SQL > START
2 ctx_ddl.sync_index('ACIIS_AB00_USER.) CTX_REMARKS_IDX');
3 end;
4.
PL/SQL procedure successfully completed.
SQL > truncate the output of the table;
Table truncated.
SQL > declare
2 x clob: = null;
3. start
4 ctx_report.index_stats('ACIIS_AB00_USER.) CTX_REMARKS_IDX', x);
5. insert into output values (x);
6 validation;
7 dbms_lob.freetemporary (x);
8 end;
9.
PL/SQL procedure successfully completed.
SQL > select * output;
===========================================================================
STATISTICS FOR THE 'ACIIS_AB00_USER '. "" CTX_REMARKS_IDX ".
===========================================================================
Indexing of documents: 154
allocated docids: 154
$I lines: 6 786
---------------------------------------------------------------------------
STATISTICS OF TOKEN
---------------------------------------------------------------------------
Let's take unique: 649
average $I by token lines: 10.46
average frequency per token: 18.21
---------------------------------------------------------------------------
FRAGMENTATION STATISTICS
---------------------------------------------------------------------------
total area of data $I: 36 528 (35,67 KB)
$I lines: 6 786
$I lines considered if optimal: 652
estimated row fragmentation: 90%
garbage docids: 0
projected size of garbage: 0
more fragmented chips:
780 (0:TEXT) 100%
555 (0:TEXT) 1
SQL > spo offRay,
above all, you started the optimization of a sessionwhere work NLS_LANGUAGE/NLS_LANG is not American and are facing a bug 2544938to 11.2
For a workaround, see the Note 223465.1 .Thank you
Edwin -
Hello world
IAM having a det_rec table (direction of history date, identification number, number of rec_id...) which the index on the first three columns.
How below select stmt will use the index?
Select * from det_rec where s hist = sysdate;
with EXPLAIN PLAN that he uses RANGE SCAN instead of use the index? how the index will be off when we conduct this type of index?
Thanks and greetings
Murali.AJR says:
HelloThe Index will work if all three columns in the index are filtered to the place where the query clause.
Kind regards
AJRWhat a wrong answer.
If you have a table with columns a, b, c, d, and you have a compound of the index on a, b, c, the index can be used on the following condition.
(1) one
(2) a, b
(3) a, b, cAnd with the introduction of skip scan limited index that the index can be used even in the first column is skiped. Like this
(1) b, c
(2) c -
My both hands, index fingers. which are based on the computer next to the trackpad or are used on the trackboard are painful, feel like they were burnt, and I can barely move them. I do not have this problem before, I bought my new Mac - specifications below: it hurts and I don't have a problem with my windows, iPad or Samsung Galaxy equipment operating systems computers.
It feels like radiation leaking through the computer case. Is the radiation involved in the chips?
MacBook Pro
Model identifier: MacBookPro11, 4
Processor name: Intel Core i7
Processor speed: 2.2 GHz
Number of processors: 1
Total number of Cores: 4
(By heart) L2 Cache: 256 KB
L3 Cache: 6 MB
Memory: 16 GB
Boot ROM version: MBP114.0172.B06
Version of the SCM (System): 2.29f24
Are you use while plugged in, I feel a buzzing in my 13-inch rMBP (12.1)
Maybe you are looking for
-
We bought a new laptop to Windows 8. I used Windows Easy Transfer to transfer data from the old laptop to the new laptop. Now, my wife, saved bookmarks passwords and other custom settings do not appear on the new laptop. I do not know if Windows Easy
-
After the upgrade of Firefox all my favorites icons disappear.
After release of the next version of Firefox, all my favorites have lost their icons. To restore an icon I have to click this bookmark and load a web pade again. Brings back an icon.But I have so many icons that I can't go just by each of them.I appr
-
I had upgraded to windows 10 8.1 about 20 days back, but now I don't like the outlook and my system also became slow so I thought to go back to windows 8.1. My laptop gives error 0xc0000225. Please help urgently.
-
Question related to the backup server
I have Dell server, but my Raid card fails. I want to take backup of my data.
-
Run MS-DOS programs in Windows 7
In Windows XP, I used a command mode to display my MS-DOS mode programs full screen. The command was con passes Mode = 80 rows = 25. This does not work in Windows 7 in XP Mode. Instead, the display flashes and displays my programs on 1/4 of the sc