Indexes not being replicated

Greeting:
Problem: I create a new index on the master instance and it not replicating to the consumer instance. Also previously existing indices are not being replicated. There are no error messages regarding replication
Direcotory Server 6.3
Actions:
** I created the consumer instance via DSCC
** I create blank suffixes on the new consumer instance
** I enable replication on consumer
** I create replication agreement on master
** I initialize replication from consumer
The indices existing on master are showing on the consumer and newly added index are also not showing up.
Please help and thanks
Ahsan

Your observation is correct. Index configuration is not replicated but is on a per-server basis. This is probably to allow various instances on the topology to serve different purposes while not being forced to maintain unnecessary indices.

Similar Messages

Security Permissions from Management Console Not Being Replicated on SQL Server Database

Hi Everyone,
We have been encountering issues with access to Reporting Services for most console users since we upgraded to SCCM 2012 R2. We have observed that since the R2 upgrade, security permissions
that are set in the console are not being replicated on the SQL database. Users/Groups that had access prior to the R2 upgrade are now only able to access Reports via the web interface. All new users/groups are not able to get access at all.
We are not sure what the problem could be and would appreciate any guidance.
We have tried the following without success:
Manually adding new users/groups to the database
Reinstalling the the Reporting Service point and Reporting Service, Removing all of the security groups from the console and from the database, and Adding the security groups back
to the console.
Our current environment:
SCCM 2012 R2
1 Site
Primary Site:
OS: Server 2008 R2
Roles: Site Server / Software Update Point / Management
Point
SQL Server
OS: Server 2008 R2
SQL Version: Microsoft SQL Server 2008 R2
Roles: Site Database Server / Reporting Services Point

Thanks for your feedback.
Permissions
We have two main types of users: Full Administrators and local departmental IT administrators. (Local IT Admins only have full control over their own departmental collections. They have Read/Add to All Systems.)
The only account that's currently able to run Reports from both the console and web is the admin account used to perform the R2 upgrade.
Full Administrator
Role: Full Administrator
Scope: All instances of the objects that are related to the assigned security roles.
Local Departmental Administrator
Role: Full Administrator & Read/Add
Scope: Main Departmental Collection (Full Admin) & All Systems, All Users, and All User Groups (Read/Add)
Report Service Execution
On the database, we have tried assigning the Report Service Execution Account to the built-in Network Service Account, Local Service Account, and to a separate AD role account.
Error Messages
Console: We are able to select reports from the Console however nothing appears when we click on Run.
Web: Generating Reports from the Web works for only the Full Administrators. Nothing appears for a Local Departmental Admin.
This is a partial output from srsrp.log:
Set configuration   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Check state   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Check server health.   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Successfully created srsserver   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Reporting Services URL from Registry [http://132.205.120.154/ReportServer/ReportService2005.asmx]   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Reporting Services is running   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Retrieved datasource definition from the server.   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
[SCM-SQL.concordia.ca] [CM_SCM] [ConfigMgr_SCM] [SCM-SQL.CONCORDIA.CA]   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
[MSSQLSERVER] [1] [] [CONCORDIA\SVC-SCM_REPORT]   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
[1] [0]   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Confirmed version [10.50.2811.0] for the Sql Srs Instance.   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Retrieved datasource definition from the server.   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Updating data source {5C6358F2-4BB6-4a1b-A16E-8D96795D8602} at ConfigMgr_SCM   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Loading localization resources from directory [E:\SMS_SRSRP\SrsResources.dll]   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Looking for 'English (United States)' resources   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Looking for 'English' resources   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Found resources for 'English'   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:05 PM   2588 (0x0A1C)
Confirmed the configuration of SRS role [ConfigMgr Report Users].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Confirmed the configuration of SRS role [ConfigMgr Report Administrators].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Confirmed the security policy for folder [/].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Confirmed the security policy for folder [/ConfigMgr_SCM].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Confirmed the security policy for folder [/ConfigMgr_SCM/Asset Intelligence].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)
Error retrieving users - [The EXECUTE permission was denied on the object 'spGetReportUsers', database 'CM_SCM', schema 'SCCM_Rpt'.].   SMS_SRS_REPORTING_POINT   3/10/2015 2:28:06 PM   2588 (0x0A1C)

Index not being used in access path

Hi,
I have been trying to rewrite a query which currently is taking almost 1min and 25 secs to execute. The database version is 11.1.0.7.
The query is -
SELECT COUNT(1)
FROM TAB1 p
WHERE p.ACODE = 24377
AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
AND p.rflag = 'Y';
The table originally didn't have an index on p.ACODE. So, I created this index and set it to visible and set the optimizer_use_invisible_indexes parameter also to TRUE. I set the monitoring on this index too. Even though I have created the index on the ACODE column, the access path doesn't use it. Can someone please tell me why this is not being used.
Below is the explain plan for the sql stmt and the usage of the index -
I have changed the actual table and column names -
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.ACODE = 24377
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.ACODE = 24377
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 3942424611
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 214K (2)| 00:42:57 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 214K (2)| 00:42:57 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 209K (2)| 00:41:56 |
|* 4 | TABLE ACCESS FULL | TAB1 | 1 | 32 | 209K (2)| 00:41:55 |
| 5 | INDEX FAST FULL SCAN| PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AKey")
3 - access("PHS"."PKey"="P"."AKey")
4 - filter(TO_NUMBER("P"."ACODE")=24377 AND "P"."rflag"='Y')
20 rows selected.
Elapsed: 00:00:00.03
SQL> select index_name,VISIBILITY from user_indexes where index_name='IDX_TAB1_ACODE';
INDEX_NAME VISIBILIT
IDX_TAB1_ACODE VISIBLE
Elapsed: 00:00:00.01
SQL> show parameter visible
NAME TYPE VALUE
optimizer_use_invisible_indexes boolean TRUE
SQL>
SQL> SELECT v.index_name, v.table_name,
v.monitoring, v.used,
start_monitoring, end_monitoring
FROM v$object_usage v, dba_indexes u
WHERE v.index_name = u.index_name
AND v.index_name = 'IDX_TAB1_ACODE';
INDEX_NAME TABLE_NAME MON USE START_MONITORING END_MONITORING
IDX_TAB1_ACODE TAB1 YES NO 05/26/2010 14:13:41
Elapsed: 00:00:00.10
Edited by: user12158503 on May 26, 2010 1:24 PM

Thanks Centinul.
I apologize for posting in both sections. I put it in the Database General too because I thought I originally posted it in the wrong section.
The index was not being used because it was doing the implicit type conversion. When I enclosed it in quotes, it returns the result within a second and it uses the index.(whereas without the index it takes around 1min 25 sec)
Here is the explain plan and execution time after enclosing it in quotes -
SQL> explain plan for
2 SELECT COUNT(1)
3 FROM TAB1 p
4 WHERE p.AKey = '24377'
5 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
6 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
7 AND p.rflag = 'Y';
Explained.
Elapsed: 00:00:00.02
SQL> @$ORACLE_HOME/rdbms/admin/utlxpls.sql
PLAN_TABLE_OUTPUT
Plan hash value: 2008452282
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 87 | 5134 (1)| 00:01:02 |
| 1 | SORT AGGREGATE | | 1 | 87 | | |
|* 2 | HASH JOIN ANTI | | 1 | 87 | 5134 (1)| 00:01:02 |
|* 3 | HASH JOIN ANTI | | 1 | 60 | 60 (2)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| TAB1 | 1 | 32 | 6 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | IDX_TAB1_AKey | 4 | | 1 (0)| 00:00:01 |
| 6 | INDEX FAST FULL SCAN | PK_TAB3 | 29918 | 818K| 53 (0)| 00:00:01 |
| 7 | INDEX FAST FULL SCAN | PK_TAB2 | 3199K| 82M| 5059 (1)| 00:01:01 |
Predicate Information (identified by operation id):
2 - access("PH"."PKey"="P"."AGILITYKEY")
3 - access("PHS"."PKey"="P"."AGILITYKEY")
4 - filter("P"."rflag"='Y')
5 - access("P"."AKey"='24377')
22 rows selected.
Elapsed: 00:00:00.02
SQL> SELECT COUNT(1)
2 FROM TAB1 p
3 WHERE p.AKey = '24377'
4 AND NOT EXISTS (SELECT 1 FROM TAB2 ph where ph.PKey = p.AgilityKey )
5 AND NOT EXISTS (SELECT 1 FROM TAB3 phs where phs.PKey = p.AgilityKey )
6 AND p.rflag = 'Y';
COUNT(1)
1
Elapsed: 00:00:00.52
Can you give me some tips on where I could read about learning to understand the explain plan. I did read a few articles which did help me, but not much. I am looking for something in detail.

Index not being used in group by.

Here is the scenario with examples. Big table 333 to 500 million rows in the table. Statistics are gathered. Histograms are there. Index is not being used though. Why?
CREATE TABLE "XXFOCUS"."some_huge_data_table"
   ( "ORG_ID" NUMBER NOT NULL ENABLE,
"PARTNERID" VARCHAR2(30) NOT NULL ENABLE,
"EDI_END_DATE" DATE NOT NULL ENABLE,
"CUSTOMER_ITEM_NUMBER" VARCHAR2(50) NOT NULL ENABLE,
"STORE_NUMBER" VARCHAR2(10) NOT NULL ENABLE,
"EDI_START_DATE" DATE,
"QTY_SOLD_UNIT" NUMBER(7,0),
"QTY_ON_ORDER_UNIT" NUMBER(7,0),
"QTY_ON_ORDER_AMT" NUMBER(10,2),
"QTY_ON_HAND_AMT" NUMBER(10,2),
"QTY_ON_HAND_UNIT" NUMBER(7,0),
"QTY_SOLD_AMT" NUMBER(10,2),
"QTY_RECEIVED_UNIT" NUMBER(7,0),
"QTY_RECEIVED_AMT" NUMBER(10,2),
"QTY_REQUISITION_RDC_UNIT" NUMBER(7,0),
     "QTY_REQUISITION_RDC_AMT" NUMBER(10,2),
     "QTY_REQUISITION_RCVD_UNIT" NUMBER(7,0),
     "QTY_REQUISITION_RCVD_AMT" NUMBER(10,2),
     "INSERTED_DATE" DATE,
     "UPDATED_DATE" DATE,
     "CUSTOMER_WEEK" NUMBER,
     "CUSTOMER_MONTH" NUMBER,
     "CUSTOMER_QUARTER" NUMBER,
     "CUSTOMER_YEAR" NUMBER,
     "CUSTOMER_ID" NUMBER,
     "MONTH_NAME" VARCHAR2(3),
     "ORG_WEEK" NUMBER,
     "ORG_MONTH" NUMBER,
     "ORG_QUARTER" NUMBER,
     "ORG_YEAR" NUMBER,
     "SITE_ID" NUMBER,
     "ITEM_ID" NUMBER,
     "ITEM_COST" NUMBER,
     "UNIT_PRICE" NUMBER,
      CONSTRAINT "some_huge_data_table_PK" PRIMARY KEY ("ORG_ID", "PARTNERID", "EDI_END_DATE", "CUSTOMER_ITEM_NUMBER", "STORE_NUMBER")
USING INDEX TABLESPACE "xxxxx" ENABLE,
      CONSTRAINT "some_huge_data_table_CK_START_DATE" CHECK (edi_end_date - edi_start_date = 6) ENABLE
SQL*Plus: Release 11.2.0.2.0 Production on Fri Sep 14 12:11:16 2012
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> SELECT num_rows FROM user_tables s WHERE s.table_name = 'some_huge_data_table';
NUM_ROWS
333338434
SQL> SELECT MAX(edi_end_date)
2    FROM some_huge_data_table p
3   WHERE p.org_id = some_number
4     AND p.partnerid = 'some_string';
MAX(EDI_E
13-MAY-12
Elapsed: 00:00:00.00
SQL> explain plan for
2 SELECT MAX(edi_end_date)
3    FROM some_huge_data_table p
4   WHERE p.org_id = some_number
5     AND p.partnerid = 'some_string';
Explained.
SQL> /
PLAN_TABLE_OUTPUT
Plan hash value: 2104157595
| Id | Operation                    | Name        | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT             |             |     1 |    22 |     4   (0)| 00:00:01 |
|   1 | SORT AGGREGATE              |             |     1 |    22 |            |          |
|   2 |   FIRST ROW                  |             |     1 |    22 |     4   (0)| 00:00:01 |
|* 3 |    INDEX RANGE SCAN (MIN/MAX)| some_huge_data_table_PK |     1 |    22 |     4   (0)| 00:00:01 |
SQL> explain plan for
2 SELECT MAX(edi_end_date),
3         org_id,
4         partnerid
5    FROM some_huge_data_table
6   GROUP BY org_id,
7            partnerid;
Explained.
PLAN_TABLE_OUTPUT
Plan hash value: 3950336305
| Id | Operation          | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT   |          |     2 |    44 | 1605K (1)| 05:21:03 |
|   1 | HASH GROUP BY     |          |     2 |    44 | 1605K (1)| 05:21:03 |
|   2 |   TABLE ACCESS FULL| some_huge_data_table |   333M| 6993M| 1592K (1)| 05:18:33 |
-------------------------------------------------------------------------------                     Why wouldn't it use the index in the group by? If I write a loop to query for different partnerid (there are only three), the whole things takes less than a second. Any help is appreciated.
btw, I gave the index hint too. Didn't work. Version mentioned in the example.
Edited by: RPuttagunta on Sep 14, 2012 11:24 AM
Edited by: RPuttagunta on Sep 14, 2012 11:26 AM
the actual names are 'scrubbed' for obvious reasons. Don't worry, I didn't name the tables in mixed case.

Jonathan,
Thank you for your input. Forgot about this issue since ended up creating an MV since, the view was slower. But either way, I am curious. Here are the results for your questions.
SQL> SELECT last_analyzed,
2         blocks
3    FROM user_tables s
4   WHERE s.table_name = 'huge_data';
LAST_ANAL     BLOCKS
14-MAY-12    5869281
SQL> SELECT last_analyzed,
2         leaf_blocks
3    FROM user_indexes i
4   WHERE i.table_name = 'huge_data';
LAST_ANAL LEAF_BLOCKS
14-MAY-12     2887925
SQL>It looks like stale statistics from the last_analyzed, but, they really aren't. This is a development database and that was the last time around which it was refreshed. And the stats are right (at least the approx_no_of_blocks and num_rows etc).
No other data came into the table after.
Also,
1). I thought I don't have any particular optimizer parameters, but, checking back I do. fastfull_scan_enabled = false. Could that be it?
SQL> SELECT a.name,
2         a.value,
3         a.display_value,
4         a.isdefault,
5         a.isses_modifiable
6    FROM v$parameter a
7   WHERE a.name LIKE '\_%' ESCAPE '\';
NAME                           VALUE                          DISPLAY_VALUE   ISDEFAULT       ISSES
_disable_fast_validate         TRUE                           TRUE            FALSE           TRUE
_system_trig_enabled           TRUE                           TRUE            FALSE           FALSE
_sort_elimination_cost_ratio   5                              5               FALSE           TRUE
_b_tree_bitmap_plans           FALSE                          FALSE           FALSE           TRUE
_fast_full_scan_enabled        FALSE                          FALSE           FALSE           TRUE
_index_join_enabled            FALSE                          FALSE           FALSE           TRUE
_like_with_bind_as_equality    TRUE                           TRUE            FALSE           TRUE
_optimizer_autostats_job       FALSE                          FALSE           FALSE           FALSE
_connect_by_use_union_all      OLD_PLAN_MODE                  OLD_PLAN_MODE   FALSE           TRUE
_trace_files_public            TRUE                           TRUE            FALSE           FALSE
10 rows selected.
SQL>As, you might have guessed, I am not the dba for this db. Should pay more attention to these optimizer parameters.
I know why we had to set connectby_use_union_all hint (due to a bug in 11gR2).
Also, vaguely remember something about the disablefast_validate (something about another major db bug in 11gR2 again), but, not sure why those other parameters are set.
2). Also, I have tried this
SQL> SELECT /*+ index_ss(huge_data_pk) gather_plan_statistics*/
2   MAX(edi_end_date),
3   org_id,
4   partnerid
5    FROM huge_data
6   GROUP BY org_id,
7            partnerid;
MAX(EDI_E     ORG_ID PARTNERID
2 rows
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null,null,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
SQL_ID f3kk8skdyvz7c, child number 0
SELECT /*+ index_ss(huge_data_pk) gather_plan_statistics*/
MAX(edi_end_date), org_id, partnerid   FROM huge_data GROUP BY
org_id,           partnerid
Plan hash value: 3950336305
| Id | Operation          | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads | OMem | 1Mem | Used-Mem |
PLAN_TABLE_OUTPUT
|   0 | SELECT STATEMENT   |          |      1 |        |      2 |00:05:11.31 |    5905K|   5897K|    | |          |
|   1 | HASH GROUP BY     |          |      1 |      2 |      2 |00:05:11.31 |    5905K|   5897K|   964K|   964K| 2304K (0)|
|   2 |   TABLE ACCESS FULL| hug_DATA |      1 |    333M|    334M|00:04:31.44 |    5905K|   5897K|    | |          |
16 rows selected.But, then, I tried this too.
SQL> alter session set "_fast_full_scan_enabled"=true;
Session altered.
SQL> SELECT MAX(edi_end_date),
2         org_id,
3         partnerid
4    FROM hug_data
5   GROUP BY org_id,
6            partnerid;
MAX(EDI_E     ORG_ID PARTNERID
2 rowsAnd this took around 5 minutes too.
PS: This has nothing to do with original question, but, it is plausible to derive the 'huge_data' table name from the sql_id? Just curious.

Index not being used (again)

Dear All,
Having real trouble these days with the indexes.
I have a query below:
SELECT MAX(A.ID) PRID,TIMEPERIODID,RESOURCEID
                      FROM   TIMESHEET A, TIMEPERIOD B
                      WHERE A.STATUS IN (1,3,4) AND A.ISADJUSTMENT = 0
                         AND A.timeperiodid = B.id
                         AND TRUNC(B.PSTART)>=TRUNC(NEXT_DAY(SYSDATE-28,'MONDAY'))
                         GROUP BY TIMEPERIODID,RESOURCEID
The explain plan for this query is as below:
Plan     COST
SELECT STATEMENT      2720
SORT GROUP BY      2720
HASH JOIN      2520
   TABLE ACCESS FULL TIMEPERIOD     2
   TABLE ACCESS FULL TIMESHEET     2516As you can see, table access full on timesheet table. However, I have an index on timeperiodid column of the table. Despite using it as hint, the index is not being used. Is it that indexes are not used with GROUP BY?
Please help.
Thanks,

and the explain plan:
Plan
SELECT STATEMENT ALL_ROWSCost: 18,747 Bytes: 105 Cardinality: 1
     34 SORT GROUP BY Cost: 18,742 Bytes: 105 Cardinality: 1
          33 FILTER
               21 NESTED LOOPS Cost: 18,727 Bytes: 105 Cardinality: 1
                    18 HASH JOIN Cost: 18,722 Bytes: 415 Cardinality: 5
                         11 TABLE ACCESS BY INDEX ROWID TIMEENTRY Cost: 14 Bytes: 144 Cardinality: 9
                              10 NESTED LOOPS Cost: 15,980 Bytes: 15,552 Cardinality: 243
                                   8 HASH JOIN Cost: 15,588 Bytes: 1,344 Cardinality: 28
                                        3 HASH JOIN Cost: 4,050 Bytes: 24,876,930 Cardinality: 829,231
                                             1 TABLE ACCESS FULL TEAM Cost: 3,394 Bytes: 879,444 Cardinality: 48,858
                                             2 INDEX FAST FULL SCAN NON-UNIQUE TASK2 Cost: 396 Bytes: 11,656,104 Cardinality: 971,342
                                        7 VIEW index$_join$_003 Cost: 10,376 Bytes: 24,981,984 Cardinality: 1,387,888
                                             6 HASH JOIN Cost: 15,588 Bytes: 1,344 Cardinality: 28
                                                  4 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT1 Cost: 3,835 Bytes: 24,981,984 Cardinality: 1,387,888
                                                  5 INDEX FAST FULL SCAN UNIQUE ASSIGNMENT4 Cost: 3,835 Bytes: 24,981,984 Cardinality: 1,387,888
                                   9 INDEX RANGE SCAN NON-UNIQUE TIMEENTRY5 Cost: 2 Cardinality: 12
                         17 VIEW USER25. Cost: 2,741 Bytes: 553,812 Cardinality: 29,148
                              16 SORT GROUP BY Cost: 2,741 Bytes: 1,107,624 Cardinality: 29,148
                                   15 HASH JOIN Cost: 2,540 Bytes: 1,107,624 Cardinality: 29,148
                                        13 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1 Bytes: 140 Cardinality: 10
                                             12 INDEX RANGE SCAN NON-UNIQUE TIMEPERIOD2 Cost: 1 Cardinality: 2
                                        14 TABLE ACCESS FULL TIMESHEET Cost: 2,537 Bytes: 12,040,224 Cardinality: 501,676
                    20 TABLE ACCESS BY INDEX ROWID TIMEPERIOD Cost: 1 Bytes: 22 Cardinality: 1
                         19 INDEX UNIQUE SCAN UNIQUE TIMEPERIOD1 Cardinality: 1
               32 NESTED LOOPS Cost: 5 Bytes: 75 Cardinality: 1
                    29 NESTED LOOPS Cost: 4 Bytes: 63 Cardinality: 1
                         27 NESTED LOOPS Cost: 2 Bytes: 37 Cardinality: 1
                              25 NESTED LOOPS Cost: 2 Bytes: 31 Cardinality: 1
                                   23 TABLE ACCESS BY INDEX ROWID OBS_TYPES Cost: 1 Bytes: 18 Cardinality: 1
                                        22 INDEX UNIQUE SCAN UNIQUE OBS_TYPES_U2 Cardinality: 1
                                   24 INDEX RANGE SCAN NON-UNIQUE PROJECT_INDX1 Cost: 1 Bytes: 13 Cardinality: 1
                              26 INDEX UNIQUE SCAN UNIQUE PROJECTS_PK Bytes: 6 Cardinality: 1
                         28 INDEX RANGE SCAN NON-UNIQUE OBS_ASSOCIATIONS_N3 Cost: 2 Bytes: 26 Cardinality: 1
                    31 TABLE ACCESS BY INDEX ROWID OBS_UNITS Cost: 1 Bytes: 12 Cardinality: 1
                         30 INDEX UNIQUE SCAN UNIQUE OBS_UNITS_U1 Cardinality: 1

Newly created index not being used

Hello friends,
I am observing that a newly created index on a z table with mandt & a new field is not being used. I have already rebuild index & updated stats for table.
when we query on this table with where clause having same 2 fields mandt & other.. we expected this index to be used. This table is very large. What more i can do now ?
In trace/SQL session, we can see it is going full table scan.. and takes very long time.
this new field contain no data as of now for all existing rows. Is this the reason ? or sometihng else ?
SQL Statement
SELECT
FROM
"ABSA"
WHERE
"MANDT" = :A0 AND "ZABCD" = :A1
Execution Plan
Explain from v$sql_plan not possible -> Explain from PLAN_TABLE is displayed !
No values in v$sql_plan for Address: 0000000166710240 Hash_value: 3891403872 Child_number: 0 Sql_id:
SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
        1 TABLE ACCESS FULL ZABSA
          ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
          Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
          Filter Predicates
NONUNIQUE Index   ZABSA~Z01
Column Name                     #Distinct
MANDT                                          1
ZABCD                                         1
thanks & regards
ashish
Edited by: ashish vikas on Mar 3, 2012 9:05 PM

ashish vikas wrote:
> Execution Plan
> Explain from v$sql_plan not possible -> Explain from PLAN_TABLE is displayed !
> No values in v$sql_plan for Address: 0000000166710240 Hash_value: 3891403872 Child_number: 0 Sql_id:
>
> SELECT STATEMENT ( Estimated Costs = 905.739 , Estimated #Rows = 110.190.667 )
>
>         1 TABLE ACCESS FULL ZABSA
>           ( Estim. Costs = 905.739 , Estim. #Rows = 110.190.667 )
>           Estim. CPU-Costs = 152.614.535.266 Estim. IO-Costs = 899.784
>           Filter Predicates
>
> NONUNIQUE Index   ZABSA~Z01
> Column Name                     #Distinct
> MANDT                                          1
> ZABCD                                         1
Hi,
with this WHERE clause, both columns just one distinct value, the Full Table Scan is indded the best approach, beside
the point you only need a check to evaluate a value is NOT in the result.
In this case you should HINT the statement to the new index, because the DB will always assume that this index is non-selective.
Volker

Linguistic index not being used

I am using 10G database and am having an issue that my linguistic index is not being used during sorting.
Any help will be appreciated.
Table structure.
create table TEST
ID CHAR(256) not null,
NAME VARCHAR2(100) not null,
DESIGNATION VARCHAR2(200)
alter table TEST add constraint ID primary key (ID)
create index TEST_IDX on TEST (NLSSORT(NAME,'nls_sort=''GENERIC_M'''))
Number of rows - 1 million
Query being run.
alter session set nls_sort='Generic_M';
select * from test order by name;
Explain plan
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1001K| 270M| | 70194 (1)| 00:14:0
3 |
| 1 | SORT ORDER BY | | 1001K| 270M| 579M| 70194 (1)| 00:14:0
3 |
| 2 | TABLE ACCESS FULL| TEST | 1001K| 270M| | 9163 (1)| 00:01:5
0 |
--------------------------------------------------------------------------------

I don't think that's true, at least with the nls_sort function. I'm running into the same problem now, and I've traced with and without the use of the index, and it's definitely better with the index.
Here it is, not using the index:
SQL> select * from test where col2='sfs';
no rows selected
Execution Plan
Plan hash value: 1357081020
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST | 1 | 366 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('7366730
0') )
Note
- dynamic sampling used for this statement
Statistics
87 recursive calls
0 db block gets
21 consistent gets
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
327 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
And here it is WITH the index:
SQL> select /*+ index_asc(test index1) */ * from test where col2='adsfas';
no rows selected
Execution Plan
Plan hash value: 2960817241
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
| 0 | SELECT STATEMENT | | 1 | 366 | 2 (0)| 00:0
0:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 366 | 2 (0)| 00:0
0:01 |
|* 2 | INDEX FULL SCAN | INDEX1 | 1 | | 1 (0)| 00:0
0:01 |
Predicate Information (identified by operation id):
2 - access(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
0') )
filter(NLSSORT("COL2",'nls_sort=''BINARY_CI''')=HEXTORAW('6164736661730
0') )
Note
- dynamic sampling used for this statement
Statistics
11 recursive calls
0 db block gets
7 consistent gets
0 physical reads
0 redo size
339 bytes sent via SQL*Net to client
327 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processed
Oddly enough, the optimizer chooses not to use the index on this example table I created.

Why is index not being used?

I need some help in trying to work out why an index isn't being used. I hope someone here can help.
Table definition for ACT_TOTALS includes
STARTTIME TIMESTAMP(6)
There is an index on to_char(starttime, 'YYYY-MM-DD HH24')
There is a vew definition ACT_TOTALS_HOURLY2 which includes
select to_char(starttime, 'YYYY-MM-DD HH24') STARTTIMSE
from ACT_TOTALS
group by to_char(starttime, 'YYYY-MM'DD HH24'), TRANSTYPE
I have run a query
select starttime from ACT_TOTALS_HOURLY2
where starttime <= to_char(sysdate, 'YYYY-MM-DD HH24');
The table access comes out as full despite there being > 2 million rows in the table.
The predicate looks like
TO_CHAR(INTERNAL_FUNCTION(''STARTTIME''), 'YYYY-MM-DD HH24')<= ..........
I thinkg the INTERNAL_FUNCTION is an implicit cast from DATE to TIMESTAMP.
Can anyone please throw any light on why the index on the table wouldn't be used in this case?
Thanks in advance for any help.

Can you supply a test case for that?
This is what I have done to engeneer your case
drop table t1;
create table t1 (n1 number, d1 date, STARTTIME TIMESTAMP(6));
insert into t1(n1,d1, starttime) select rownum, trunc(sysdate) + rownum, sysdate
from dual connect by level <= 2e6;
create or replace view t1_v as select n1, d1, to_char(starttime, 'YYYY-MM-DD HH24') starttimse
from t1;
SQL> explain plan for
2 select starttimse from t1_v
3 where starttimse <= to_char(sysdate, 'YYYY-MM-DD HH24');
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 838529891
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |   109K| 1394K| 2004 (14)| 00:00:12 |
|* 1 | TABLE ACCESS FULL| T1   |   109K| 1394K| 2004 (14)| 00:00:12 |
Predicate Information (identified by operation id):
   1 - filter(TO_CHAR(INTERNAL_FUNCTION("STARTTIME"),'YYYY-MM-DD
              HH24')<=TO_CHAR(SYSDATE@!,'YYYY-MM-DD HH24'))
Note
   - dynamic sampling used for this statement
SQL> create index t1_ind on t1 (to_char(starttime, 'YYYY-MM-DD HH24'));
Index created.
SQL> explain plan for
2 select starttimse from t1_v
3 where starttimse <= to_char(sysdate, 'YYYY-MM-DD HH24');
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3884685049
| Id | Operation        | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |        |   109K| 1394K|    68   (2)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| T1_IND |   109K| 1394K|    68   (2)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access(TO_CHAR(INTERNAL_FUNCTION("STARTTIME"),'YYYY-MM-DD
              HH24')<=TO_CHAR(SYSDATE@!,'YYYY-MM-DD HH24'))
Note
   - dynamic sampling used for this statement
The above selects are done against the view t1_v.
While the following one is done against the table t1
SQL> set autotrace traceonly explain
SQL> select starttime from t1
2 where starttime <= to_char(sysdate, 'YYYY-MM-DD HH24');
Execution Plan
Plan hash value: 838529891
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 29875 |   379K| 1790   (4)| 00:00:11 |
|* 1 | TABLE ACCESS FULL| T1   | 29875 |   379K| 1790   (4)| 00:00:11 |
Predicate Information (identified by operation id):
   1 - filter("STARTTIME"<=TO_TIMESTAMP(TO_CHAR(SYSDATE@!,'YYYY-MM-DD
              HH24')))
If you can post a clear test case of your issue may be one of us can help you
Best regards
Mohamed Houri
www.hourim.wordpress.com

Application Table Index not being created

Since this is slightly different than my last post, I created a new one.
I am using the example as a basis to complete the Bulk process from the Staging table to the Application table with the following code snippet:
public void completeBulk(String completeBulkFlags) throws Exception {
GraphOracleSem graph = null;
try {
graph = getModel().getGraph();
try {
graph.dropApplicationTableIndex();
} catch (SQLException e) {}
graph.getBulkUpdateHandler().completeBulk(completeBulkFlags, null);
graph.rebuildApplicationTableIndex();
finally {
if (graph != null)
graph.close();
It appears to be dropping the 'applicationTableIndex', however when the call 'rebuildApplicationTableIndex' the <MODEL_NAME>_IDX does not exist in the database. And i'm not seeing errors anywhere alerting me that the index was not created.
Since this index is not created, deletes on the model do not have an index to scan over the <MODEL_NAME>_TPL table and takes forever. For the time being, we are creating this index manually. However is there something that we are doing wrong using the Jena Adapter API?
We are using the newest Jena Adapter and 11.2.0.3 Database instance.
Thanks
-Michael

Hi Michael,
Your code looks fine.
Hmmm. That is strange. The code path for rebuilding application table index is quite straightforward. Can you please drop your own index and re-run the following by itself?
graph.rebuildApplicationTableIndex();
Thanks,
Zhe Wu

Index not being used in Select statement

Friends
I have the following SQL statement:
SELECT
a.acct,
a.date_field,
UPPER(b.feegroup) feegrp,
SUM (a.fee1) fee1,
SUM (a.fee2) fee2,
SUM (a.fee3) fee3
FROM table1 a, table2 b
WHERE 1 = 1
AND a.fee_id = b.fee_id
GROUP BY a.acct, a.date_field, b.feegroup;
Both the tables have index on fee_id column. When I run the explain plan for this statement, I am getting the following output:
Operation | Option | Object Name | Position
SELECT STATEMENT | | | 560299
HASH | GROUP BY| |1
TABLE ACCESS | FULL| table2 | 1
TABLE ACCESS | FULL| table1 | 2
Why Oracle is not using the index?
Edited by: darshilm on Dec 10, 2009 3:56 PM

The proposed plan is the optimal according to your current conditions in the "where clause" where you have only the equality join condition and therefore the CBO can use HASH JOIN. Using any kind of index access would just increase the amount of required work unless you would add some very restrictive conditions which will select rows from relatively small amount of blocks. Here I have to mention that what really counts in the CBO cost calculation is the amount of blocks accessed and not the number of rows. The "currency" for I/O in Oracle is a block and not a row. CBO always uses an assumption that there is nothing in the buffer cache and it will have to perform a physical read for every block.
How many blocks will actually be accessed depends on the data distribution. It can happen that every single row that you have to retrieve resides in a different block and although you access only 1000 rows out of a million row table you would have to visit almost every block of that table. For such a situation a FULL TABLE SCAN is the best access path and Oracle will use multiblock I/O for that. On the other side you can have those 1000 rows only in a few blocks and then the index access would be the most appropriate one. For index access Oracle uses single block I/O. Usually the actual situation is somewhere between this two extreme situations. But you can run some tests by yourself and see when an index access will be replaced by a full table scan while you will make your predicates less selective.
HTH, Joze
Co-author of the forthcoming book "Expert Oracle Practices"
http://www.apress.com/book/view/9781430226680
Oracle related blog: http://joze-senegacnik.blogspot.com/
Blog about flying: http://jsenegacnik.blogspot.com/
Blog about Building Ovens, Baking and Cooking: http://senegacnik.blogspot.com

Index not being used in Oracle 11g

Hi,
I executed an SQL in Oracle 9i based on a Materialized View with an index. Execution plan shows it used Index and did Range scan. But the same query if I executed in Oracle 11g, it did full table scan and ignored the index. Finally, I used /*+Index*/ hint to tell compiler to use the index. Can anyone tell why it happended like this.
below is the query.
SELECT TYPE,NAME,PARENT_ID,CHILD_ID,UNIT_OF_MEASURE,QUANTITY,POSITION_NUMBER
FROM MVIEW_BOM_CHILD_ATTRIBUTES
WHERE BREAKDOWN_LIMIT = 'FALSE'
CONNECT BY PRIOR CHILD_ID = PARENT_ID START WITH PARENT_ID IN ('7325','34676','10121','35154','34370','4909','5494','28714','2273','22551','36465','35416','7148','34774',' 23290','18225','24415','35774','34772','20108','19072','8134','14688','31751','12669','26450','34716','768 4','26004','8770','34001','32614','3816','19801','30329','13822','15784','9296','17147','35423','6181','3477 3','18683','20780','35191','17990','7788','1559','7691','35449','34640','35432','35829','14161','9412','2039 2','593','23744','15741','35850','4177','36420','34695','33027','34655','31315','13552','23089','14025','901 2','22930','36182','13413','13839','32502','2392','19666','35183','32174','35170','20545','14344','29190','1 8163','19124','35448','32171','23498','2694','31101','4357','30421','35826','17976','13218','34770','35778' ,'16112','36408','34797','3294','9600','23524','3663','36412','34674','26715','2886','3204','15928','4510','8 112','27232','14966','35217','6281','1610','16359','25906','10262','3291','35777','11789','34675','24208','1 0093','28479','2928','23396','19702','32716','29813','2536','2349','34639','18610','35175','9796','26915','6 041','4745','34718','17946','3285','34308','9451','29689','17903','34642','35166','4630','35760','35761','34 696','27958','5912','35549','17695','31595','8028','24020','16025','8004','6430','36391','3580','32433','354 94','27368','15801','35583','35488','18807','34180','26626','20629','34767','14771','28746','34728','4948',' 34355','14000','34734','35820','36449','4904','11136','35177','27740','8016','13883','36402','35233','2614 7','21089','33152','35162','11320','32843','7336','34654','35602','32026','35582','24500','10573','33778','1 651','22781','25784','30124','10798','15930','28652','1513','745','35415','30404','21990','20872','2272','16 273','4234','35601','35581','22088','15543','3362','7713','35431','34719','27710','33104','20482','16801','1 686','35658','16545','32681','8722','20046','8950','34799','31605','21299','19572','445','35489','35656','35 546','7414','13369','35455','35434','35438','19383','10591','24698','14607','25715','27913','1046','15511',' 36386','6801','25134','2717','2083','35288','15851','14538','35398','11575','35156','35435','4232','36380',' 18406','32862','20879','5695','4229','24132','7081','35420','34694','22474','30047','29352','34735','2305',' 36409','18040','13472','31481','29246').
Thanks

SBH wrote:
My doubt is only that is it possible that a SQL query with same index proprties uses different access path to execute. Is it dependent on oracle version also.
Yes, it is possible.
It is even possible on the same Oracle version - look at simple examples:
case 1
create table test as
select level l, 'test' test from dual
connect by level < 1000;
create index test_ix on test(l);
explain plan for
select * from test where l < 50;
select * from table(dbms_xplan.display);
Plan hash value: 1408842701
| Id | Operation                   | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |         |    49 |   931 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST    |    49 |   931 |     3   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | TEST_IX |    49 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("L"<50)
Note
   - dynamic sampling used for this statement (level=2)case 2
drop table test;
create table test as
select * from (
select level l, 'test' test from dual
connect by level < 1000
) order by dbms_random.value(0,100);
create index test_ix on test(l);
explain plan for
select * from test where l < 50;
select * from table(dbms_xplan.display);
Plan hash value: 1357081020
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |    49 |   931 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST |    49 |   931 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("L"<50)
Note
   - dynamic sampling used for this statement (level=2)The same query on the same table containing the same data in it. And the same index.
The only difference is records order in the table.
In the first case CBO decided that index range scan would be reasonable.
In the second case CBO preferred FTS as less costly.

Custom Objects in JNDI Not Being Replicated in Cluster

I know this is going to end up being something really simple, but I can't find
any docs or other posts on it.
I have a simple two node weblogic 7.0 cluster. In a startup class that is deployed
to the cluster I check for and create a subcontext. This subcontext will just
hold custom objects when a node comes up. When a node does come up, one of the
web applications binds a non-RMI custom object to the subcontext created via the
startup class.
Once both nodes in the cluster are up I can see via the weblogic console's "View
JNDI tree" feature that the custom object bound on node 1 is only visible in the
JNDI tree of node 1. Similarly the object bound on node 2 is only visible in
the JNDI tree of node 2.
Is the JNDI tree that is visible via the console the JNDI specific to the node
and not the clusterwide JNDI tree? Do I have to do something special to get access
to the cluster wide JNDI tree (for instance when creating an InitialContext)?
Is there a way to view the cluster wide JNDI tree?
Thanks for any information.

Hi Matt,
how did you compile t3 stubs,there are -clusterable or something like this
option shat should make replicatable-aware stubs.
"Matt" <[email protected]> wrote:
>
I know this is going to end up being something really simple, but I can't
find
any docs or other posts on it.
I have a simple two node weblogic 7.0 cluster. In a startup class that
is deployed
to the cluster I check for and create a subcontext. This subcontext
will just
hold custom objects when a node comes up. When a node does come up,
one of the
web applications binds a non-RMI custom object to the subcontext created
via the
startup class.
Once both nodes in the cluster are up I can see via the weblogic console's
"View
JNDI tree" feature that the custom object bound on node 1 is only visible
in the
JNDI tree of node 1. Similarly the object bound on node 2 is only visible
in
the JNDI tree of node 2.
Is the JNDI tree that is visible via the console the JNDI specific to
the node
and not the clusterwide JNDI tree? Do I have to do something special
to get access
to the cluster wide JNDI tree (for instance when creating an InitialContext)?
Is there a way to view the cluster wide JNDI tree?
Thanks for any information.

JNDI bindings not being replicated across servers in a cluster

According to the Weblogic Server documentation, JNDI bindings are
          automatically replicated across the servers in a cluster.
          http://www.weblogic.com/docs45/classdocs/weblogic.jndi.WLContext.html#REPLIC
          ATE_BINDINGS
          This is not proving to be true in my testing. Perhaps it's "just broken", or
          perhaps my cluster isn't correctly configured...
          Here is a reproducible case. Install the following on two or more servers in
          a cluster. You'll need to change line 26 of test1 to reference one of the
          servers explicitly.
          Test 1 works fine, since both web servers connect to the same server for
          JNDI usage. The test should return the last host to hit the page, along with
          the current host name. Alternating between servers in the cluster will
          alternate the results. However, the fact that I'm specifically naming a
          server in the cluster breaks the whole point of clustering -- if that server
          goes down, the application ceases to function properly.
          Test 2, which is supposedly the right way to do it, does not work, an error
          message is logged:
          Tue Jan 04 08:17:15 CST 2000:<I> <ConflictHandler> ConflictStart
          lastviewhost:java.lang.String (from
          [email protected]:[80,80,7002,7002,-1])
          And then both servers begin to report that they have been the only server to
          hit the page. Alternating between servers will have no effect -- both
          servers are looking solely at their own copies of the JNDI tree. No
          replication is occurring.
          What is up with this? Any ideas?
          Tim
          [test1.jsp]
          [test2.jsp]


1. yes
          <JMSConnectionFactory AllowCloseInOnMessage="false"
          DefaultDeliveryMode="Persistent" DefaultPriority="4"
          DefaultTimeToLive="0"
          JNDIName="xlink.jms.factory.commerceFactory"
          MessagesMaximum="10" Name="xlink.jms.factory.commerceFactory"
          OverrunPolicy="KeepOld" Targets="bluej,biztalk-lab,devtestCluster"/>
          2. No I am just using the jndi name of the queue.
          This is an example of how I send a message:
               Context ctx = new InitialContext();
          QueueConnectionFactory qconFactory;
          QueueConnection qcon;
          QueueSession qsession;
          QueueSender qsender;
          Queue queue;
          ObjectMessage msg;
          qconFactory = (QueueConnectionFactory) ctx.lookup("xlink.jms.factory.commerceFactory");
          qcon = qconFactory.createQueueConnection();
          qsession = qcon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
          queue = (Queue) ctx.lookup("xlink.jms.queue.biztalk-lab.OrdrspImport");
          qsender = qsession.createSender(queue);
          msg = qsession.createObjectMessage(reportExecutorContainer);
          qcon.start();
          qsender.send(msg);
          qsender.close();
          qsession.close();
          qcon.close();
          3. I don't know those setting (wl 6.1sp7)

Index not being used

Hi all,
10.2.0.1
I have a query of the kind
SELECT   DISTINCT a.trea_code,
                  a.class1,
                  a.class2,
                  a.class3,
                  a.class4,
                  a.other,
                  a.gross_pay,
                  b.trea_name
FROM     (SELECT   trea_code,
                   Count(CASE
                           WHEN empl_code = '1'
                           THEN emp_code
                         END) class1,
                   Count(CASE
                           WHEN empl_code = '2'
                           THEN emp_code
                         END) class2,
                   Count(CASE
                           WHEN empl_code = '3'
                           THEN emp_code
                         END) class3,
                   Count(CASE
                           WHEN empl_code = '4'
                           THEN emp_code
                         END) class4,
                   Count(CASE
                           WHEN empl_code = '5'
                           THEN emp_code
                         END) other,
                   Sum(CASE
                         WHEN empl_code BETWEEN '1' AND '5'
                         THEN gross_pay
                       END) gross_pay
          FROM     mon_act
          WHERE    v_no IS NOT NULL
                   --and upto_date between to_date('01-JAN-10') and to_date('31-JAN-10')
                   AND To_char(upto_date,'MONYYYY') = 'JAN2010'
          GROUP BY trea_code
          ORDER BY 1) a,
         treasury.trea_mast b
WHERE    a.trea_code = b.trea_code
ORDER BY 1 The trea_code,emp_code,upto_date column of mon_Act are primary key indexed[pk_monact].
Upon creating a function based index on to_char(upto_date,'MONYYYY'), oracle uses the function based index.
But If query as
SELECT   DISTINCT a.trea_code,
                  a.class1,
                  a.class2,
                  a.class3,
                  a.class4,
                  a.other,
                  a.gross_pay,
                  b.trea_name
FROM     (SELECT   trea_code,
                   Count(CASE
                           WHEN empl_code = '1'
                           THEN emp_code
                         END) class1,
                   Count(CASE
                           WHEN empl_code = '2'
                           THEN emp_code
                         END) class2,
                   Count(CASE
                           WHEN empl_code = '3'
                           THEN emp_code
                         END) class3,
                   Count(CASE
                           WHEN empl_code = '4'
                           THEN emp_code
                         END) class4,
                   Count(CASE
                           WHEN empl_code = '5'
                           THEN emp_code
                         END) other,
                   Sum(CASE
                         WHEN empl_code BETWEEN '1' AND '5'
                         THEN gross_pay
                       END) gross_pay
          FROM     mon_act
          WHERE    v_no IS NOT NULL
                   and upto_date between to_date('01-JAN-10') and to_date('31-JAN-10')
                   --AND To_char(upto_date,'MONYYYY') = 'JAN2010'
          GROUP BY trea_code
          ORDER BY 1) a,
         treasury.trea_mast b
WHERE    a.trea_code = b.trea_code
ORDER BY 1 Oracle does not use the index pk_monact and does a n expansive full scan of mon_act.
The statistics are upto date.
Even if i use a hint as /*+ mon_act pk_monact */ in the outer query,it does not use an index.
Why it is ignoring the index based on primary key?

Hi !
Which execution plan to use , CBO decides based on its own calculations which depends on ... many things . You can
analize CBO decision with activating event 10053 and analyzing output ( trace file )
ALTER SESSION SET EVENTS='10053 trace name context forever, level 1'; --- activate tracing
-- run your query
ALTER SESSION SET EVENTS '10053 trace name context off'; --- deactivate tracing
analize recent trace file using TKPROF T

Performance issue - Index not being used

Hi,
I have the following scenario
- I have a table Account with a PK -Account_ID, for which there is a index PK_ACCOUNT_ID_IDX
- Another table Account_fact has a PK - Account_ID, Month_Year, for which there is a index PK_ACCOUNT_FACT_IDX
I have a join in these two table. The query is
select a.ACCOUNT_ID, b.Cost
From Account a, Account_fact b
Where a.account_id = b.Account_id
and a.Include_flag = 'Y'
The explain plan for this query tells me its doing a Full table scan and not using the index and the cost of query is very high.
Can any one suggest what is wrong here.
Regards
Deepak

>> Shud I be creating a bit map index.
Bit map index is not for this case.
http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96533/data_acc.htm#8131
Also bitmaps are very dangerous for Transactional tables. They are not meant for them.
As I told you in this case create index on all the columns you are using in the query.
For example INCLUDE_FLAG, ACCOUNT_ID in ACCOUNT table
ACCOUNT_ID, COST in the other table.
But keep in mind that if you are selecting any other column from these tables then again it might opt for full table scan......

Indexes not being replicated

Similar Messages

Maybe you are looking for