Index isssue again

Hi
i have an index on my ods table . this index consists of fields a and b .
however , in most queries i use a selection only on field a
1) How can i ensure if the index on a and b is being used during query execution ?
2) if i create an additional index only on field a , will it be an added advantage ?
3) if both my indexes exist simultaneosly ( on eon field a and one on field a and b ) ,
is that bad from a performance perspective ?
All inputs welcome

Hi,
Say, a & b are your key fields of the ODS and by default index is present on a & b. But that does not mean that if you give only value for a; index will work..index will work only if you provide both the values. If you want to give only value for a and the result should come faster then you need to create secondary index. Hence if you are going to provide only value for a more frequently then creating an additional index only on field a is an advantage. Performance is not bad if both the indexes exist but maintenance cost is high on indexes.
PB

Similar Messages

Why Indexing Rebuild Again and Again

Hi Team,
I am facing issue outlook stander ed edition 2010 indexing rebuilding again and again on local system due to this unable to search old email it happens twice in a week or in two days.
Please help me to resolve the same thanks to you all.

Hi,
Please make sure your Outlook is fully patched. And we can try the following changes:
1. Create a new Outlook profile:
http://support.microsoft.com/kb/829918
2. Start Outlook in safe mode:
Click Start > Run > Outlook /safe
3. If it doesn’t work, please perform a clean boot in Windows:
http://support.microsoft.com/kb/929135/en-us
4. Then rebuild Indexing in Outlook 2010 until it is complete:
Click File > Options > Search > Indexing Options > Advanced > Rebuild.
Regards,
Winnie Liang
TechNet Community Support

Spatial Index problem again

I have a TAR open and I am awaiting an answer, but the representative is based in Austraila so I am assuming I will not get another answer until tomorrow, so hopefully someone can see what I have going on and can offer some advice (Thanks in advance Dan :-) )
Trying to create my spatial index:
create index locations_test_sidx on locations_test(map_loc_data) indextype is
mdsys.spatial_index
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: internal error [ROWID:AAAJMWAADAAAJsLAEp] in spatial indexing.
ORA-13206: internal error [] while creating the spatial index
ORA-13032: Invalid NULL SDO_GEOMETRY object
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
Our Data in the table looks like the following:
Yuma Proving Ground, AZ SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(32.773,-114.5, NULL), NULL, NULL)
I do not understand why I am getting the ORA-13032 error. From all that I have on documentation my table is created correctly. Here is a script I used to create my Spatial Table, maybe somethng in there will give some pointers as to what is wrong.
Thank you!
declare
lv_loc_id locations.location_id%TYPE;
lv_lat locations.latitude%TYPE;
lv_long locations.longitude%TYPE;
CURSOR loc
IS
SELECT DISTINCT location_id
FROM locations_test
WHERE state IS NOT NULL;
BEGIN
OPEN loc;
LOOP
FETCH loc
INTO lv_loc_id;
EXIT WHEN loc%NOTFOUND;
SELECT latitude,
longitude
INTO
lv_lat,
lv_long
FROM locations_test
WHERE location_id = lv_loc_id;
UPDATE locations_test
SET map_loc_data = MDSYS.SDO_GEOMETRY(
2001,
8307,
MDSYS.SDO_POINT_TYPE(lv_lat,lv_long,NULL),
NULL,
NULL)
WHERE location_id = lv_loc_id;
END LOOP;
CLOSE loc;
END;

Here is the update:
Recreated the Index, YAY no errors!!!
Trying to generate my map though in Mapviewer gives the following:
05/03/30 12:06:42 java.sql.SQLException: ORA-29902: error in executing ODCIIndex Start() routine
ORA-13208: internal error while evaluating [window SRID does not match layer SRID] operator
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
Here is the code that I am generating my map with:
<?xml version="1.0" standalone="yes"?>
<map_request
title="Testing Dynamic Themes"
basemap="Demo_MAP"
datasource ="mvdemo"
width="640"
height="480"
bgcolor="#a6cae0"
antialiase="false"
format="PNG_STREAM">
<center size="45">
<geoFeature
render_style="M.cyan pin"
label="Center" label_always_on="true"
text_style="T.Title" radius="100000">
<geometricProperty>
<point>
<coordinates>-96.2, 39</coordinates>
</point>
</geometricProperty>
</geoFeature>
</center>
<themes>
<theme name="Locations">
<jdbc_query
datasource="mvdemo"
spatial_column="map_loc_data"
render_style="M.STAR"
label_column="CITY"
label_style="T.CITY NAME">
select map_loc_data
from resources.locations_test l
where l.country = 'US'
and l.region_ID = 1
and l.location_id IN (Select distinct d_loc_id from cii.devices)
</jdbc_query>
</theme>
</themes>
</map_request>
this does display a map with a center point, just none of the cities are labeled or displayed.
Here is my USER_SDO_GEOM_METADATA
TABLE_NAME
COLUMN_NAME
DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)
SRID
LOCATIONS_TEST
MAP_LOC_DATA
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('LONGITUDE', -180, 180, .5), SDO_DIM_ELEMENT('LATITUDE', -90, 90, .5))
8307
Here is an example of my data:
LOCATION_ID LOCATION ST LATITUDE LONGITUDE REGION_ID CO
MAP_LOC_DATA(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
6264 NASHUA NH 42.7486 -71.491848 1 US
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-71.491848, 42.7486, NULL), NULL, NULL)
My data looks like the following:

Lost the ability to Spotlight Index my Time Machine drive

I have an external, Firewire Time Machine drive which has been working without problems up to now. This evening I had a backup which hung up in the "preparing" stage (no file transfers begun yet). When I went to look in the console, there was a device error apparently related to trying to detect the powered-on state of my Time Machine drive. Apparently Time Machine did not handle this gracefully. In the course of trying to clear that I got into a state where I had to force shutdown of the system (holding the power button). (I accidentally clicked on the Time Machine icon which got hung up trying to display the histories, and left me with no access to the Desktop....)
Things appeared to check out fine when I brought the machine back up (including Verify Disk of both the main and Time Machine drives and Repair Permissions of the main drive), and I finally did a Back Up Now in Time Machine. Due to the forced shut down, this became a "Deep Traversal" "preparing"stage. We'll I've seen those before, so no worries. However it lasted quite a bit longer than it should, at which point I noticed that Spotlight was indexing the Time Machine drive.
So at this point I dragged the Time Machine into the Spotlight Privacy list. Rather than going away completely as I expected, the indexing of the Time Machine drive apparently went into some sort of clean-up phase that said it was still indexing for another 5 minutes (where it had, just prior, said it was going to be indexing for another 2 hours). The progress bar advanced normally as if it really did do 5 minutes more of indexing of the Time Machine drive. I've not seen this before
When that finished, the backup which had been "preparing" during all of this also finished "preparing", transferred the several MB of files I expected, and finished normally. There were no errors in the console related to any of this.
I rebooted, and once again did a pair of Disk Verifies and a Repair Permissions without problems. Opened up the console to track things, and poked around in the Time Machine. All was normal as far as I can tell. I also explored the Time Machine drive via the Finder. No problems.
So I now went into Spotlight Privacy and removed the Time Machine drive from the privacy list expecting it to do the re-indexing I had stopped above. Spotlight started indexing the drive and a couple seconds later it stopped. I tried again -- into and out of privacy -- same result, a couple seconds of indexing and then it stopped.
At this point I noticed the console was saying I had some bus errors in the I/O system, and that's what was terminating the md worker process and stopping the indexing.
So I shut down, unplugged the Time Machine drive, and went through my maintenance ritual.
I reset the PMU (this is a powerbook), reset PRAM, booted once in Safe Mode, booted normally, and ran Disk Utility again to Verify and Repair Permissions on the main hard drive. All of that went without a hitch. No failures, faults or funnies.
I ran through the list of Applications I use, keeping an eye on the console. Again no problems.
So I shut down, plugged the Time Machine drive back in and booted back up. I put the drive into Spotlight Privacy and turned off Time Machine backups. I then did a Verify Disk on that drive. No problems. I went into the Time Machine history display. No problems. And no problems looking at it in the Finder either. In particular, no bus errors or anything else funny in the console.
I rebooted and did a new Back Up Now. It completed without problems. It was another Deep Traversal backup due to the Safe Mode Boot, but it went without a hitch. I rebooted and did another Back Up Now and got a normal speed incremental backup again without a hitch. The bottom line is that as far as I can see that Time Machine drive is working just fine.
So I went into Spotlight Privacy and removed it from the list. Once again it started to index and stopped in a couple seconds. But this time there were NO Console error messages.
I moved my main hard drive into Spotlight Privacy and removed it and it re-indexed from scratch just fine. Tried again with the Time Machine drive -- indexing stopped in a couple of seconds with no message in the Console. Spotlight searches find all the right stuff in the main drive. Spotlight and finder searches find only the top level Time Machine folders in the Time Machine drive.
I also tried removing the Spotlight plist from my account's Library / Preferences. Spotlight created a new plist as expected but it still won't index that darned Time Machine drive.
Apparently there is something left over from when I originally aborted the Spotlight indexing of that drive which is causing Spotlight to think it has no work to do. I'm not seeing any I/O errors of any sort any more (I think my maintenance pass took care of that) and Time Machine backups and history access continue to work just fine. And again, the Time Machine disk Verifies just fine.
So I've run out of things to try.
Is there a hidden file that I need to remove from that drive so that Spotlight no longer thinks it already has it indexed?
--Bob

Well unfortunately the command
sudo mdutil -E /Volumes/MyDiskName
didn't help.
The command itself echoed the name of the volume and then said "Indexing Enabled", which looked good. But the Spotlight indexing stopped after a couple seconds. The Console reported the Terminal sudo command and nothing else.
I tried moving the Time Machine drive in and out of Spotlight privacy and once again the indexing started and stopped a couple seconds later with no Console messages.
I then tried another trick I've learned to make Spotlight indexing happen which is to do a Finder search for, say, all folders (limited to the one drive) via Command-f and while Including both System Files and files both Visible and Invisible. And indeed Spotlight indexing started but again stopped a few seconds later.
However, this time there were console messages and a crash report.
The Console shows (with personal information x'ed out):
12/31/07 1:30:38 PM mds[28] (/)(Error) IndexCI in openindex_filelazy:open file error: 2, 0.indexGroups
12/31/07 1:30:41 PM ReportCrash[146] Formulating crash report for process mds[28]
12/31/07 1:30:42 PM com.apple.launchd[1] (com.apple.metadata.mds[28]) Exited abnormally: Bus error
12/31/07 1:30:42 PM com.apple.launchd[1] (0x10ba40.mdworker[96]) Exited: Terminated
12/31/07 1:30:42 PM com.apple.launchd[1] (0x1004a0.mdworker[108]) Exited: Terminated
12/31/07 1:30:42 PM mds[147] (/Volumes/Xxxxxx Time Machine/.Spotlight-V100/Store-V1/Stores/80F3EC85-D77A-49FE-8BDC-BB7C3B3EC1CF)(E rror) IndexCI in ContentIndexOpenBulk:Unclean shutdown of /Volumes/Xxxxxx Time Machine/.Spotlight-V100/Store-V1/Stores/80F3EC85-D77A-49FE-8BDC-BB7C3B3EC1CF/0. ; needs recovery
12/31/07 1:30:43 PM ReportCrash[146] Saved crashreport to /Library/Logs/CrashReporter/mds2007-12-31-133038Xxxxxx-Xxxxxx-Computer.crash using uid: 0 gid: 0, euid: 0 egid: 0
The Crash Report reads as follows (again with personal information x'ed out):
Process: mds [28]
Path: /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework /Support/mds
Identifier: mds
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: launchd [1]
Date/Time: 2007-12-31 13:30:38.746 -0500
OS Version: Mac OS X 10.5.1 (9B18)
Report Version: 6
Exception Type: EXCBADACCESS (SIGBUS)
Exception Codes: KERNPROTECTIONFAILURE at 0x0000000000000030
Crashed Thread: 15
Thread 0:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0000cfa0 0x1000 + 49056
5 mds 0x00005580 0x1000 + 17792
Thread 1:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 2:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 3:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 4:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 5:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 6:
0 libSystem.B.dylib 0x92eda3ec _semwaitsignal + 12
1 libSystem.B.dylib 0x92f16fa0 pthread_condwait + 1580
2 mds 0x00009648 0x1000 + 34376
3 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 7:
0 libSystem.B.dylib 0x92ee0ea0 read$UNIX2003 + 12
1 mds 0x000091b4 0x1000 + 33204
Thread 8:
0 libSystem.B.dylib 0x92f15438 kevent + 12
1 mds 0x0007e584 0x1000 + 513412
Thread 9:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 10:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 11:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 12:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 13:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.spotlight.index 0x00207f0c _handleExceptions + 208
3 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 14:
0 libSystem.B.dylib 0x92ed39d8 machmsgtrap + 8
1 libSystem.B.dylib 0x92eda8fc mach_msg + 56
2 com.apple.CoreFoundation 0x90214664 CFRunLoopRunSpecific + 1828
3 mds 0x00059ab8 0x1000 + 363192
4 mds 0x0005987c 0x1000 + 362620
5 com.apple.Foundation 0x969c5d9c _NSThread__main_ + 1004
6 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 15 Crashed:
0 com.apple.spotlight.index 0x002046cc ContentIndexContainsContentByDocId + 204
1 com.apple.spotlight.index 0x00164358 QueryFunctionCallbackContext::findContent(db_obj*, __CFString const*, char*, int) + 244
2 com.apple.spotlight.index 0x001634d0 qpContentIndexMatch(datastoreinfo*, dblazyobj*, query_piece*, void*, int) + 328
3 com.apple.spotlight.index 0x0015587c comparefile_againsttree + 828
4 com.apple.spotlight.index 0x00155d30 comparefile_againsttree + 2032
5 com.apple.spotlight.index 0x00155d5c comparefile_againsttree + 2076
6 com.apple.spotlight.index 0x001e307c -[SISearchCtx isObjectInQuery:withQuery:shortcut:] + 144
7 com.apple.spotlight.index 0x001fa268 -[SISearchCtx_FSWalk performSearch:] + 996
8 com.apple.spotlight.index 0x001e2cbc -[SISearchCtx executeSearchContextCracked_2:jobNum:] + 136
9 com.apple.spotlight.index 0x00177e80 siwork_queueprocess + 752
10 com.apple.spotlight.index 0x0017811c sischeduleronce + 356
11 com.apple.spotlight.index 0x0017816c sischeduleronce + 436
12 com.apple.spotlight.index 0x001784f8 sischeduler_run_waitingtimeout + 640
13 com.apple.spotlight.index 0x0016529c runLoop + 72
14 com.apple.spotlight.index 0x00165308 query_runLoop + 32
15 libSystem.B.dylib 0x92f15bf8 pthreadstart + 316
Thread 15 crashed with PPC Thread State 32:
srr0: 0x002046cc srr1: 0x0200f030 dar: 0x00000030 dsisr: 0x40000000
r0: 0x002046a4 r1: 0xf09a4380 r2: 0x00000000 r3: 0x00000000
r4: 0xf09a43c0 r5: 0x00000000 r6: 0x000074d1 r7: 0x00000000
r8: 0x003fc080 r9: 0x00000000 r10: 0x00000000 r11: 0x44000444
r12: 0x92ede094 r13: 0x00000000 r14: 0x00000000 r15: 0x00373410
r16: 0x00000000 r17: 0x00239e98 r18: 0x00000001 r19: 0x00227b9c
r20: 0x00000000 r21: 0x00245554 r22: 0x00000001 r23: 0x00000001
r24: 0x00000000 r25: 0x00000005 r26: 0x00000000 r27: 0x00000000
r28: 0x00000000 r29: 0x00000005 r30: 0xf09a43c0 r31: 0x00204610
cr: 0x24000444 xer: 0x20000004 lr: 0x002046a4 ctr: 0x92ede094
vrsave: 0x00000000
Binary Images:
0x1000 - 0xc1ffb mds ??? (???) <af9cc958b4b030835101ff024186c7d3> /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework /Support/mds
0xde000 - 0xe0ffd com.apple.MDSChannel 1.0 (1.0) /System/Library/PrivateFrameworks/MDSChannel.framework/Versions/A/MDSChannel
0x139000 - 0x23fffb com.apple.spotlight.index 10.5.0 (398.1) <5843125c709dd85f22f9bd42744beea5> /System/Library/PrivateFrameworks/SpotlightIndex.framework/Versions/A/Spotlight Index
0x1ca9000 - 0x1caaffc liblangid.dylib ??? (???) <5f078ac1f623f5ce432ea53fc29338c0> /usr/lib/liblangid.dylib
0x2198000 - 0x22bdffb libmecab.1.0.0.dylib ??? (???) <cd875e74974e4ec3a0b13eeeb236fa53> /usr/lib/libmecab.1.0.0.dylib
0x8fe00000 - 0x8fe309d3 dyld 95.3 (???) <a7be977c203ec5c76b2f25a7aef66554> /usr/lib/dyld
0x90123000 - 0x9016effb com.apple.Metadata 10.5.0 (398) <b6bb1fd5a7a9135f546b2d8cbd65eafc> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadat a.framework/Versions/A/Metadata
0x901ab000 - 0x902d0ff3 com.apple.CoreFoundation 6.5 (476) <9073c2bfdf6842562c8b7f0308109c02> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x9060a000 - 0x90612fff libbsm.dylib ??? (???) <c1fca3cbe3b1c21e9b31bc89b920f34c> /usr/lib/libbsm.dylib
0x90683000 - 0x90688ff6 libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0x90757000 - 0x907d2fff com.apple.SearchKit 1.2.0 (1.2.0) <1b448fbae02460eae76ee1c6883f45d6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchK it.framework/Versions/A/SearchKit
0x9088a000 - 0x9090ffff libsqlite3.0.dylib ??? (???) <7b379cb4220346e99c32c427d4539496> /usr/lib/libsqlite3.0.dylib
0x90aa7000 - 0x90ab5fff libz.1.dylib ??? (???) <1a70dd3594a8c5ad39d785af5da23237> /usr/lib/libz.1.dylib
0x90b50000 - 0x90be2fff com.apple.framework.IOKit 1.5.1 (???) <591b8b0cc4261db98a6e72e38eef5f9a> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x91105000 - 0x9116cffb libstdc++.6.dylib ??? (???) <a4e9b10268b3ffac26d0296499b24e8e> /usr/lib/libstdc++.6.dylib
0x9116d000 - 0x912b5ff3 libicucore.A.dylib ??? (???) <250daed2fb2e6bf114480e2e4da0728b> /usr/lib/libicucore.A.dylib
0x91c3c000 - 0x91d32ffc libiconv.2.dylib ??? (???) <05ae1fcc97404173b2f9caef8f8be797> /usr/lib/libiconv.2.dylib
0x91d3a000 - 0x91db4ffd com.apple.CFNetwork 220 (221) <00b882d3d3325526b78ded74880759fe> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwo rk.framework/Versions/A/CFNetwork
0x9236a000 - 0x92382ffb com.apple.DictionaryServices 1.0.0 (1.0.0) <fe37191e732eeb66189185cd000a210b> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Diction aryServices.framework/Versions/A/DictionaryServices
0x92383000 - 0x9238effb libgcc_s.1.dylib ??? (???) <ea47fd375407f162c76d14d64ba246cd> /usr/lib/libgcc_s.1.dylib
0x92742000 - 0x92769fff libxslt.1.dylib ??? (???) <3700d04090629deddb436aa2d516c56d> /usr/lib/libxslt.1.dylib
0x92777000 - 0x92860fff libxml2.2.dylib ??? (???) <6f383df1e1e775be0158ba947784ae13> /usr/lib/libxml2.2.dylib
0x928aa000 - 0x928b9fff com.apple.DSObjCWrappers.Framework 1.2 (1.2) <2411674c821a8907449ac741ce6a40c3> /System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DSObjCWra ppers
0x92a17000 - 0x92afafeb libobjc.A.dylib ??? (???) <4a90e315bd1718c3f5ae09ee6c23e36c> /usr/lib/libobjc.A.dylib
0x92afb000 - 0x92bc9ff7 com.apple.CoreServices.OSServices 210.2 (210.2) <bad4943629f870d305f2bc7c6dfffe2d> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServi ces.framework/Versions/A/OSServices
0x92bde000 - 0x92dbfffb com.apple.security 5.0.1 (32736) <15632bf9bbdb223194b3d79a2e48e02d> /System/Library/Frameworks/Security.framework/Versions/A/Security
0x92e9a000 - 0x92ec5ff7 libauto.dylib ??? (???) <c1f2bd227817ad7c7bf29ec74729ac7c> /usr/lib/libauto.dylib
0x92ed2000 - 0x9306bfe3 libSystem.B.dylib ??? (???) <8a6cd873dfa7ada786efac188f95ed1b> /usr/lib/libSystem.B.dylib
0x931a7000 - 0x934a7ff3 com.apple.CoreServices.CarbonCore 783 (783) <fd2acaf23e95472f78b8a077fa039986> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonC ore.framework/Versions/A/CarbonCore
0x946f2000 - 0x9472afff com.apple.SystemConfiguration 1.9.0 (1.9.0) <d925dde7699e6231c88a41b0254a7591> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfi guration
0x94933000 - 0x9494eff3 com.apple.DirectoryService.Framework 3.5 (3.5) <3246a5d1c6a3d678798a90e8c5cd3677> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryServi ce
0x9494f000 - 0x9494fffa com.apple.CoreServices 32 (32) <42b6dda539f7411606187335d9eae0c5> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x94c68000 - 0x94c9dfff com.apple.AE 402 (402) <a4b92c8ac89cc774b85fb44c48b9d882> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.fram ework/Versions/A/AE
0x96831000 - 0x9683afff com.apple.DiskArbitration 2.2 (2.2) <9c8f8ade43fa25b32109ef9dcc0cb5d5> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x9683b000 - 0x968d1ff7 com.apple.LaunchServices 286 (286) <a3a0b2af862e9a8945072f8cb523678f> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchS ervices.framework/Versions/A/LaunchServices
0x969bc000 - 0x96c00ffb com.apple.Foundation 6.5.1 (677.1) <4152239382fb0f48abbcbf35bd04afa6> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0xfffec000 - 0xfffeffff libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib
0xffff8000 - 0xffff9703 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
Apparently the mdutil command didn't actually delete the Spotlight index file which is causing the problem, or at least didn't leave the indexing files in a consistent, empty state to start indexing over again. I may have to Erase this Time Machine disk and start over.
I should point out that except for Spotlight indexing this disk is otherwise working just fine. It passes Verify Disk with no errors and both new Time Machine backups and viewing and restoring via Time Machine and Finder work without problem.
Any suggestions before I just Erase the disk and start over with a new backup?
--Bob

Index Statistics Update - Problem

We had performance problem yesterday with FI report FAGLL03, it timed out in online execution and in background mode it took 5000+ sec to execute. Result was no more than 100 records.
Later with some investigation problem drill down to index usage of table FAGLFLEXA. We then updated the index statistics of table from DB02. After that report worked fine with execution time of 10-15 sec for same set of input.
However user, in morning , was complaining again about performance problem with same report FAGLL03. We did that update index statistics again and as it was the case yesterday it fixed the problem.
Later today I checked SQL server the job SAP CCMS_xxx_xxx_Update_Tabstats, which I guess is updating index statistics daily at 0400 hours, is working fine. I can't see any error log there. Daily job to check database consistency is also not reporting anything.
Anyidea what could be going wrong.
Basis Consultants are looking into problem however I am putting this case here if anyone of you had same problem and fixed it.
Thanks,
Pawan.
Edited by: Pawan Kesari on Dec 11, 2009 4:05 PM

Hi,
Appears the stats are dropped eveytime the job runs @04:00
Have a look at the table DBSTATC in trx: DB21 to see if it's setup to dropped the stats..
Mark

Solr errors when indexing custom file extensions.

Greetings!
I am working on my company's public website and need to be able to index the web pages. The site is configured to read .ak files as .cfm files, but Soler errors when trying to read them. While testing I found that if I remove the <head> tags from the documents there are no errors. I've looked into the Solr config files for a location to tell Solr that .ak files should be parsed as html. I have been unable to find such a setting, does one exist?
Thanks for your help,
Dave

Hi,
Are you able to manually add new extension to the list?
Try the troubleshooter under “Advanced Options” or rebuild the index for a test.
If doesn’t work, then let’s go deeper for this issue.
Open registry, expand, HKEY_CLASSES_ROOT
Under this entry, there should be a bunch of file types, I did a test, if I delete a file type in it, for example .txt, then when I open the index option again, advanced option, file type, I’ll no longer find the txt extension in the list, so you may check
the keys in case the registry is broken.
Regards
Yolanda
TechNet Community Support

Index not using in select query

Hello All,
I have table CITY with 2 composite primary key CITYCODE, COUNTRYCODE of course they are NOT NULL.
i created an index.
CREATE UNIQUE INDEX CITYKEY ON CITY     (CITYCODE, COUNTRYCODE);
then i run explain plan as follows
explain plan for
select CityCode, CityName, CountryCode, LexiconId, UserId, Status
from City
where CountryCode = 'IR';
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 803 | 57013 | 112 (2)| 00:00:02 |
|* 1 | TABLE ACCESS FULL| CITY | 803 | 57013 | 112 (2)| 00:00:02 |
later i analyze table rebuild indexes but again explain plan gives me the same result.
Could any 1 please guide me to solve this issue.
Thanks
Edited by: mohsin javed on Feb 17, 2011 10:10 AM

Hello All,
Again with one more query which having join:
table SDNMASTER with sdnid pk and SDNMASTER_PK index on SDNID, table SDNALIAS sdnid pk and SDNALIAS_PK index on SDNID.
explain plan for
SELECT a.SourceId,
          a.SourceName,
          b.LastName,
          a.Status
FROM SdnMaster a,
          SdnAlias b
WHERE a.SdnId = b.SdnId
AND a.Status in ('1', '3')
AND b.LastName is not null
ORDER BY b.LastName;
PLAN_TABLE_OUTPUT
Plan hash value: 1153036645
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2399 | 64773 | 69 (5)| 00:00:01 |
| 1 | SORT ORDER BY | | 2399 | 64773 | 69 (5)| 00:00:01 |
|* 2 | HASH JOIN | | 2399 | 64773 | 68 (3)| 00:00:01 |
|* 3 | TABLE ACCESS FULL| SDNALIAS | 2399 | 21591 | 11 (0)| 00:00:01 |
|* 4 | TABLE ACCESS FULL| SDNMASTER | 4562 | 82116 | 56 (2)| 00:00:01 |
Even after analyzing table and rebuilding index its not using the index..
Thanks

Time machine taking too long (indexing)

I run my time capsule to back up both of my computers
a Imac 2GHz intel core duo running 10.6.8 and
an Imac 3.4GHz intel core i7 running 10.7.4
both are connected wirelessly to the Time Capsule
Recently, on the older machine, backups have stalled. I can work on it for a while, doing disk repairs and disk permissions with the Snow Leopard installation disk utility and 'fix' it for multiple backups - and all is well. Then it stalls on 'indexing backup' again. Meanwhile, the new machine running Lion is just fine. I just noticed it again.
Last successful backup was 0517 this morning (EST) and this was at approx 1700 (5 evening). I sat at the computer and was working away when Snow Leopard became really slow and I noted that the Time Capsule was indicating indexing backup, I let it run for 45 minutes and it was still indexing backup, so I quite Time Machine and restarted at 1845 (645 evening). The restart of Time Machine allows Snow Leopard to regain its usual speed, Time machine reported a file count of 202 files that had changed and went to 'indexing backup' a half hour later it is still at 'indexing backup' (about 9 emails were received - how that relates to 202 files I am not sure)
Why does it work multiple times just fine and then all of a sudden stall? When it does stall it simply (over time I presume) eats up all available memory (1.5 gb) with page swaps each one getting bigger and bigger until all memory is gone. I can 'free memory' and recover to about 600 free (running email and browser app in the background) but the time machine does it all over again if I allow it to run.
As I said, I have used Disk Utility (with the Snow Leopard Installation disk to allow repair of the boot volume) and have repaired the disk and repaired permissions - several times. (some disk permissions are repaired - no disk repairs reported) After each time, I go back and restart Time Machine and 'poof' within an hour it performs a backup with no problems. I note that backups are performed on schedule for the next few days with no problems, and then bingo, the system is totally bogged down again, and Time Machine is stuck on indexing backup once again. I have not noticed any commonality as to when the problem occurs - sometimes after a day, sometimes after several days. And meanwhile, the Lion machine is performing flawlessly
At the moment my kludge to work around is to turn off Time Machine so as not to use up all the memory and then periodically use the installation disk routine to 'repair' (disk and permissions) and then backup, but this is NOT solving the problem long term of course.
The first time I noticed this (about two months ago) the disk repair did note a disk error the system was claiming 2 bytes less free space than there was, but after that time, all the disk repairs report fine.

Indexing can take a long time over wireless. You would do much better with ethernet connection.
Maybe the hard drive is failing.. The fact that the disk passes tests does not mean it is ok. As a disk ages it can have issues reading, where the same sector has to read multiple times.
I guess the ideal would be replace the machine.. it is several years old and really due for replacement.
Or at least the hard disk... although the cost of doing that job might not be worth it.
As a test I would do a backup using TM to a USB local disk plugged into it... that is good practice anyway when you are getting poor reliability on backups.
You can create a disk image using a other tools.. CCC or superduper.
A clone of the existing drive again can be worth it.
You can set to boot from FW drive and ignore the internal.. see if the problems go away.
Pondini is usually helpful although he doesn't have specific on this indexing issue.
http://pondini.org/TM/Troubleshooting.html

SRMO - Cannot delete Index Category after System Copy

Hi,
I am trying to delete incorrect Index Categories using t-code SRMO after a system copy (restore db from backup) from our production system to our sandbox system.
When I select the Index Category and click on the "Delete Category" button I get this message:
Error during deletion of language 'EN'. Search
engine result '3147'
When I click on the Help button I get this:
Error during deletion of language 'EN'. Search engine result '3147'
Message no. SRET148
Diagnosis
When the index category is deleted, all languages, and consequently all physical indices on the search server (RFC server) are deleted.
If a physical index could not be deleted, the index category is not deleted or set to inactive either. This is to prevent the index from staying on the search server without R/3 inforamtion.
Procedure
Firstly clean up all languages / indexes for which this information appears.
Use the function to delete an index without R/3 information (if such an index exists) and / or the function to delete the language without an index from the R/3 System.
You can then call the function 'Delete index category' again.
Any ideas on what function they are talking about in the second to last paragraph: "function to delete an index without r/3 information"?
Thank you,
Neil

I have exactly the same problem, only that the index category still can't be deleted even after I deleted the languages first. I still get the error message '3147'. It says that there was an error deleting the languages. As procedure it is suggested (as before) to first delete the languages and then again the index category. But the languages are no longer displayed in the index category.
Does anybody know how I should proceed in order to delete the old invalid index and to create a new one for indexing with the new TREX?

SAP Table index size is greater than the size of the actual table

Hello Experts,
We are resolving an issue related to database performance. The present database size is 9 Terabytes. The analysis of response times through ST03N shows that the db time is 50% of the total response time. We are planning to reorganize the most updated tables (found from DB02old tx).
Here we see that the size of the index for a table is greater than the actual size of the table. Is this possible, if yes then how can we reorganize the index as it does not allow us to reorganize the index using brspace command.
Hope to hear from you soon, and if any additional activities you can suggest to improve the performance of the database will be appreciated.
Thank you

Hi Zaheer,
online redef may help you (for a little while) , but also check WHY the index became fragmented.
Improper settings can bring the index fragmented again and you have reoccuring reorg needs.
i.e.
check if PCT_INCREASE >0 if you are using Dictionary Managed Tablespaces or locally managed tablespaces that uses a "User" allocation policy. Set it to 0 to generate uniform next extents in the online reorg.
select
            SEGMENT_NAME,
            SEGMENT_TYPE,
            round((NEXT_EXTENT*BLOCKS)/(EXTENTS*BYTES))*(BYTES/BLOCKS),
            PCT_INCREASE
        from
            DBA_SEGMENTS
        where
            OWNER='SAPR3'
        and
            SEGMENT_TYPE in ('INDEX',
                            'TABLE')
        and
            PCT_INCREASE > 0
        and segment_name in ('Yourtable','Yourindex')
In the following cases, it may be worthwhile to rebuild the index:
     --> the percentage of the space used is bad - lower than 66%: PCT_USED
     --> deleted leaf blocks represent more than 20% of total leaf blocks: DEL_LF_ROWS
     --> the height of the tree is bigger than 3: HEIGHT or BLEVEL
select
name,
'----------------------------------------------------------'    headsep,
'height               '||to_char(height,     '999,999,990')     height,
'blocks               '||to_char(blocks,     '999,999,990')     blocks,
'del_lf_rows          '||to_char(del_lf_rows,'999,999,990')     del_lf_rows,
'del_lf_rows_len      '||to_char(del_lf_rows_len,'999,999,990') del_lf_rows_len,
'distinct_keys        '||to_char(distinct_keys,'999,999,990')   distinct_keys,
'most_repeated_key    '||to_char(most_repeated_key,'999,999,990') most_repeated_key,
'btree_space          '||to_char(btree_space,'999,999,990')       btree_space,
'used_space           '||to_char(used_space,'999,999,990')        used_space,
'pct_used                     '||to_char(pct_used,'990')          pct_used,
'rows_per_key         '||to_char(rows_per_key,'999,999,990')      rows_per_key,
'blks_gets_per_access '||to_char(blks_gets_per_access,'999,999,990') blks_gets_per_access,
'lf_rows      '||to_char(lf_rows,    '999,999,990')||'        '||+
'br_rows      '||to_char(br_rows,    '999,999,990')                  br_rows,
'lf_blks      '||to_char(lf_blks,    '999,999,990')||'        '||+
'br_blks      '||to_char(br_blks,    '999,999,990')                  br_blks,
'lf_rows_len '||to_char(lf_rows_len,'999,999,990')||'        '||+
'br_rows_len '||to_char(br_rows_len,'999,999,990')                  br_rows_len,
'lf_blk_len   '||to_char(lf_blk_len, '999,999,990')||'        '||+
'br_blk_len   '||to_char(br_blk_len, '999,999,990')                br_blk_len
from
index_stats where index_name = 'yourindex'
bye
yk

How to rename database with secondary indexes.

Hi,
could somebody advise how to run correct next operation:
I have database with secondary indexes in a single file and I need to rename that db file.
As I understand I have to
1) close and delete all database handles
2) remove from db file all secondary indexes with DbEnv::dbremove
3) rename db file with DbEnv::dbrename
4) create primary db
5) create once again all secondary indexes and associate them with primary db
Appreciate in advance.

Hi,
Your question has two possible cases:
1. A single file contains main DB and its secondary indexes.
2. A file contains several secondary indexes of main DB, another file contains the main DB.
For the first case, the main database could be renamed directly, but all of the secondary databases do not continue to work. That means no new index items will be added automatically into exist secondary databases. So these secondary databases should be removed and created, you could also just run a DB->associate to re-associate it again. But in the later way, the re-associated secondary DB won't automatic index these records that are added before associating.
That means, if main db is renamed and then inserted a record 'A'. Then secondary DB is re-associated to main db. The secondary DB still does not index record 'A'. And currently there is not method to let secondary DB manually index 'A' again. So it is better to remove and create a new secondary DB with DB_CREATE flag. That will make the new secondary DB scan current items and index them.
For the second case, the result is the same, main database could be remained directly. Then all of the secondary databases should be re-created or re-associated. Still for the described reason, we prefer the first way.
And, removing old secondary databases before renaming main database is also work in above cases.
Thanks,
Victor Yang

Mds not running. Lazy indexing

I have been having problems with Finder and Spotlight recently. I've done a clean install and an archive install in the last three weeks but this hasn't helped.
Spotlight will only carry out a brief index not even nearly indexing my entire drive. The mds process is not running and I can't find the little expletive is hiding in order to manually start it up.
Finder crashes when I use More Info in the Inspector. I've verified disk permissions and repair both permissions and the startup disk itself.
I've tried to force a rebuild but it finishes far too quickly.
sudo mdutil -E /
is the command for those of you who haven't tried that option yet, does require root access of course.
Anyone else having similar problems? I've got no idea how to get OS X playing nicely again. In all honesty I feel like I've hit a brick wall.
All help is appreciated. Thanks fellow Mac-enthusiasts.
MBP Mac OS X (10.4.10) 2.33GHz Core2Duo, 3GB, 256MB RadeonX1600, 120GB & 500GB LaCie d2.

I have fixed the issue myself using a sledgehammer approach as the feather-light touch did not help.
Here's an extract direct from my blog with all the info you need.
*Indicative Symptoms*
If Spotlight is not indexing your drive properly you may notice the search in Mail no longer finds any results. You may also notice Finder slows to a snail’s pace in column view and looking for more info in the Inspector does nothing short of induce a fatal hang within Finder.
*Feather-light Solutions*
Apple and other websites will tell you to put your entire drive in the Privacy section of Spotlight’s preference pane and then remove it. This did not work when I tried it as the index was totally corrupted. You may want to try this however as it has worked for some people.
I opted for using the command line to reindex as I’m a bit of a command line junkie. If you get an indexing status unknown error during this process you’ll need to proceed to the sledgehammer steps.
If you do not wish to use the command line for this step you will need to refer to http://www.info.apple.com/kbnum/n302223 for more information on fixing spotlight issues.
And for those of us who aren’t *nix nerds, but still want to use the command line, you will need to enable root user access to employ this fix. Apple have documentation on how to this at http://docs.info.apple.com/article.html?artnum=106290.
sudo mdutil -i off /
sudo mdutil -E /
sudo mdutil -i on /
These three commands, executed using root user permissions, allow you to firstly turn off indexing on the startup volume (the startup volume is mounted at / hence the forward slash at the end), clear the index completely using the -E flag, and then turn on indexing once again.
*Sledgehammer Steps*
These steps should only be used as a last resort as they go above an beyond the typical guidelines for repairing Spotlight, they did however work for me.
First you’re going to have to remove the main spotlight directories on your HDD using root permissions.
Then repair disk permissions and reboot.
The commands necessary are below. This is a _last resort_ and should not be attempted before a simple uninterrupted reindex.
sudo rm -r /.Spotlight-V100
sudo rm -r /Library/Spotlight
diskutil repairPermissions /
Alternatively, you can use Apple’s Disk Utility to repair permissions. The Disk Utility application can be found within your Utilities folder (/Applications/Utilities/Disk Utility.app.)
After carrying out these steps reboot your system. Once you’ve logged in DO NOT TOUCH SPOTLIGHT! Just leave your computer alone until the pulsing white circle within the Spotlight icon has disappeared or you will have achieved nothing.
Happy sudoing!
Message was edited by: James Conroy-Finn

Endless spotlight indexing on my idisk

it's about a week that spotlight it's indexing my iDisk.
I have my idisk on the desktop with active syncro so i have a proper copy of the idisk on the desktop.
Using cocktail i erased the index for the main(system) disk and let spotlight indexing it again but it started again with the message "indexing idisk estimated time...".
My i disk its about 800mb and the system disk is 500gb just 4gb full.
thanks for now.

Hi gimbo70 & welcome to forums
Go to System Preferences/Spotlight and add your iDisk to the exclusion list/window.
Close prefs, then re-open and remove your iDisk from the exclusion window. This should stop and restart normal indexing on that particular volume.
See these articles/links for more info:
http://support.apple.com/kb/TA22902?viewlocale=en_US
http://discussions.apple.com/thread.jspa?threadID=1635504&tstart=795
http://www.wwco.com/~wls/blog/2007/08/29/rebuilding-spotlights-index-on-os-x-man ually/
If it were me, I wouldn't entertain an indexed iDisk...

Indexing Question - Shorten Process?

It appears that when one searches for a keyword it indexes all the files in the folder/folders that are being searched. This can take awhile if there are lots of files.
If one adds a folder and then searches for the same keyword, it again goes through the whole indexing sequence again.
I use central cache, if I would check "export cache to folders" would that eliminate the constant indexing for searches?
I saved the search as a collection and then clicked on that folder, the Bridge then when through the whole indexing routine again, and I did not change a thing.
I have the box checked "search all non-indexed files" which probably is the culprit, but if not checked I can miss files.
Does anyone have a clue as to when Bridge needs to index, when to check the search non-indexed files, and how to reduce the indexing time?

Hi,
Try using 'INNER JOIN' as opposed to the 'FOR ALL ENTRIES' construct.
BR/
Mathew.
P.S. This link could give some help with the coding.
http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb39c4358411d1829f0000e829fbfe/content.htm
Edited by: Mathew Muthalaly on Apr 10, 2008 12:43 PM

Causes of invalid indexes

Oracle 11.2.0.1
Windows
Can anyone please give me link or a complete list of reasons which can cause of an invalidate index.
I just want to know all the resons by which one valid index becomes invalid.
Thanks.

1.alter index <index_name> unusable;
2.In the common definition, an index becomes unusable when the database recognizes the rowids in the index are no longer pointing to the rows in the table. This can occur when the table is moved, compressed, etc. while the index is inaccessible.
3.SQL*Loader fails to update the index because the index runs out of space.
4.The instance fails during the building of the index.
5.A unique key has duplicate values.
6.An index isn't in the same order as that specified by a sorted indexes clause.
7.Truncating a table makes an unusable index usable again.
8.The data is not in the order specified by the SORTED INDEXES clause.
9.There are duplicate keys in a unique index.
10.Data savepoints are being used, and the load fails or is terminated by a keyboard interrupt after a data savepoint occurred.
11.Any table-level Partition operation like split,move,import,exchange,merge,truncate,drop except add parition; all non-partitioned and globally partitioned indexes becames unusable; while Locally Partitioned Indexes only affects partitions being affects.
12.Performing an online redefinition of a table because these operation Shifts the ROWID valuse. And that causes the Index to become unusable.
Source:[url http://docs.oracle.com/cd/B19306_01/server.102/b14215/ldr_modes.htm#sthref1486]Documentation, This forum and Page No.127 Expert Indexing in Oracle Database 11g by Darl Kuhn,Sam R. Alapati,Bill Padfield.
This is not a complete list, but I guess these are the main causes for unusable indexes.
Regards
Girish Sharma

Index isssue again

Similar Messages

Maybe you are looking for