Degraded Performance with Partitioning

We are using Oracle 11.2.0.3 on Solaris. There is a view defined on a few tables. Because of its complexness and the size of tables, the performance of the view is not good. So, I changed two of the tables to partitioned tables, list-partitioned by year. All indexes on these two tables were changed to local partitioned, with year as the leading index keys. Statistics on all tables and indexes were collected. I then created a new view with the two tables replaced with the partitioned ones. I also ran SQL Tuning advisor and created recommended indexes. I hoped the new view would be faster than the old one, but the fact is the opposite.
The old view has order-by clause. If I remove the order-by in the new view, the elapsed time is close to the old one which has order-by. With "select * from new-view order by ...", or even a "select count(*) from new-view", I never got a return in few hours.
SQL Tuning Advisor shows partition-pruning, all operations are on one partition, and the only recommendation now is accepting SQL profile. I don't understand why partitioning has such a bad result. This is really frustrating to me. Not sure if anyone here experienced something similar, or know there is an Oracle bug, or can tell me where I am lost.
Appreciate your advice.
Gary
Edited by: user12131557 on Feb 25, 2013 3:15 PM

This is the old plan. Again, please replace # with seven spaces to read.
| Id | Operation#######   | Name###      | Rows | Bytes |TempSpc| Cost |
|   0 | SELECT STATEMENT######   |####    |#|#|#| 50259 |
|   1 | SORT ORDER BY######     |####    |    27 | 21951 |#| 50259 |
|   2 |   VIEW#######      | VW_BCZC_REPORT##   |    27 | 21951 |#| 50233 |
|   3 |    SORT ORDER BY######   |####    |    27 | 8937 |#| 50233 |
|   4 |     NESTED LOOPS OUTER#####    |####    |    27 | 8937 |#| 50207 |
|* 5 |      HASH JOIN OUTER#####      |####    |    27 | 7614 |#| 50167 |
|* 6 |#HASH JOIN######    |####    |    27 | 6291 |#| 46428 |
|   7 |# TABLE ACCESS FULL##### | HSD_SUMMARY_OUTPUT#      |   762 | 21336 |#|     4 |
|* 8 |# HASH JOIN######   |####    | 44145 | 8837K|#| 46421 |
|   9 |# TABLE ACCESS FULL##### | HSD_LOOKUP###|   132 | 6732 |#|     3 |
|* 10 |# HASH JOIN###### |####    | 43142 | 6488K|#| 46417 |
| 11 |#   TABLE ACCESS FULL#####| HSD_COUNTY###| 3227 | 74221 |#|     4 |
|* 12 |#   HASH JOIN###### |####    | 43142 | 5519K|#| 46406 |
| 13 |#    VIEW######     |####    |     4 |    56 |#|   208 |
| 14 |#     SORT UNIQUE#####    |####    |     4 |   406 |#|   208 |
| 15 |#      UNION-ALL#####     |####    |#|#|#|#|
|* 16 |##FILTER######|####    |#|#|#|#|
| 17 |## SORT GROUP BY####      |####    |     1 |   109 |#|    67 |
| 18 |## NESTED LOOPS####      |####    |     1 |   109 |#|    18 |
| 19 |##   NESTED LOOPS####     |####    |     1 |    67 |#|    17 |
|* 20 |##    INDEX FULL SCAN#### | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   230 |#|     2 |
| 21 |##    TABLE ACCESS BY INDEX ROWID##   | CONTRACT_X_COUNTY##|     1 |    44 |#|     2 |
|* 22 |##     INDEX RANGE SCAN###      | CONTRACT_X_COUNTY_APP_ID_IDX   |     1 |#|#|     1 |
|* 23 |##   INDEX RANGE SCAN#### | CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
|* 24 |##FILTER######|####    |#|#|#|#|
| 25 |## SORT GROUP BY####      |####    |     1 |   106 |#|    62 |
| 26 |## NESTED LOOPS####      |####    |     1 |   106 |#|    13 |
| 27 |##   NESTED LOOPS####     |####    |     1 |    64 |#|    12 |
|* 28 |##    INDEX FULL SCAN#### | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   230 |#|     2 |
|* 29 |##    TABLE ACCESS BY INDEX ROWID##   | CONTRACT_X_PARTIAL_ZIPCODE     |     1 |    41 |#|     1 |
|* 30 |##     INDEX RANGE SCAN###      | CONTRACT_X_PAR_ZIP_APP_ID_IDX |     1 |#|#|     1 |
|* 31 |##   INDEX RANGE SCAN#### | CONTRACT_X_PARTIAL_ZIPCODE_PK |     1 |    42 |#|     1 |
|* 32 |##FILTER######|####    |#|#|#|#|
| 33 |## NESTED LOOPS#####|####    |     1 |    94 |#|     8 |
| 34 |## NESTED LOOPS####      |####    |     1 |    72 |#|     6 |
| 35 |##   NESTED LOOPS####     |####    |     1 |    63 |#|     5 |
| 36 |##    NESTED LOOPS####    |####    |     1 |    52 |#|     4 |
|* 37 |##     TABLE ACCESS BY INDEX ROWID## | CONTRACT_INFORMATION#    |     1 |    25 |#|     3 |
|* 38 |##      INDEX RANGE SCAN###     | IX2_CONTRACT_INFORMATION#|     1 |#|#|     2 |
| 39 |###SORT AGGREGATE###      |####    |     1 |    22 |#|#|
| 40 |### FIRST ROW####   |####    |     1 |    22 |#|     1 |
|* 41 |### INDEX RANGE SCAN (MIN/MAX)#      | CONTRACT_INFORMATION_PK# |     1 |    22 |#|     1 |
|* 42 |##     TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_REGION##|     1 |    27 |#|     1 |
|* 43 |##      INDEX RANGE SCAN###     | CONTRACT_X_REGION_PK#    |     1 |#|#|     1 |
|* 44 |##    INDEX RANGE SCAN####| HSD_SUMMARY_OUTPUT_INDX4#|     1 |    11 |#|     1 |
| 45 |##   TABLE ACCESS BY INDEX ROWID##    | STATES###    |     1 |     9 |#|     1 |
|* 46 |##    INDEX RANGE SCAN####| STATES_INDX2##     |     2 |#|#|     1 |
|* 47 |## TABLE ACCESS BY INDEX ROWID##     | COUNTIES### |     2 |    44 |#|     2 |
|* 48 |##   INDEX RANGE SCAN#### | COUNTIES_INDX_4## |    54 |#|#|     1 |
| 49 |## SORT AGGREGATE####     |####    |     1 |    25 |#|#|
|* 50 |## TABLE ACCESS BY INDEX ROWID##     | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|* 51 |##   INDEX RANGE SCAN#### | IX1_CONTRACT_X_REGION#   |     1 |#|#|     1 |
|* 52 |##FILTER######|####    |#|#|#|#|
| 53 |## NESTED LOOPS#####|####    |     1 |    97 |#|    18 |
| 54 |## NESTED LOOPS####      |####    |     1 |    75 |#|    16 |
| 55 |##   NESTED LOOPS####     |####    |     1 |    66 |#|    15 |
| 56 |##    NESTED LOOPS####    |####    |     4 |   152 |#|    11 |
|* 57 |##     INDEX RANGE SCAN###      | IX1_HSD_SUMMARY_OUTPUT# |    10 |   110 |#|     1 |
|* 58 |##     TABLE ACCESS BY INDEX ROWID## | CONTRACT_X_REGION##|     1 |    27 |#|     1 |
|* 59 |##      INDEX RANGE SCAN###     | CONTRACT_X_REGION_PK#    |     1 |#|#|     1 |
|* 60 |##    TABLE ACCESS BY INDEX ROWID##   | CONTRACT_INFORMATION#    |     1 |    28 |#|     1 |
|* 61 |##     INDEX RANGE SCAN###      | CONTRACT_INFORMATION_PK# |     1 |#|#|     1 |
| 62 |##      SORT AGGREGATE####|####    |     1 |    22 |#|#|
| 63 |###FIRST ROW####    |####    |     1 |    22 |#|     1 |
|* 64 |### INDEX RANGE SCAN (MIN/MAX)##| CONTRACT_INFORMATION_PK# |     1 |    22 |#|     1 |
| 65 |##   TABLE ACCESS BY INDEX ROWID##    | STATES###    |     1 |     9 |#|     1 |
|* 66 |##    INDEX RANGE SCAN####| STATES_INDX1##     |     1 |#|#|     1 |
|* 67 |## TABLE ACCESS BY INDEX ROWID##     | COUNTIES### |     2 |    44 |#|     2 |
|* 68 |##   INDEX RANGE SCAN#### | COUNTIES_INDX_4## |    54 |#|#|     1 |
| 69 |## SORT AGGREGATE####     |####    |     1 |    25 |#|#|
|* 70 |## TABLE ACCESS BY INDEX ROWID##     | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|* 71 |##   INDEX RANGE SCAN#### | IX1_CONTRACT_X_REGION#   |     1 |#|#|     1 |
| 72 |#    VIEW######     |####    | 1078K|   120M|#| 46189 |
| 73 |#     SORT GROUP BY##### |####    | 1078K|   120M|#| 46189 |
| 74 |#      VIEW######   |####    | 1078K|   120M|#| 35578 |
| 75 |##SORT UNIQUE##### |####    | 1078K|   147M|   324M| 35578 |
| 76 |## UNION-ALL#####   |####    |#|#|#|#|
|* 77 |## FILTER#####     |####    |#|#|#|#|
|* 78 |##   HASH JOIN OUTER#### |####    | 1078K|   147M|   141M| 5496 |
| 79 |##    VIEW#####     |####    | 1078K|   129M|#| 1082 |
|* 80 |##     HASH JOIN####      |####    | 1078K|    46M|#| 1082 |
| 81 |##      INDEX FULL SCAN###      | HSD_SUMMARY_OUTPUT_INDX3#|   762 | 11430 |#|     2 |
| 82 |##      TABLE ACCESS FULL###    | HSD_NCB_OUTPUT##   | 1078K|    30M|#| 1071 |
| 83 |##    VIEW#####     |####    |     5 |    85 |#| 2152 |
| 84 |##     SORT UNIQUE####    |####    |     5 |   262 |#| 2152 |
| 85 |##      UNION-ALL####     |####    |#|#|#|#|
| 86 |###VIEW##### |####    |     4 |    68 |#|   203 |
| 87 |### SORT UNIQUE#### |####    |     4 |   398 |#|   203 |
| 88 |### UNION-ALL#### |####    |#|#|#|#|
|* 89 |###   FILTER####    |####    |#|#|#|#|
| 90 |###    SORT GROUP BY###   |####    |     1 |   107 |#|    62 |
| 91 |###     NESTED LOOPS###   |####    |     1 |   107 |#|    13 |
| 92 |###      NESTED LOOPS### |####    |     1 |    65 |#|    12 |
|* 93 |####INDEX FULL SCAN##     | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   230 |#|     2 |
|* 94 |####INDEX RANGE SCAN##    | CONTRACT_X_COUNTY_APP_ID_IDX   |     1 |    42 |#|     1 |
|* 95 |###      INDEX RANGE SCAN##     | CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
|* 96 |###   FILTER####    |####    |#|#|#|#|
| 97 |###    SORT GROUP BY###   |####    |     1 |   104 |#|    62 |
| 98 |###     NESTED LOOPS###   |####    |     1 |   104 |#|    13 |
| 99 |###      NESTED LOOPS### |####    |     1 |    62 |#|    12 |
|*100 |####INDEX FULL SCAN##     | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   230 |#|     2 |
|*101 |####TABLE ACCESS BY INDEX ROWID#| CONTRACT_X_PARTIAL_ZIPCODE     |     1 |    39 |#|     1 |
|*102 |#### INDEX RANGE SCAN##   | CONTRACT_X_PAR_ZIP_APP_ID_IDX |     1 |#|#|     1 |
|*103 |###      INDEX RANGE SCAN##     | CONTRACT_X_PARTIAL_ZIPCODE_PK |     1 |    42 |#|     1 |
|*104 |###   FILTER####    |####    |#|#|#|#|
|*105 |###    FILTER####   |####    |#|#|#|#|
| 106 |###     NESTED LOOPS###   |####    |     1 |    92 |#|     8 |
| 107 |###      NESTED LOOPS### |####    |     1 |    70 |#|     6 |
| 108 |####NESTED LOOPS### |####    |     1 |    61 |#|     5 |
| 109 |#### NESTED LOOPS###|####    |     1 |    50 |#|     4 |
|*110 |#### TABLE ACCESS BY INDEX ROWID     | CONTRACT_INFORMATION#    |     1 |    25 |#|     3 |
|*111 |####   INDEX RANGE SCAN## | IX2_CONTRACT_INFORMATION#|     1 |#|#|     2 |
| 112 |####    SORT AGGREGATE## |####    |     1 |    22 |#|#|
| 113 |####     FIRST ROW##      |####    |     1 |    22 |#|     1 |
|*114 |####      INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# |     1 |    22 |#|     1 |
|*115 |#### TABLE ACCESS BY INDEX ROWID     | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*116 |####   INDEX RANGE SCAN## | CONTRACT_X_REGION_PK#    |     1 |#|#|     1 |
|*117 |#### INDEX RANGE SCAN##   | HSD_SUMMARY_OUTPUT_INDX4#|     1 |    11 |#|     1 |
| 118 |####TABLE ACCESS BY INDEX ROWID#| STATES###    |     1 |     9 |#|     1 |
|*119 |#### INDEX RANGE SCAN##   | STATES_INDX2##     |     2 |#|#|     1 |
|*120 |###      TABLE ACCESS BY INDEX ROWID# | COUNTIES### |     2 |    44 |#|     2 |
|*121 |####INDEX RANGE SCAN##    | COUNTIES_INDX_4## |    54 |#|#|     1 |
| 122 |###    SORT AGGREGATE### |####    |     1 |    25 |#|#|
|*123 |###     TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*124 |###      INDEX RANGE SCAN##     | IX1_CONTRACT_X_REGION#   |     1 |#|#|     1 |
|*125 |###   FILTER####    |####    |#|#|#|#|
|*126 |###    FILTER####   |####    |#|#|#|#|
| 127 |###     NESTED LOOPS###   |####    |     1 |    95 |#|    18 |
| 128 |###      NESTED LOOPS### |####    |     1 |    73 |#|    16 |
| 129 |####NESTED LOOPS### |####    |     1 |    64 |#|    15 |
| 130 |#### NESTED LOOPS###|####    |     4 |   144 |#|    11 |
|*131 |#### INDEX RANGE SCAN## | IX1_HSD_SUMMARY_OUTPUT# |    10 |   110 |#|     1 |
|*132 |#### TABLE ACCESS BY INDEX ROWID     | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*133 |####   INDEX RANGE SCAN## | CONTRACT_X_REGION_PK#    |     1 |#|#|     1 |
|*134 |#### TABLE ACCESS BY INDEX ROWID      | CONTRACT_INFORMATION#    |     1 |    28 |#|     1 |
|*135 |#### INDEX RANGE SCAN## | CONTRACT_INFORMATION_PK# |     1 |#|#|     1 |
| 136 |####   SORT AGGREGATE##   |####    |     1 |    22 |#|#|
| 137 |####    FIRST ROW###|####    |     1 |    22 |#|     1 |
|*138 |####     INDEX RANGE SCAN (MIN/MAX)   | CONTRACT_INFORMATION_PK# |     1 |    22 |#|     1 |
| 139 |####TABLE ACCESS BY INDEX ROWID#| STATES###    |     1 |     9 |#|     1 |
|*140 |#### INDEX RANGE SCAN##   | STATES_INDX1##     |     1 |#|#|     1 |
|*141 |###      TABLE ACCESS BY INDEX ROWID# | COUNTIES### |     2 |    44 |#|     2 |
|*142 |####INDEX RANGE SCAN##    | COUNTIES_INDX_4## |    54 |#|#|     1 |
| 143 |###    SORT AGGREGATE### |####    |     1 |    25 |#|#|
|*144 |###     TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*145 |###      INDEX RANGE SCAN##     | IX1_CONTRACT_X_REGION#   |     1 |#|#|     1 |
| 146 |###INTERSECTION#### |####    |#|#|#|#|
| 147 |### SORT UNIQUE#### |####    |     1 |    97 |#|#|
|*148 |### FILTER####     |####    |#|#|#|#|
| 149 |###   SORT GROUP BY###    |####    |     1 |    97 |#| 1822 |
|*150 |###    HASH JOIN####|####    |     7 |   679 |#| 1773 |
|*151 |###     TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_COUNTY##| 2357 | 98994 |#|   885 |
|*152 |###      INDEX RANGE SCAN##     | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
| 153 |###     NESTED LOOPS OUTER##    |####    | 2338 |   125K|#|   886 |
|*154 |###      TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_COUNTY##| 2338 | 86506 |#|   885 |
|*155 |####INDEX RANGE SCAN##    | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
|*156 |###      INDEX UNIQUE SCAN##    | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
| 157 |### SORT UNIQUE#### |####    |     1 |    97 |#|#|
|*158 |### FILTER####     |####    |#|#|#|#|
| 159 |###   SORT GROUP BY###    |####    |     1 |    97 |#|   103 |
| 160 |###    NESTED LOOPS###    |####    |     1 |    97 |#|    54 |
| 161 |###     NESTED LOOPS OUTER##    |####    |    20 | 1100 |#|    34 |
|*162 |###      INDEX RANGE SCAN##     | IX1_CONTRACT_X_COUNTY#   |    20 |   740 |#|    33 |
|*163 |###      INDEX UNIQUE SCAN##    | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
|*164 |###     INDEX RANGE SCAN##      | CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
| 165 |## TABLE ACCESS BY INDEX ROWID##     | HSD_NCB_OUTPUT##   |     1 |    30 |#|     2 |
| 166 |##   NESTED LOOPS####     |####    |     1 |    78 |#| 6158 |
|*167 |##    HASH JOIN#####|####    |     1 |    48 |#| 6157 |
| 168 |##     NESTED LOOPS####   |####    |     1 |    31 |#| 4004 |
| 169 |##      VIEW#####   |####    |     2 |    32 |#| 4004 |
| 170 |###SORT UNIQUE#### |####    |     2 |   152 |#| 4004 |
| 171 |### UNION-ALL####   |####    |#|#|#|#|
|*172 |### HASH JOIN#### |####    |     1 |    88 |#| 2002 |
|*173 |###   FILTER####    |####    |#|#|#|#|
|*174 |###    HASH JOIN OUTER### |####    |     1 |    64 |#| 1938 |
|*175 |###     TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_PARTIAL_ZIPCODE     |     1 |    40 |#|     1 |
| 176 |###      NESTED LOOPS### |####    |     1 |    56 |#|    12 |
|*177 |####INDEX FULL SCAN##     | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   160 |#|     2 |
|*178 |####INDEX RANGE SCAN##    | CONTRACT_X_PAR_ZIP_APP_ID_IDX |     1 |#|#|     1 |
| 179 |###     VIEW####    | VW_HSD_PARTIAL_EXPANSION_ONLY |     1 |     8 |#| 1925 |
| 180 |###      INTERSECTION### |####    |#|#|#|#|
| 181 |####SORT UNIQUE### |####    |     1 |    97 |#|#|
|*182 |#### FILTER###      |####    |#|#|#|#|
| 183 |#### SORT GROUP BY##     |####    |     1 |    97 |#| 1822 |
|*184 |####   HASH JOIN### |####    |     7 |   679 |#| 1773 |
|*185 |####    TABLE ACCESS BY INDEX ROWID   | CONTRACT_X_COUNTY##| 2357 | 98994 |#|   885 |
|*186 |####     INDEX RANGE SCAN#      | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
| 187 |####    NESTED LOOPS OUTER#     |####    | 2338 |   125K|#|   886 |
|*188 |####     TABLE ACCESS BY INDEX ROWID | CONTRACT_X_COUNTY##| 2338 | 86506 |#|   885 |
|*189 |####      INDEX RANGE SCAN#     | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
|*190 |####     INDEX UNIQUE SCAN#     | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
| 191 |####SORT UNIQUE### |####    |     1 |    97 |#|#|
|*192 |#### FILTER###      |####    |#|#|#|#|
| 193 |#### SORT GROUP BY##     |####    |     1 |    97 |#|   103 |
| 194 |####   NESTED LOOPS##     |####    |     1 |    97 |#|    54 |
| 195 |####    NESTED LOOPS OUTER#     |####    |    20 | 1100 |#|    34 |
|*196 |####     INDEX RANGE SCAN#      | IX1_CONTRACT_X_COUNTY#   |    20 |   740 |#|    33 |
|*197 |####     INDEX UNIQUE SCAN#     | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
|*198 |####    INDEX RANGE SCAN##| CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
| 199 |###   VIEW####      | VW_SQ_7###   |    30 |   720 |#|    64 |
|*200 |###    FILTER####   |####    |#|#|#|#|
| 201 |###     SORT GROUP BY### |####    |    30 | 1530 |#|    64 |
|*202 |###      INDEX FAST FULL SCAN## | CONTRACT_X_PARTIAL_ZIPCODE_PK |   588 | 29988 |#|    37 |
|*203 |### FILTER####     |####    |#|#|#|#|
| 204 |###   NESTED LOOPS OUTER##      |####    |     1 |    64 |#| 1952 |
| 205 |###    VIEW####     |####    |     1 |    38 |#| 1951 |
| 206 |###     SORT UNIQUE###    |####    |     1 |    50 |#| 1951 |
| 207 |###      NESTED LOOPS### |####    |     1 |    50 |#| 1927 |
| 208 |####NESTED LOOPS### |####    |     1 |    34 |#| 1926 |
| 209 |#### VIEW#### | VW_HSD_PARTIAL_EXPANSION_ONLY |     1 |    14 |#| 1925 |
| 210 |#### INTERSECTION##      |####    |#|#|#|#|
| 211 |####   SORT UNIQUE##      |####    |     1 |    97 |#|#|
|*212 |####    FILTER###   |####    |#|#|#|#|
| 213 |####     SORT GROUP BY## |####    |     1 |    97 |#| 1822 |
|*214 |####      HASH JOIN##     |####    |     7 |   679 |#| 1773 |
|*215 | D####     TABLE ACCESS BY INDEX ROWI | CONTRACT_X_COUNTY##| 2357 | 98994 |#|   885 |
|*216 |##### INDEX RANGE SCAN#   | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
| 217 |#####NESTED LOOPS OUTER# |####    | 2338 |   125K|#|   886 |
|*218 | ID####     TABLE ACCESS BY INDEX ROW | CONTRACT_X_COUNTY##| 2338 | 86506 |#|   885 |
|*219 |##### INDEX RANGE SCAN# | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
|*220 |##### INDEX UNIQUE SCAN# | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
| 221 |####   SORT UNIQUE##      |####    |     1 |    97 |#|#|
|*222 |####    FILTER###   |####    |#|#|#|#|
| 223 |####     SORT GROUP BY## |####    |     1 |    97 |#|   103 |
| 224 |####      NESTED LOOPS## |####    |     1 |    97 |#|    54 |
| 225 |#####NESTED LOOPS OUTER# |####    |    20 | 1100 |#|    34 |
|*226 |##### INDEX RANGE SCAN#   | IX1_CONTRACT_X_COUNTY#   |    20 |   740 |#|    33 |
|*227 |##### INDEX UNIQUE SCAN# | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
|*228 |#####INDEX RANGE SCAN#    | CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
| 229 |#### TABLE ACCESS BY INDEX ROWID      | HSD_SUMMARY_OUTPUT#      |     1 |    20 |#|     1 |
|*230 |#### INDEX RANGE SCAN## | HSD_SUMMARY_OUTPUT_INDX4#|     1 |#|#|     1 |
|*231 |####INDEX RANGE SCAN##    | PK_HSD_NCB_OUTPUT1#      |     6 |    96 |#|     1 |
|*232 |###    TABLE ACCESS BY INDEX ROWID#   | CONTRACT_X_PARTIAL_ZIPCODE     |     1 |    26 |#|     1 |
|*233 |###     INDEX RANGE SCAN##      | IX5_CONTRACT_X_PARTIAL_ZIPCODE |     1 |#|#|     1 |
|*234 |##      INDEX RANGE SCAN###     | IX1_HSD_SUMMARY_OUTPUT# |     1 |    15 |#|     1 |
| 235 |##     VIEW#####    |####    |     5 |    85 |#| 2152 |
| 236 |##      SORT UNIQUE####   |####    |     5 |   262 |#| 2152 |
| 237 |###UNION-ALL####    |####    |#|#|#|#|
| 238 |### VIEW##### |####    |     4 |    68 |#|   203 |
| 239 |### SORT UNIQUE####|####    |     4 |   398 |#|   203 |
| 240 |###   UNION-ALL#### |####    |#|#|#|#|
|*241 |###    FILTER####   |####    |#|#|#|#|
| 242 |###     SORT GROUP BY### |####    |     1 |   107 |#|    62 |
| 243 |###      NESTED LOOPS### |####    |     1 |   107 |#|    13 |
| 244 |####NESTED LOOPS### |####    |     1 |    65 |#|    12 |
|*245 |#### INDEX FULL SCAN##    | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   230 |#|     2 |
|*246 |#### INDEX RANGE SCAN##   | CONTRACT_X_COUNTY_APP_ID_IDX   |     1 |    42 |#|     1 |
|*247 |####INDEX RANGE SCAN##    | CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
|*248 |###    FILTER####   |####    |#|#|#|#|
| 249 |###     SORT GROUP BY### |####    |     1 |   104 |#|    62 |
| 250 |###      NESTED LOOPS### |####    |     1 |   104 |#|    13 |
| 251 |####NESTED LOOPS### |####    |     1 |    62 |#|    12 |
|*252 |#### INDEX FULL SCAN##    | HSD_SUMMARY_OUTPUT_INDX3#|    10 |   230 |#|     2 |
|*253 |#### TABLE ACCESS BY INDEX ROWID      | CONTRACT_X_PARTIAL_ZIPCODE     |     1 |    39 |#|     1 |
|*254 |#### INDEX RANGE SCAN## | CONTRACT_X_PAR_ZIP_APP_ID_IDX |     1 |#|#|     1 |
|*255 |####INDEX RANGE SCAN##    | CONTRACT_X_PARTIAL_ZIPCODE_PK |     1 |    42 |#|     1 |
|*256 |###    FILTER####   |####    |#|#|#|#|
|*257 |###     FILTER#### |####    |#|#|#|#|
| 258 |###      NESTED LOOPS### |####    |     1 |    92 |#|     8 |
| 259 |####NESTED LOOPS### |####    |     1 |    70 |#|     6 |
| 260 |#### NESTED LOOPS###|####    |     1 |    61 |#|     5 |
| 261 |#### NESTED LOOPS##      |####    |     1 |    50 |#|     4 |
|*262 |####   TABLE ACCESS BY INDEX ROWID    | CONTRACT_INFORMATION#    |     1 |    25 |#|     3 |
|*263 |####    INDEX RANGE SCAN##| IX2_CONTRACT_INFORMATION#|     1 |#|#|     2 |
| 264 |####     SORT AGGREGATE## |####    |     1 |    22 |#|#|
| 265 |####      FIRST ROW##     |####    |     1 |    22 |#|     1 |
|*266 |#####INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# |     1 |    22 |#|     1 |
|*267 |####   TABLE ACCESS BY INDEX ROWID    | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*268 |####    INDEX RANGE SCAN##| CONTRACT_X_REGION_PK#    |     1 |#|#|     1 |
|*269 |#### INDEX RANGE SCAN## | HSD_SUMMARY_OUTPUT_INDX4#|     1 |    11 |#|     1 |
| 270 |#### TABLE ACCESS BY INDEX ROWID      | STATES###    |     1 |     9 |#|     1 |
|*271 |#### INDEX RANGE SCAN## | STATES_INDX2##     |     2 |#|#|     1 |
|*272 |####TABLE ACCESS BY INDEX ROWID#| COUNTIES### |     2 |    44 |#|     2 |
|*273 |#### INDEX RANGE SCAN##   | COUNTIES_INDX_4## |    54 |#|#|     1 |
| 274 |###     SORT AGGREGATE### |####    |     1 |    25 |#|#|
|*275 |###      TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*276 |####INDEX RANGE SCAN##    | IX1_CONTRACT_X_REGION#   |     1 |#|#|     1 |
|*277 |###    FILTER####   |####    |#|#|#|#|
|*278 |###     FILTER#### |####    |#|#|#|#|
| 279 |###      NESTED LOOPS### |####    |     1 |    95 |#|    18 |
| 280 |####NESTED LOOPS### |####    |     1 |    73 |#|    16 |
| 281 |#### NESTED LOOPS###|####    |     1 |    64 |#|    15 |
| 282 |#### NESTED LOOPS##      |####    |     4 |   144 |#|    11 |
|*283 |####   INDEX RANGE SCAN## | IX1_HSD_SUMMARY_OUTPUT# |    10 |   110 |#|     1 |
|*284 |####   TABLE ACCESS BY INDEX ROWID    | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*285 |####    INDEX RANGE SCAN##| CONTRACT_X_REGION_PK#    |     1 |#|#|     1 |
|*286 |#### TABLE ACCESS BY INDEX ROWID     | CONTRACT_INFORMATION#    |     1 |    28 |#|     1 |
|*287 |####   INDEX RANGE SCAN## | CONTRACT_INFORMATION_PK# |     1 |#|#|     1 |
| 288 |####    SORT AGGREGATE## |####    |     1 |    22 |#|#|
| 289 |####     FIRST ROW##      |####    |     1 |    22 |#|     1 |
|*290 |####      INDEX RANGE SCAN (MIN/MAX) | CONTRACT_INFORMATION_PK# |     1 |    22 |#|     1 |
| 291 |#### TABLE ACCESS BY INDEX ROWID      | STATES###    |     1 |     9 |#|     1 |
|*292 |#### INDEX RANGE SCAN## | STATES_INDX1##     |     1 |#|#|     1 |
|*293 |####TABLE ACCESS BY INDEX ROWID#| COUNTIES### |     2 |    44 |#|     2 |
|*294 |#### INDEX RANGE SCAN##   | COUNTIES_INDX_4## |    54 |#|#|     1 |
| 295 |###     SORT AGGREGATE### |####    |     1 |    25 |#|#|
|*296 |###      TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_REGION##|     1 |    25 |#|     1 |
|*297 |####INDEX RANGE SCAN##    | IX1_CONTRACT_X_REGION#   |     1 |#|#|     1 |
| 298 |### INTERSECTION####|####    |#|#|#|#|
| 299 |### SORT UNIQUE####|####    |     1 |    97 |#|#|
|*300 |###   FILTER####    |####    |#|#|#|#|
| 301 |###    SORT GROUP BY###   |####    |     1 |    97 |#| 1822 |
|*302 |###     HASH JOIN###      |####    |     7 |   679 |#| 1773 |
|*303 |###      TABLE ACCESS BY INDEX ROWID# | CONTRACT_X_COUNTY##| 2357 | 98994 |#|   885 |
|*304 |####INDEX RANGE SCAN##    | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
| 305 |###      NESTED LOOPS OUTER##   |####    | 2338 |   125K|#|   886 |
|*306 |####TABLE ACCESS BY INDEX ROWID#| CONTRACT_X_COUNTY##| 2338 | 86506 |#|   885 |
|*307 |#### INDEX RANGE SCAN##   | CONTRACT_X_COUNTY_INDX_6#|   148K|#|#|   157 |
|*308 |####INDEX UNIQUE SCAN##   | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
| 309 |### SORT UNIQUE####|####    |     1 |    97 |#|#|
|*310 |###   FILTER####    |####    |#|#|#|#|
| 311 |###    SORT GROUP BY###   |####    |     1 |    97 |#|   103 |
| 312 |###     NESTED LOOPS###   |####    |     1 |    97 |#|    54 |
| 313 |###      NESTED LOOPS OUTER##   |####    |    20 | 1100 |#|    34 |
|*314 |####INDEX RANGE SCAN##    | IX1_CONTRACT_X_COUNTY#   |    20 |   740 |#|    33 |
|*315 |####INDEX UNIQUE SCAN##   | CONTRACT_AREA_SUPP_INFO_PK     |     1 |    18 |#|     1 |
|*316 |###      INDEX RANGE SCAN##     | CONTRACT_X_COUNTY_PK#    |     1 |    42 |#|     1 |
|*317 |##    INDEX RANGE SCAN####| PK_HSD_NCB_OUTPUT1#      |     1 |#|#|     1 |
| 318 |#VIEW####### |####    | 1155 | 56595 |#| 3738 |
|*319 |# HASH JOIN######   |####    | 1155 | 56595 |    10M| 3738 |
|*320 |# TABLE ACCESS FULL##### | HSD_NCB_OUTPUT##   |   304K| 7443K|#| 1071 |
|*321 |# TABLE ACCESS FULL##### | HSD_CALC_OUTPUT## |   340K| 7986K|#| 2308 |
| 322 |      VIEW PUSHED PREDICATE#####|####    |     1 |    49 |#|     2 |
| 323 |#NESTED LOOPS###### |####    |     1 |    49 |#|     3 |
| 324 |# TABLE ACCESS BY INDEX ROWID###      | HSD_NCB_OUTPUT##   |     1 |    25 |#|     2 |
|*325 |# INDEX UNIQUE SCAN##### | PK_HSD_NCB_OUTPUT1#      |     1 |#|#|     1 |
| 326 |# TABLE ACCESS BY INDEX ROWID###      | HSD_CALC_OUTPUT## |     1 |    24 |#|     1 |
|*327 |# INDEX UNIQUE SCAN##### | PK_HSD_ACC_CALC_OUTPUT1# |     1 |#|#|     1 |
---------------------------------------------------------------------------------------------------------------------------------------

Similar Messages

Can i partition my HD now for fcpx since i didn't do it when i downloaded it. my performance with fcpx is terrible terrible performance

When i downloaded FCPX i was told I really didn't need to partition my hard drive. But my performance with fcpx is terrible from rendering constantly to waiting for a minute after you click for it to do it. I turn off the rendring, I transcoded the media to pro res went to file and hit transcode. but still i mean it crashes, buggy, suggy and it takes hours to do anything. I have my media on a external drive but i did screw up and put some media on internal drive. iMac OSX 10.7.2 3.06 GHZ Core 2 Duo. EX HD LaCie on a 800 firewire.

Partitioning the internal drive is - imho! - completely useless for UNIX-systems such as MacOS, due to excessive usage of (hidden!) temp-files.
And, especially a too small int. HDD partition for the system will brake any app 'til a full halt.
plus, 10.7. has some issues with managing Timemachine backups when it comes to large files as video - again, if the intHDD/OS drive is too small, it gets iffy.
at last >30GBs free, only codecs and material as intended by Cupertino = no probs here (on a much smaller/older set-up).

Insert performance issue with Partitioned Table.....

Hi All,
I have a performance issue during with a table which is partitioned. without table being partitioned
it ran in less time but after partition it took more than double.
1) The table was created initially without any partition and the below insert took only 27 minuts.
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:27:35.20
2) Now I re-created the table with partition(range yearly - below) and the same insert took 59 minuts.
Is there anyway i can achive the better performance during insert on this partitioned table?
[ similerly, I have another table with 50 Million records and the insert took 10 hrs without partition.
with partitioning the table, it took 18 hours... ]
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 4195045590
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 643K| 34M| | 12917 (3)| 00:02:36 |
|* 1 | HASH JOIN | | 643K| 34M| 2112K| 12917 (3)| 00:02:36 |
| 2 | VIEW | index$_join$_001 | 69534 | 1290K| | 529 (3)| 00:00:07 |
|* 3 | HASH JOIN | | | | | | |
| 4 | INDEX FAST FULL SCAN| PK_ACCOUNT_MASTER_BASE | 69534 | 1290K| | 181 (3)| 00:00
| 5 | INDEX FAST FULL SCAN| ACCOUNT_MASTER_BASE_IDX2 | 69534 | 1290K| | 474 (2)| 00:00
PLAN_TABLE_OUTPUT
| 6 | TABLE ACCESS FULL | TB_SISADMIN_BALANCE | 2424K| 87M| | 6413 (4)| 00:01:17 |
Predicate Information (identified by operation id):
1 - access("A"."VENDOR_ACCT_NBR"=SUBSTR("B"."ACCOUNT_NO",1,8) AND
"A"."VENDOR_CD"="B"."COMPANY_NO")
3 - access(ROWID=ROWID)
Open C1;
Loop
Fetch C1 Bulk Collect Into C_Rectype Limit 10000;
Forall I In 1..C_Rectype.Count
Insert test
     col1,col2,col3)
Values
     val1, val2,val3);
V_Rec := V_Rec + Nvl(C_Rectype.Count,0);
Commit;
Exit When C_Rectype.Count = 0;
C_Rectype.delete;
End Loop;
End;
Total Rec Inserted :- 2424233
PL/SQL procedure successfully completed.
Elapsed: 00:51:01.22
Edited by: user520824 on Jul 16, 2010 9:16 AM

I'm concerned about the view in step 2 and the index join in step 3. A composite index with both columns might eliminate the index join and result in fewer read operations.
If you know which partition the data is going into beforehand you can save a little bit of processing by specifying the partition (which may not be a scalable long-term solution) in the insert - I'm not 100% sure you can do this on inserts but I know you can on selects.
The APPEND hint won't help the way you are using it - the VALUES clause in an insert makes it be ignored. Where it is effective and should help you is if you can do the insert in one query - insert into/select from. If you are using the loop to avoid filling up undo/rollback you can use a bulk collect to batch the selects and commit accordingly - but don't commit more often than you have to because more frequent commits slow transactions down.
I don't think there is a nologging hint :)
So, try something like
insert /*+ hints */ into ...
Select
     A.Ing_Acct_Nbr, currency_Symbol,
     Balance_Date,     Company_No,
     Substr(Account_No,1,8) Account_No,
     Substr(Account_No,9,1) Typ_Cd ,
     Substr(Account_No,10,1) Chk_Cd,
     Td_Balance,     Sd_Balance,
     Sysdate,     'Sisadmin'
From Ideaal_Cons.Tb_Account_Master_Base A,
     Ideaal_Staging.Tb_Sisadmin_Balance B
Where A.Vendor_Acct_Nbr = Substr(B.Account_No,1,8)
   And A.Vendor_Cd = b.company_no
      ;Edited by: riedelme on Jul 16, 2010 7:42 AM

Report performance with Hierarchies

Hi
How to improve query performance with hierarchies. We have to do lot of navigation's in the query and the volume of data size very big.
Thanks
P G

HI,
chk this:
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/1955ba90-0201-0010-d3aa-8b2a4ef6bbb2
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/ce7fb368-0601-0010-64ba-fadc985a1f94
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/docs/library/uuid/4c0ab590-0201-0010-bd9a-8332d8b4f09c
Query Performance Is "Aggregates" the way out for me?
/people/vikash.agrawal/blog/2006/04/17/query-performance-150-is-aggregates-the-way-out-for-me
° the OLAP cache is architected to store query result sets and to give all users access to those result sets.
If a user executes a query, the result set for that querys request can be stored in the OLAP cache; if that same query (or a derivative) is then executed by another user, the subsequent query request can be filled by accessing the result set already stored in the OLAP cache.
In this way, a query request filled from the OLAP cache is significantly faster than queries that receive their result set from database access
° The indexes that are created in the fact table for each dimension allow you to easily find and select the data
see http://help.sap.com/saphelp_nw04/helpdata/en/80/1a6473e07211d2acb80000e829fbfe/content.htm
° when you load data into the InfoCube, each request has its own request ID, which is included in the fact table in the packet dimension.
This (besides giving the possibility to manage/delete single request) increases the volume of data, and reduces performance in reporting, as the system has to aggregate with the request ID every time you execute a query. Using compressing, you can eliminate these disadvantages, and bring data from different requests together into one single request (request ID 0).
This function is critical, as the compressed data can no longer be deleted from the InfoCube using its request IDs and, logically, you must be absolutely certain that the data loaded into the InfoCube is correct.
see http://help.sap.com/saphelp_nw04/helpdata/en/ca/aa6437e7a4080ee10000009b38f842/content.htm
° by using partitioning you can split up the whole dataset for an InfoCube into several, smaller, physically independent and redundancy-free units. Thanks to this separation, performance is increased when reporting, or also when deleting data from the InfoCube.
see http://help.sap.com/saphelp_nw04/helpdata/en/33/dc2038aa3bcd23e10000009b38f8cf/content.htm
Hope it helps!
tHAK YOU,
dst

DATACOPY with partitioned data source

Hello,
I am actually working on the Hyperion Essbase EPM 11.1.2
I am trying to perform a Datacopy command in a HBR.
Data source are partitioned with a transparent partition.
This datacopy do not work. The HBR is really fast but when I retrieve data no data are copied.
I am wondering if this is possible to perform a datacopy command, in a HBR with partitioned data source.
I have managed to perform this datacopy throw a HBR using the command:
SET CREATEBLOCKONEQ
Target = Source;
But this method is really long.
Thanks for your answer,
Arthur.

Hi
Make sure that you have relevant Role & Authorization at Quality/PRS.
You have to Transport the Source Cube first and then Create a Generate Export Data Source in QAS. Then, replicate data sources for BW QAS Soruce System. Make sure this replicated Data Source in QAS. Only then can transport new update rules for second cube.
Hope it helps and clear

Help with partitions and file systems [SOLVED]

Hi, i have been using Ubuntu for a while, and now i want to move to Arch. I've probed it in a PC and i like so i want to make que change.
But, before installing Arch, I have 2 doubts. I red the beginners guide and also the instalation guide. There it says that if better to have diferents partitions for /, /boot/, /home, /usr, /var, y /tmp
Usually, i alwayes used something like this:
* /boot (32megas)
* /swap (512 megas)
* /root (6 a 8 gigas)
* /home (80 gigas aprox)
It's really better to also have partitions for /var, /usr y /tmp? o some of them? and, in that case, wich size should i give them? because i don't want to make them too small, but i don't want to waste disk space neither.
Adn that takes me to my second question, wich filesystem is better for each partitionn? in many places, i read taht JFS its good for /var or that XFS if better for /home and big files
I thinked to use something like this:
* /boot (ext2)
* / (JFS)
* swap
* /home (XFS)
Is a good design? or should i use other filesystem like reiserfs, etc... and for /var, /usr and /tmp partition, wich one should i use?
Thank you
Ps: This Pc is gonna be a desktop pc
Ps2: sorry for my bad english. it is not my real lenguage
Reason of edit: added the swap partition. I forgot it
Last edited by Thalskarth (2008-12-21 20:11:00)

thanks everybody for the help,
kaola_linux wrote:@Thalskarth - it's better to have /var especially if you're using ext3 or other filesystems which was designed for larger files as your partition for /home and /. Having a seperate partition for /var would be nice (backup purposes and reinstalling without downloading the entire package whole over again). 5gb would be sufficient for your /var, anyway you can always resize it to your needs.
so, a 5gb partition in reiserfs would be OK for a /var
Inxsible wrote:
Lot of people also use XFS which is known to have better performance with huge files. I think EXT3 offers a good balance...because I am never sure whether my home partition will have all huge files or not..same with my external drive...so i just use EXT3
If you have a specific partition for movies or some video/audio editing that you do..you may wanna consider XFS too. I don't do all that...so I have never used XFS. I wouldn't know the exact performance difference between ext3 and XFS.
Yes, in many places i red that XFS is better for big files. But i couldn't fine wich is the meaning of "big file". Does it mean a 200 mg file? or a 4.4gb one??
the same applies to reiserFs, what is a small file? a 1mg one or a 4kb one?
I have alwayes used ext3, i thinked in XFS and JFS just to give them a try.
amranu wrote:I have no idea about better filesystems, all my partitions are ext3 (soon to be ext4)
Inxsible wrote:One thing that makes me wanna keep EXT3 is that EXT4 is coming out (soon?) and you can upgrade from 3 to 4 without having to reformat and having to make backups of your current data.
really is cominf soon? i didn't think in ext4 beacuse many places said that was in development for many years... meybe they were a bit out-of-date
Edit: i search in the wiki and it says that since 11 october 2008, ext4 is "stable" and is been included since kernel 2.6.28 as stable realase, is to early to prove it? or it better to wait a while??
thanks.
and, does anyone try the JFS one?
Last edited by Thalskarth (2008-12-03 00:14:56)

Degraded performance.

Has anyone noticed degraded performance when enabling 802.11n with support for G? The reason for asking is all my wireless workstations are running 802.11n with the exception of my iPhone. I also want to get a wireless all-in-one printer/scanner which I can only find support for B/G wireless networks, not 802.11n. Can anyone recommend an all-in-one printer/scanner that supports 802.11n for use with Apple's AEBS router?

Has anyone noticed degraded performance when enabling 802.11n with support for G? The reason for asking is all my wireless workstations are running 802.11n with the exception of my iPhone.
That would be "normal" as the best you can expect in a mixed radio mode is 100 - 130 Mbps for your "n" devices. If you want to take advantage of "n" speed, you would either need to set up a "Dual-Band" network or remove any non-"n" devices from your current network.

Export backup degrades performance?

Hi all,
Please suggest me if i take export backup of the database does it degrades performance of the database when the applications are connected?
Can this export be done while application is using the database?
Is there any risk concerning performance of the application during DB export?
Thank you.

An export is a query against the database. Generally, a query to extract the whole schema or whole table (or whole database). It has the same performance impact as any query doing FullTableScans against the tables being exported.
Note :If you do an export using 'exp', ensure that you use "CONSISTENT=Y" or "FLASHBACK_SCN" or "FLASBACK_TIME" to get consistency across tables, else exp does Table-level consistency.
With 'expdp' you can use FLASHBACK_SCN or FLASHBACK_TIME

Are there Issues with poor performance with Maverick OS,

Are there issues with slow and reduced performance with Mavericks OS

check this
http://apple.stackexchange.com/questions/126081/10-9-2-slows-down-processes
or
this:
https://discussions.apple.com/message/25341556#25341556
I am doing a lot of analyses with 10.9.2 on a late 2013 MBP, and these analyses generally last hours or days. I observed that Maverick is slowing them down considerably for some reasons after few hours of computations, making it impossible for me to work with this computer...

Performance with the new Mac Pros?

I sold my old Mac Pro (first generation) a few months ago in anticipation of the new line-up. In the meantime, I purchased a i7 iMac and 12GB of RAM. This machine is faster than my old Mac for most Aperture operations (except disk-intensive stuff that I only do occasionally).
I am ready to purchase a "real" Mac, but I'm hesitating because the improvements just don't seem that great. I have two questions:
1. Has anyone evaluated qualitative performance with the new ATI 5870 or 5770? Long ago, Aperture seemed pretty much GPU-constrained. I'm confused about whether that's the case anymore.
2. Has anyone evaluated any of the new Mac Pro chips for general day-to-day use? I'm interested in processing through my images as quickly as possible, so the actual latency to demosaic and render from the raw originals (Canon 1-series) is the most important metric. The second thing is having reasonable performance for multiple brushed-in effect bricks.
I'm mostly curious if anyone has any experience to point to whether it's worth it -- disregarding the other advantages like expandability and nicer (matte) displays.
Thanks.
Ben

Thanks for writing. Please don't mind if I pick apart your statements.
"For an extra $200 the 5870 is a no brainer." I agree on a pure cost basis that it's not a hard decision. But I have a very quiet environment, and I understand this card can make a lot of noise. To pay money, end up with a louder machine, and on top of that realize no significant benefit would be a minor disaster.
So, the more interesting question is: has anyone actually used the 5870 and can compare it to previous cards? A 16-bit 60 megapixel image won't require even .5GB of VRAM if fully tiled into it, for example, so I have no ability, a priori, to prove to myself that it will matter. I guess I'm really hoping for real-world data. Perhaps you speak from this experience, Matthew? (I can't tell.)
Background work and exporting are helpful, but not as critical for my primary daily use. I know the CPU is also used for demosaicing or at least some subset of the render pipeline, because I have two computers that demonstrate vastly different render-from-raw response times with the same graphics card. Indeed, it is this lag that would be the most valuable of all for me to reduce. I want to be able to flip through a large shoot and see each image at 100% as instantaneously as possible. On my 2.8 i7 that process takes about 1 second on average (when Aperture doesn't get confused and mysteriously stop rendering 100% images).
Ben

Performance with Boot Camp/Gaming?

Hi,
I just acquired a MBP/2GHz IntelCD/2GB RAM/100GB/Superdrive, with Applecare. Can anyone comment about the performance with
Boot Camp -- running Windows XP SP2, and what the gaming graphics are like?
Appreciate it, thanks...
J.
Powerbook G4 [15" Titanium - DVI] Mac OS X (10.4.8) 667MHz; 1GB RAM; 80GB

Well, I didn't forget to mention what I did not know yet.... So that's not exactly correct..
As per Apple's support page, http://support.apple.com/specs/macbookpro/MacBook_Pro.html
My new computer does have 256MB of video memory...

Performance with external display

Hello,
when I'm connecting my 19'' TFT to the MacBook the performance (with the same applications runnig) is realy bad. It tooks longer to switch between apps and if I don't use an app for some time, it can took up to 30 sec to "reactivate" the app.
Because the HD is working when I switch apps, it looks like the OS is swapping. My question: Would it help to upgrade the MacBook to 2GB ram? AFAIC the intel card uses shared memory.
Thanks for your help
Till
MacBook 1.83 GHz/1GB Mac OS X (10.4.8)

How much RAM do you have? Remember that the MB does not have dedicated VRAM like some computers do and that it uses the system RAM to drive the graphics chipset.
I use my MB with the mini-DVI to DVI adapter to drive a 20" widescreen monitor without any of the problems that you describe, but I have 2GB of RAM. If you only have the stock 512MB of RAM, that may be part of what you are seeing.

Performance with LinkedList in java

Hello All,
Please suggest me any solution to further improve the performance with List.
The problem description is as follows:
I have a huge number of objects, lets say 10,000 , and need to store the objects in such a collection so that if i want to store an object at some particular index i , I get the best performance.
I suppose as I need indexed based access, using List makes the best sense as Lists are ordered.
Using LinkedList over ArrayList gives the better performance in the aforementioned context.
Is there are way I can further improve the performance of LinkedList while solving this particular problem
OR
Is there any other index based collection using that i get better performance than LinkedList?
Thanks in advance

The trouble with a LinkedList as implemented in the Java libraries is that if you want to insert at index 100, it has no option but to step through the first 100 links of the list to find the insert point. Likewise is you retrieve by index. The strength of the linked list approach is lost if you work by index and the List interface gives no other way to insert in the middle of the list. The natural interface for a linked list would include an extended Iterator with methods for insert and replace. Of course LinkedLists are fine when you insert first or last.
My guess would be that if your habitual insertion point was half way or more through the list then ArrayList would serve you better especially if you leave ample room for growth. Moving array elements up is probably not much more expensive, per element, than walking the linked list. Maybe 150% or thereabouts.
Much depends on how you retrieve, and how volatile the list is. Certainly if you are a read-mostly situation and cannot use an iterator then a LinkedList won't suit.

Performance with dates in the where clause

Performance with dates in the where clause
CREATE TABLE TEST_DATA
FNUMBER NUMBER,
FSTRING VARCHAR2(4000 BYTE),
FDATE DATE
create index t_indx on test_data(fdata);
query 1: select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
query 2: select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
query 3: select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_date('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
My questions:
1) Why isn't the index t_indx used in Execution plan 1?
2) From the execution plan, I see that query 2 & 3 is better than query 1. I do not see any difference between execution plan 2 & 3. Which one is better?
3) I read somewhere - "Always check the Access Predicates and Filter Predicates of Explain Plan carefully to determine which columns are contributing to a Range Scan and which columns are merely filtering the returned rows. Be sceptical if the same clause is shown in both."
Is that true for Execution plan 2 & 3?
3) Could some one explain what the filter & access predicate mean here?
Thanks in advance.
Execution Plan 1:
SQL> select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
COUNT(*)
283
Execution Plan
Plan hash value: 1486387033
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 | 517 (20)| 00:00:07 |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
|* 2 | TABLE ACCESS FULL| TEST_DATA | 341 | 3069 | 517 (20)| 00:00:07 |
Predicate Information (identified by operation id):
2 - filter(TRUNC(INTERNAL_FUNCTION("FDATE"))=TRUNC(SYSDATE@!))
Note
- dynamic sampling used for this statement
Statistics
4 recursive calls
0 db block gets
1610 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
Execution Plan 2:
SQL> select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
COUNT(*)
283
Execution Plan
Plan hash value: 1687886199
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
|* 2 | FILTER | | | | | |
|* 3 | INDEX RANGE SCAN| T_INDX | 283 | 2547 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(TRUNC(SYSDATE@!)<=TRUNC(SYSDATE@!)+.9999884259259259259259
259259259259259259)
3 - access("FDATE">=TRUNC(SYSDATE@!) AND
"FDATE"<=TRUNC(SYSDATE@!)+.999988425925925925925925925925925925925
9)
Note
- dynamic sampling used for this statement
Statistics
7 recursive calls
0 db block gets
76 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows
Execution Plan 3:
SQL> select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_dat
e('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
COUNT(*)
283
Execution Plan
Plan hash value: 1687886199
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 9 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 9 | | |
|* 2 | FILTER | | | | | |
|* 3 | INDEX RANGE SCAN| T_INDX | 283 | 2547 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(TO_DATE('21-APR-10','dd-MON-yy')<=TO_DATE('21-APR-10
23:59:59','DD-MON-YY hh24:mi:ss'))
3 - access("FDATE">=TO_DATE('21-APR-10','dd-MON-yy') AND
"FDATE"<=TO_DATE('21-APR-10 23:59:59','DD-MON-YY hh24:mi:ss'))
Note
- dynamic sampling used for this statement
Statistics
7 recursive calls
0 db block gets
76 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
380 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed

Hi,
user10541890 wrote:
Performance with dates in the where clause
CREATE TABLE TEST_DATA
FNUMBER NUMBER,
FSTRING VARCHAR2(4000 BYTE),
FDATE DATE
create index t_indx on test_data(fdata);Did you mean fdat<b>e</b> (ending in e)?
Be careful; post the code you're actually running.
query 1: select count(*) from TEST_DATA where trunc(fdate) = trunc(sysdate);
query 2: select count(*) from TEST_DATA where fdate between trunc(sysdate) and trunc(SYSDATE) + .99999;
query 3: select count(*) from TEST_DATA where fdate between to_date('21-APR-10', 'dd-MON-yy') and to_date('21-APR-10 23:59:59', 'DD-MON-YY hh24:mi:ss');
My questions:
1) Why isn't the index t_indx used in Execution plan 1?To use an index, the indexed column must stand alone as one of the operands. If you had a function-based index on TRUNC (fdate), then it might be used in Query 1, because the left operand of = is TRUNC (fdate).
2) From the execution plan, I see that query 2 & 3 is better than query 1. I do not see any difference between execution plan 2 & 3. Which one is better?That depends on what you mean by "better".
If "better" means faster, you've already shown that one is about as good as the other.
Queries 2 and 3 are doing different things. Assuming the table stays the same, Query 2 may give different results every day, but the results of Query 3 will never change.
For clarity, I prefer:
WHERE fdate >= TRUNC (SYSDATE)
AND fdate < TRUNC (SYSDATE) + 1(or replace SYSDATE with a TO_DATE expression, depending on the requirements).
3) I read somewhere - "Always check the Access Predicates and Filter Predicates of Explain Plan carefully to determine which columns are contributing to a Range Scan and which columns are merely filtering the returned rows. Be sceptical if the same clause is shown in both."
Is that true for Execution plan 2 & 3?
3) Could some one explain what the filter & access predicate mean here?Sorry, I can't.

Slow Performance with Business Rules

Hello,
Has anyone ever had slow performance with business rules? For example, I attached a calc script to a form and it ran for 20 seconds. I made an exact replica of the calc script in a business rules and it took 30 seconds to run. Also, when creating / modifying business rules in EAS it takes a long time to open or save or attach security - any ideas on things to improve this performance?
Thanks!

If you are having issues with performance of assigning access then I am sure there was patch available, it was either a HSS patch or planning patch.
Cheers
John
http://john-goodwin.blogspot.com/

Degraded Performance with Partitioning

Similar Messages

Maybe you are looking for