После обновления возникли вопросы. : Супермаг Плюс (Супермаг 2000)

ничего не понимаю....
Решил сильно не рисковать, и попросил помощи в виде сисадмина у обслуживающей компании.
Поменяли SM2000 1.023.3 на 1.024.5 sp5, oracle 8.1.6.3 на 9.2.7.0. Думал, что настанет шоколадная жизнь, но не тут то было... Сначала меняли оракл с 8 на 9 через дамп, ошибок не было, потом поднимали версию супермага. После обновления возникли серьезные вопросы, на которых мне вразумительного ответа так и не дали.
1. Если заходить из computer management, то вылетает mmc консоль каждые 2-3 минуты с ошибкой. Мне объяснили, что это известный глюк (фича?), решается через выбор кассового сервера и "новое окно отсюда". Помогло, но считаю это полумерой. Как-нибудь по-другому можно сделать, чтобы не вылетало?
2. Завожу юзера, даю ему все права на расчет аналитики. Запускаю расчет себестоимости под этим юзером, считает все, делает в temp куча файликов, потом в логе пишет, что нет прав на таблицу ff*. Под юзером supermag все считает. Что и куда надо нажать, чтобы считало под другиим юзерами?
3. До обновления версии себестоимость считалась порядка 20 минут. Обновил версию, прошелся оптимайзером 29r4, подкрутил ключики, которые он мне сказал, себестоимость считается 40 минут. Терпимо в принципе, но непонятно, почему считается то медленнее...
4. Зачем нужно undotbs1? Сначало было 350 метров, были жуткие тормоза. Сделал 2040 метров, из них занято 550 метров, тормозов стало меньше. Сколько надо ставить? и на что это влияет по скорости?
5. Делаю себе redo.log. Создал 5 штук по 102400 кб, делаю шестой, пишет "ora-01185, неверный номер 6 группы протокольных файлов". В spfile стоит max_rolback_segments 99. Чего еще крутить?
6. В приходной накладной юзеры вводят товар, пытаются выбрать сумму документа. При нажатии кнопки "сумма (там где стрелка вниз)", там где выбор суммы документа, появляется выбор "сумма документа, без НДС, НДС 10%, без налогов, сумма в валюте". Про НДС 18% как бы забыли. Что где подкрутить, чтобы этот НДС появился в этом списке? (естественно, что раньше все было).
7. Нажимаем в приходной накладной функции - заполнить документ ценами последнего прихода. Туууупняк. Все симптомы что полетели индексы. Но! Перед этим было только импорт через дамп, optimizer2 /optimize и расчет себестоимости. Все этапы без ошибок,в алерт логе пусто. Когда могли умереть индексы??? Что делать в таких случаях, если работать надо срочно, optimizer /chkindx не помогает, а optimizer /optimize работает больше часа? как ловить тот индекс, который потом надо alter index rebuild?
8. Раза в три стало медленее проведение документов. Все работает, но... ну правда гораздо медленнее. Где копать - тоже не совсем понятно. Ну нету у меня запроса, на котором все колом встает. Что делать?
9. Как все-таки правильно настраивать сервер, если стоит 2 dual xeon. hyper threading включать или нет? если один пользователь - вообще не заметно, если много - такое впечатление, что oracle 9 с включенным гипертрейдингом чуть медленее работает, чем с выключенным. С 8 было наоборот. Может где я галку не там поставил? Или это надо в оракловую ветку?

Единственное, что радует, слияние строк, на которое я жаловался раньше, стало работать как раньше, минута-полторы. Но вот остальное.....

помогите, кто чем может... можно rtfm, только какой...
offtopic. посоветуйте книжку по 9 ораклу умную какую-нибудь.

1. Работает, просто выбирай в окне слева, а не кликом на окне справа. А вообще, зачем на него пялиться?
2. Считать под supermag ПРАВИЛЬНО, под другими юзерами нет. Если очень хочется - отобрать права Админа аналитики и дать их снова.
3. Вопрос на тему оптимизации. См. более ранние сообщения форума о том, как это правильно описывать и лечить.
4. Прочти об изменениях в 9i по сравнению с 8i.
5. Параметр базы maxlogfiles=6
6. Историю налоговых ставок
7. Ребилдить не надо посмотри, какой запрос тормозит и см. п.3
8. Надо его найти, запрос.
9. Я против HT

Основной tfm, который тебе можно порекомендовать - оракловая дока и этот форум. Не читал ты явно ни того, ни другого. Очень настоятельная рекомендация не сливать кучу вопросов в одну тему. Как отвечать - не понятно. Возьми вопросы последовательно, расписывай в разные темы, будем разбираться.
Книжка умная - Тома Кайта, но тебе пойдет и глупая, возьми для начала любую.

2. юзер обязательно должен называться английскими буквами.

1. -
2. Давайте вопще всех под одним юзером пускать?
3. скорее всего статиска или еще че нить в этом роде
4. если не нравиться то в init UNDO_MANAGEMENT=MANUAL и все как в 8
5.
6.
7. см 3
8. см 3
9. Можешь включить хуже не будет, главно помнить что ораклу на это пох.

откуда ограничение?

из опыта. под русским юзером товародвижение не считается.

И в пароле никаких запятых, точек и прочей лабуды. Не забываем, что лоадер пускается из консоли.

Практические наблюдения показывают, что совсем НТ ему не пох, вплоть до двукратного торможения по необъяснимым причинам и падений.

ну тады упс

Разбил на подвопросы только потому, что не надеялся на некоторые из них получить ответ. На будущее буду создавать отдельные темы.
1. По вопросу кассового сервера мне несколько непонятно, а я что, один такой "счастливый", у которого кассовый сервер время от времени пишет "сервер RPC недоступен" в модальном окошке и ничего не делает, пока в левом окне этот сервер не выбрать опять? Поэтому я достаточно часто, особенно когда делаю полную выгрузку вручную, смотрю на этот кассовый сервер. Поэтому меня и напрягало то, что вылетает. Ну раз способа решения до сих пор нет - ну тогда ладно...
2. Спасибо за ответ, все предельно ясно и понятно.
3. Вот тут совершенно не понятно. Все вопросы про оптимизацию, которые я нашел, были в оракловой ветке. Там круто решили, что чтобы отчеты не тормозили, надо убить статистику на временных таблицах, но не написали как сделать, чтобы она не считалась опять. А про проставление цен и про остальные тормоза (ну мои симптомы) я так ничего и не нашел.
Ну нашел я запрос, который тормозит. А дальше что? или это идти в оракловую ветку и там отдельную тему поднимать?
На всякий случай вот инфа по этому запросу. Что из этого надо было постить в форум - я так и не понял.

Target:
DBDOM

Version: Oracle 9.2.0.7.0

Database: DBDOM

Schema: SUPERMAG

Date: 16.01.2007 6:00:00


SQL Statement:

SELECT sp.specitem, sc.doctype, sc.docid, sc.specitem specitem_src,
sc.itemprice, sc.itempricenotax
FROM smspec sp, smspec sc, smdocuments d
WHERE sp.doctype = :b1
AND sp.docid = :b2
AND (:b3 = '0'
OR nvl(sp.itemprice, 0) = 0)
AND sc.doctype = d.doctype
AND sc.docid = d.id
AND d.createdat <= :b4
AND d.doctype = 'WI'
AND d.docstate = 3
AND d.opcode = 0
AND sc.article = sp.article
AND d.locationto IN (SELECT id
FROM ttshoplist)
AND (:b1 != 'WI'
OR d.id != :b2)
AND d.id IN (SELECT max(d2.id)
FROM smspec s2, smdocuments d2
WHERE s2.doctype = d2.doctype
AND s2.docid = d2.id
AND d2.doctype = 'WI'
AND d2.docstate = 3
AND d2.opcode = 0
AND s2.article = sp.article
AND d2.locationto IN (SELECT id
FROM ttshoplist)
AND (:b1 != 'WI'
OR d2.id != :b2)
AND d2.createdat IN (SELECT max(d1.createdat)
FROM smspec s1, smdocuments d1
WHERE s1.doctype = d1.doctype
AND s1.docid = d1.id
AND d1.createdat <= :b4
AND d1.doctype = 'WI'
AND d1.docstate = 3
AND d1.opcode = 0
AND s1.article = s2.article
AND d1.locationto IN (SELECT id
FROM ttshoplist)
AND (:b1 != 'WI'
OR d1.id != :b2)))
AND sc.specitem IN (SELECT max(s3.specitem)
FROM smspec s3
WHERE s3.doctype = d.doctype
AND s3.docid = d.id
AND s3.article = sp.article)


Optimizer Mode Used:

COST ALL ROWS (optimizer: CHOOSE)

Total Cost:

376

Execution Steps:

Step # Step Name
35 SELECT STATEMENT
34 NESTED LOOPS
31 HASH JOIN
26 NESTED LOOPS
24 NESTED LOOPS
21 HASH JOIN
2 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
1 SUPERMAG.SMCSPEC_DISPLAYPOS INDEX [RANGE SCAN]
20 . VIEW
19 SORT [GROUP BY]
18 . VIEW
17 FILTER
16 SORT [GROUP BY]
15 NESTED LOOPS
13 NESTED LOOPS
11 NESTED LOOPS
8 NESTED LOOPS
6 NESTED LOOPS
3 SUPERMAG.SMDOCUMENTS TABLE ACCESS [FULL]
5 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
4 SUPERMAG.SMCSPEC_PK INDEX [RANGE SCAN]
7 SUPERMAG.SMSPEC_ART INDEX [RANGE SCAN]
10 SUPERMAG.SMDOCUMENTS TABLE ACCESS [BY INDEX ROWID]
9 SUPERMAG.SMCDOCUMENTS_PK INDEX [UNIQUE SCAN]
12 SUPERMAG.TTCSHOPLIST_PK INDEX [UNIQUE SCAN]
14 SUPERMAG.TTCSHOPLIST_PK INDEX [UNIQUE SCAN]
23 SUPERMAG.SMDOCUMENTS TABLE ACCESS [BY INDEX ROWID]
22 SUPERMAG.SMCDOCUMENTS_PK INDEX [UNIQUE SCAN]
25 SUPERMAG.TTCSHOPLIST_PK INDEX [UNIQUE SCAN]
30 . VIEW
29 FILTER
28 SORT [GROUP BY]
27 SUPERMAG.SMSPEC TABLE ACCESS [FULL]
33 SUPERMAG.SMSPEC TABLE ACCESS [BY INDEX ROWID]
32 SUPERMAG.SMCSPEC_PK INDEX [UNIQUE SCAN]

Step # Description Est. Cost Est. Rows Returned Est. KBytes Returned
1 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMCSPEC_DISPLAYPOS. 3 4 --
2 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 2 1 0,024
3 This plan step retrieves all rows from table SMDOCUMENTS. 44 11 0,279
4 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMCSPEC_PK. 1 1 --
5 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 1 3 0,056
6 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 51 37 1,626
7 This plan step retrieves one or more ROWIDs in ascending order by scanning the B*-tree index SMSPEC_ART. 1 7 0,178
8 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 53 253 17,542
9 This plan step retrieves a single ROWID from the B*-tree index SMCDOCUMENTS_PK. -- 1 --
10 This plan step retrieves rows from table SMDOCUMENTS through ROWID(s) returned by an index. 1 1 0,032
11 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 63 1 0,102
12 This plan step retrieves a single ROWID from the B*-tree index TTCSHOPLIST_PK. -- 1 167 14,815
13 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 64 60 6,855
14 This plan step retrieves a single ROWID from the B*-tree index TTCSHOPLIST_PK. -- 1 167 22,793
15 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 65 69 921 9 354,665
16 This plan step accepts a set of rows from its child node, and sorts them into groups based on the columns specified in the query's GROUP BY clause. 126 127 16,991
17 This plan step accepts a set of rows from its child node, eliminates some of them, and returns the rest.
18 This plan step represents the execution plan for the subquery defined by the view . 126 127 4,589
19 This plan step accepts a set of rows from its child node, and sorts them into groups based on the columns specified in the query's GROUP BY clause. 126 127 4,589
20 This plan step represents the execution plan for the subquery defined by the view . 126 127 6,697
21 This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. 127 1 0,077
22 This plan step retrieves a single ROWID from the B*-tree index SMCDOCUMENTS_PK. -- 1 --
23 This plan step retrieves rows from table SMDOCUMENTS through ROWID(s) returned by an index. 1 1 0,025
24 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 128 1 0,103
25 This plan step retrieves a single ROWID from the B*-tree index TTCSHOPLIST_PK. -- 1 167 14,815
26 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 129 1 0,115
27 This plan step retrieves all rows from table SMSPEC. 204 183 128 3 934,391
28 This plan step accepts a set of rows from its child node, and sorts them into groups based on the columns specified in the query's GROUP BY clause. 246 9 157 196,732
29 This plan step accepts a set of rows from its child node, eliminates some of them, and returns the rest.
30 This plan step represents the execution plan for the subquery defined by the view . 246 9 157 634,909
31 This plan step accepts two sets of rows, each from a different table. A hash table is built using the rows returned by the first child. Each row returned by the second child is then used to probe the hash table to find row pairs which satisfy a condition specified in the query's WHERE clause. Note: The Oracle cost-based optimizer will build the hash table using what it thinks is the smaller of the two tables. It uses the statistics to determine which is smaller, so out of date statistics could cause the optimizer to make the wrong choice. 375 1 0,185
32 This plan step retrieves a single ROWID from the B*-tree index SMCSPEC_PK. -- 1 --
33 This plan step retrieves rows from table SMSPEC through ROWID(s) returned by an index. 1 1 0,027
34 This plan step joins two sets of rows by iterating over the driving, or outer, row set (the first child of the join) and, for each row, carrying out the steps of the inner row set (the second child). Corresponding pairs of rows are tested against the join condition specified in the query's WHERE clause. 376 1 0,212
35 This plan step designates this statement as a SELECT statement. 376 -- --


4. Все понял, спасибо.
5. А у меня нет такого параметра. . У меня есть только max_dispatchers, max_dump_file_size, max_enabled_roles, max_rollback_segments, max_servers. И вообще, у меня нет ни одного параметра, который был бы равен 6. Смотрю в All_initialization parameters, spfile.
6. Точно, оно! Спасибо, сам бы точно не догадался.
7, 8, 9. Вопрос закрыт, спасибо.