| Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
| Все форумы / Oracle | ![]() |
||
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
такой вопрос: есть боевая бд, есть разработческая. По данным естественно отличаются, равно как и по железу. Что-бы планы на разработческой совпадали с таковыми на боевой хочется перенести статистику. Т.е. обмануть оптимизатор. Какие могут быть недостатки у этого подхода? (ТКайт неодобрительно отзывался о данном методе, но вразумительных причин в его книге я не уловил) |
| 22 дек 10, 09:04 [9978828] Ответить | Цитировать Сообщить модератору | |
|
_Nikotin Member Откуда: СПб Сообщений: 2794 |
И что будет с LOW_VALUE / HIGH_VALUE, гистограммы если данные разные в таблицах? |
| 22 дек 10, 09:13 [9978864] Ответить | Цитировать Сообщить модератору | |
|
Alexander Anokhin
Guest |
О какой статистике речь? Объектной или системной? Вообще для совпадения планов лучше, чтобы это была полная/идентичная копия. Иногда оптимизатор определяет кардинальность в зависимости от количества блоков в сегменте. В этом случае для одинакового плана объекты должны быть одинаковых размеров. Ну и также не забываем про все остальные параметры, влияющие на оптимизатор. |
| 22 дек 10, 09:14 [9978869] Ответить | Цитировать Сообщить модератору | |
|
Alexander Anokhin
Guest |
Хотя, numblks тоже перенесется, этот вопрос решается. |
||
| 22 дек 10, 09:24 [9978893] Ответить | Цитировать Сообщить модератору | |||
|
_Nikotin Member Откуда: СПб Сообщений: 2794 |
почитайте что-нибудь типа Traditional Development/Integration/Staging/Production Practice for Software Development, то что Вам нужно не нужно делать в development среде. |
| 22 дек 10, 09:25 [9978900] Ответить | Цитировать Сообщить модератору | |
|
djeday84 Member Откуда: Сообщений: 324 |
skelet, может проще будет планы через baseline с девелоперской на боевую перетащить ? |
| 22 дек 10, 09:36 [9978961] Ответить | Цитировать Сообщить модератору | |
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
поясните пожалуйста, что вы имеете ввиду "через baseline" ? но вообще мне хочется что-бы планы в разработческой/тестовой стали как в боевой, а не наоборот |
||
| 22 дек 10, 10:18 [9979284] Ответить | Цитировать Сообщить модератору | |||
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
в смысле что будет? неправильные они будут. Впрочем я надеюсь, что как минимум справочники совпадают |
||
| 22 дек 10, 10:19 [9979297] Ответить | Цитировать Сообщить модератору | |||
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
как я понимаю механизм - объектной, той что в user_histograms не сомневаюсь, что полная копия лучше, только вот что ж её даст. (хотя над этим тоже работы ведутся, но не уверен я в успехе, в лучшем случае будут получены покоценные данные) |
||
| 22 дек 10, 10:21 [9979314] Ответить | Цитировать Сообщить модератору | |||
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
статья забавная, спасибо! Только не смог понять причём тут статистика и планы выполнения |
||
| 22 дек 10, 10:21 [9979320] Ответить | Цитировать Сообщить модератору | |||
|
djeday84 Member Откуда: Сообщений: 324 |
skelet, имел ввиду это Plan Management в какую сторону переносить не имеет значения. по поводу работы в 10g не в курсе, сам игрался только на 11той. |
| 22 дек 10, 10:44 [9979535] Ответить | Цитировать Сообщить модератору | |
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
хорошо, в чём преимущества данного способа в сравнении с переносом статистики? |
||
| 22 дек 10, 10:50 [9979596] Ответить | Цитировать Сообщить модератору | |||
|
djeday84 Member Откуда: Сообщений: 324 |
skelet, планы гарантированно будут как на боевой. imho не вижу каким еще способом можно добиться
|
||
| 22 дек 10, 10:56 [9979668] Ответить | Цитировать Сообщить модератору | |||
|
брадобрей Member Откуда: Сообщений: 4703 |
Минус в том, что это не сделает планы новых запросов идентичными боевым. А на разработке это важнее, чем идентичные существующие планы. |
| 22 дек 10, 10:58 [9979682] Ответить | Цитировать Сообщить модератору | |
|
брадобрей Member Откуда: Сообщений: 4703 |
Метода какбэ всего два: перенос статистики - тут встает вопрос про гистограммы. HIGH/LOW без гистограмм перенести проблем нет. и полностью идентичная база, хоть и на другом железе. |
| 22 дек 10, 11:00 [9979706] Ответить | Цитировать Сообщить модератору | |
|
skelet Member [заблокирован] Откуда: moskau Сообщений: 5555 |
в смысле что со временем планы на боевой изменяться? согласен, процедуру реэкспорта статистики надо проводить периодически или что-то другое имелось ввиду? |
||
| 22 дек 10, 12:23 [9980458] Ответить | Цитировать Сообщить модератору | |||
|
брадобрей Member Откуда: Сообщений: 4703 |
имелось ввиду, что на разработке бывает важнее видеть, как будет выполняться на проде то, что разрабатывается, т.е. новые запросы, которых нет baselines |
| 22 дек 10, 14:48 [9981530] Ответить | Цитировать Сообщить модератору | |
|
_Nikotin Member Откуда: СПб Сообщений: 2794 |
вот для этого и существует Integration |
||
| 22 дек 10, 14:52 [9981571] Ответить | Цитировать Сообщить модератору | |||
|
_Nikotin Member Откуда: СПб Сообщений: 2794 |
то есть в этой статье Staging |
| 22 дек 10, 14:59 [9981649] Ответить | Цитировать Сообщить модератору | |
|
_Alex_SMIRNOV_ Member Откуда: Киев Сообщений: 1517 |
skelet, а если через DBMS_STATS.EXPORT_SCHEMA_STATS / IMPORT_SCHEMA_STATS |
| 22 дек 10, 15:47 [9982124] Ответить | Цитировать Сообщить модератору | |
|
Peter Bobrov Member Откуда: Naberezhnaya Tower : From tusc Till DBWn Сообщений: 137 |
Имхо этого недостаточно. Лично я убежден в том, что разработчики должны знать реальное распределение данных в лицо, иначе он не сможет понять, какой план хороший. А распределение данных в общем случае <> статистике. Нужно, чтобы row source в трейсе было правильным. Поэтому я бы делал development БД как копию промышленной (при необходимости пропущенной через какой-либо data masking) |
||
| 22 дек 10, 17:24 [9983119] Ответить | Цитировать Сообщить модератору | |||
| Все форумы / Oracle | ![]() |
|