Your NO_INDEX hint appears to be incompletely formed. Please try the following to see if the execution plan changes:

select count(*) from
(select /*+ NO_INDEX(c CDR_IND_03) */
s.main_resource, s.OPERATOR_CODE , s.ORIGINATED_PREPAID_IND
from   lb_5.subscriber s , lb_5.cdr c
where
c.recieve_time between TO_DATE('01/01/2012','DD/MM/YYYY') and TO_DATE('09/02/2012','DD/MM/YYYY')
and s.operator_code='Partner'
and s.ORIGINATED_PREPAID_IND='0'
and s.main_resource=c.Anumber
and substr(lb_5.get_avl(avl,'DialedDigits'),1,3) = '117'
group by s.main_resource, s.OPERATOR_CODE , s.ORIGINATED_PREPAID_IND)

Following is an example of NO_INDEX is not working in 10g: Same SQL in 11.2.0.2 w/o any hints doesn’t use the Index and working much mush faster:

select count(*) from
(select /*+ NO_INDEX(c CDR_IND_03*/
s.main_resource, s.OPERATOR_CODE , s.ORIGINATED_PREPAID_IND
from   lb_5.subscriber s , lb_5.cdr c
where
c.recieve_time between TO_DATE('01/01/2012','DD/MM/YYYY') and TO_DATE('09/02/2012','DD/MM/YYYY')
and s.operator_code='Partner'
and s.ORIGINATED_PREPAID_IND='0'
and s.main_resource=c.Anumber
and substr(lb_5.get_avl(avl,'DialedDigits'),1,3) = '117'
group by s.main_resource, s.OPERATOR_CODE , s.ORIGINATED_PREPAID_IND)

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1033640149

-----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                               | Name       | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop 
-----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                        |            |     1 |       |       |   923   (1)| 00:00:12 |       |       
|   1 |  SORT AGGREGATE                         |            |     1 |       |       |            |          |       |       
|   2 |   VIEW                                  |            |  3377 |       |       |   923   (1)| 00:00:12 |       |       
|   3 |    HASH GROUP BY                        |            |  3377 |  2186K|  4520K|   923   (1)| 00:00:12 |       |       
|*  4 |     HASH JOIN                           |            |  3377 |  2186K|       |   447   (2)| 00:00:06 |       |       
|*  5 |      TABLE ACCESS FULL                  | SUBSCRIBER | 27819 |   516K|       |   446   (1)| 00:00:06 |       |       
|   6 |      PARTITION RANGE ITERATOR           |            | 15575 |  9795K|       |     0   (0)| 00:00:01 |     9 |    18 
|   7 |       PARTITION LIST ALL                |            | 15575 |  9795K|       |     0   (0)| 00:00:01 |     1 |    17 
|*  8 |        TABLE ACCESS BY LOCAL INDEX ROWID| CDR        | 15575 |  9795K|       |     0   (0)| 00:00:01 |   137 |   306 
|*  9 |         INDEX SKIP SCAN                 | CDR_IND_03 | 52700 |       |       |     0   (0)| 00:00:01 |   137 |   306 
-----------------------------------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   4 - access("S"."MAIN_RESOURCE"="C"."ANUMBER")
   5 - filter("S"."MAIN_RESOURCE" IS NOT NULL AND "S"."ORIGINATED_PREPAID_IND"=0 AND "S"."OPERATOR_CODE"='Partner')

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------
   8 - filter(SUBSTR("LB_5"."GET_AVL"("AVL",'DialedDigits'),1,3)='117')
   9 - access("C"."RECIEVE_TIME">=TO_DATE(' 2012-01-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
              "C"."RECIEVE_TIME"<=TO_DATE(' 2012-02-09 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
       filter("C"."RECIEVE_TIME"<=TO_DATE(' 2012-02-09 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))

26 rows selected.

That MOS (Metalink) article is an interesting find – thank you for locating it.

I see that the article was last modified November 11, 2010. The article lists as a reference a bug that applies to Oracle Database 7.1.6.2. I think that the MOS article is in need of quite a bit of editing. The take aways from that article:
* Can a unique index not be a b*tree index?
* I should set DB_FILE_MULTIBLOCK_READ_COUNT to a value greater than 16 so that my NO_INDEX hint works?

Here is a quick test on 11.2.0.2 to demonstrate that the MOS article does not apply to 11.2.0.2 (that is one of the few release versions you did not test). First, a basic query using the sample table created in the article:

SET LINESIZE 140
SET PAGESIZE 1000
 
SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3,
  SUBSTR(C4,1,10) C4
FROM
  T3
WHERE
  C1<=20;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  0s5xrvx04309f, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3,
SUBSTR(C4,1,10) C4 FROM   T3 WHERE   C1<=20
 
Plan hash value: 1371903174
 
---------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name      | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |           |      1 |        |     20 |00:00:00.01 |       8 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T3        |      1 |     20 |     20 |00:00:00.01 |       8 |
|*  2 |   INDEX RANGE SCAN          | IND_T3_C1 |      1 |     20 |     20 |00:00:00.01 |       5 |
---------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C1"<=20)

The non-unique index was selected by default.

Now drop that non-unique index, create a unique index on the same column, and try the SQL statement again:

DROP INDEX IND_T3_C1;
CREATE UNIQUE INDEX IND_T3_C1_UNIQUE ON T3(C1);
 
EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>USER,TABNAME=>'T3',CASCADE=>TRUE,ESTIMATE_PERCENT=>100)
 
SELECT /*+ GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3,
  SUBSTR(C4,1,10) C4
FROM
  T3
WHERE
  C1<=20;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  0s5xrvx04309f, child number 0
-------------------------------------
SELECT /*+ GATHER_PLAN_STATISTICS */   C1,   C2,   C3,
SUBSTR(C4,1,10) C4 FROM   T3 WHERE   C1<=20
 
Plan hash value: 66750336
 
----------------------------------------------------------------------------------------------------------
| Id  | Operation                   | Name             | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |                  |      1 |        |     20 |00:00:00.01 |       8 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T3               |      1 |     20 |     20 |00:00:00.01 |       8 |
|*  2 |   INDEX RANGE SCAN          | IND_T3_C1_UNIQUE |      1 |     20 |     20 |00:00:00.01 |       5 |
----------------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("C1"<=20)

The optimizer selected to use the unique index, as expected.

Trying again with the NO_INDEX hint:

SELECT /*+ NO_INDEX(T3 IND_T3_C1_UNIQUE) GATHER_PLAN_STATISTICS */
  C1,
  C2,
  C3,
  SUBSTR(C4,1,10) C4
FROM
  T3
WHERE
  C1<=20;
 
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
 
SQL_ID  gvsjzs6x62f1d, child number 0
-------------------------------------
SELECT /*+ NO_INDEX(T3 IND_T3_C1_UNIQUE) GATHER_PLAN_STATISTICS */
C1,   C2,   C3,   SUBSTR(C4,1,10) C4 FROM   T3 WHERE   C1<=20
 
Plan hash value: 4161002650
 
------------------------------------------------------------------------------------
| Id  | Operation         | Name | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |      1 |        |     20 |00:00:00.01 |   45583 |
|*  1 |  TABLE ACCESS FULL| T3   |      1 |     20 |     20 |00:00:00.01 |   45583 |
------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("C1"<=20)

The NO_INDEX hint worked without issue – a full table scan was performed.

—

Another interesting MOS article is this one Doc ID 1051265.1, Bug 5882821 – “Wrong Results from a RANGE-LIST PARTITIONED TABLE”. Here the NO_INDEX hint was used to produce the correct query results, while the unhinted version provided incorrect results.

Ineffective SQL Hints NO_INDEX [ID 399942.1]

It says “The NO_INDEX hint does not applying to UNIQUE indexes. The NO_INDEX hint applies to function-based, B*-tree, bitmap, cluster, or domain indexes.”

I have tested it on 9.2.0.8, 10.2.0.3 and 11.2.0.1 and I see that “no_index hint” WORKS as intended even on unique indexes.