First LVOUG conference

LVOUG group conference is announced! This is first conference in this group history. Conference is organized  in two sessions, scheduled on 27 mart 2009, from 13:00 to 18:30, in Hotel Monika, Elizabetes iela 21, Riga. More information on link

I’m also happy to take participation in this conference, trying to make fun, running oracle database with noarchivelog mode and applying different crash and recovery methods 😉

Few notes on ‘Advanced Oracle Troubleshooting Seminar’ with Tanel Poder in Latvia.

On 21 November 2008, occurred long awaited event in Latvia – Advanced Oracle troubleshooting seminar with Tanel Poder (http://blog.tanelpoder.com/seminar/). The seminar was arranged by Affecto Latvia and Oracle University, lasted 2 days, and collected about 30-40 participants .

 Tanel started with the basics and continued with more advanced things touching practically every aspect of oracle troubleshooting. Advanced, in this context, means is what you do when all available oracle tools failed to show where the problem is. In this situation, Tanel proposing to troubleshoot oracle as standard UNIX application, perform traces and stack dumps, providing amazing information about what is what within stack trace.

 Another amazing thing is to see how very skilled professionals are working. I see this as very good opportunity to learn. Here he is showing fast and efficient way to deal with problems using his own custom build scripts. This approach is really accelerate process of diagnostics, especially when you are consulting professional with limited access to production servers and environment. But I think, this approach will be very useful for DBA as well, since for High Availability systems it’s very important to reduce impact on system as fast as possible, and for this purpose, systematic approach and planned environment is very important.

 I’ve personally very inspired by Tanel’s work and dedication and would like to thank you for great work and hope to see you in Riga again, with 3-5 extended seminar. Also, would like to thank Affecto Latvia and OU, that made this event possible, here, in Riga.

Заметки с hotsos’06. Искусство решения проблем.

Докладчик: Kerry Osborn

Эта тема посвящена решению проблем в компьютерных системах. Автор Kerry Osborn, был много лет руководителем одной из консалтинговых компатий и по своему роду деятельнеости ему приходилось работать со многими проффесионалами, умными и якрими людьми, однако он заметил, что способность быстро решать сложные проблемы, очень слабо коррелирует с интеллектуальными способностями или огромным техническим опытом. Тогда почему же некоторые люди лучьше решают проблемы, чем другие, имея одинаковый уровень интеллекта, этику работы и тех. основы?

Автор Керри Осборн, пытался ответить на этой вопрос не один год, надо заметить что он не психолог, а человек который как и мы непосредственно занимается решением проблем, поэтому это больше заметки опытного человека, чем подтвеждение теории прсихологии.

Для бизнесс критической системы, любая проблема имеет прямую связь с убытками, поэтому основная задача – решить проблему как можно быстрее. Пусть это иногда не решает суть проблемы, но важно как можно быстрее восстановить работу, после чего можно уже заняться сутью.

Процесс решения проблем имеет следующие этапы.

• Дефинировать проблему. Достаточно странно, но этот шаг один из самых сложных. Для технических людей, может быть очень сложно оценить насколько проблема имеет влияние на бизнес. Мы больше думаем в зачениях техн. показателей, а не влиянии на бизнесс процессы. Это важный вопрос, потому что, от того как мы продефинируем проблему, зависит набор конечных решений.
• Сбор данных. Основная проблема – отделить зерна от плевел. Это похоже на работу следователя, он собирает все свидетельства которые доступны, и потом отбирает из них факты. Т.е. важно непредвзято собрать все доступные свидетельства.
• Постулирование причин. Та информация, которая была собрана, должна быть подтверждена на опыте, тоже относиться к предположениям, которые были сделаны. Основная проблема – в том, чтобы не перейти к этому этапу слишком быстро с предыдущего этапа, с недостаточной информацией.
• Возможные решения. На основе предположений сделанных на пред. этапе., вырабатываються возможные решения. Этот этап требует творчества, чтобы получить как можно больше решений.
• Последовательность применения решений, один из важных шагов который определяет как быстро мы прийдем к решения проблемы.

Советы по решению проблем.

• Нарисовать схему

• Использовать аналогии

• Изменить определение проблемы.

• Взять паузу. Было замечено, что если решение не приходит, имеет смысл отстраниться на некоторое время, и тогда решение или идея как бы всплывает сами.

• Вербализация проблемы. Обсудить проблему.

• Усомниться в традиционном решении. Если проблема не решаеться, можно попробовать противоположный от традиционного подход.

• Усомниться в необходимости. Самый быстрый способ, что либо сделать – не делать это.

• Принять неопределенность. Было замечено что люди которые хорошо себя чуствуют в ситуации неопределенности – лучьше решают проблемы.

• Не поддаваться стрессу. Стресс очень плохо влияет на творчество, но к сожалению наша работа связана сос стрессом, мы не может этого избежать, но мы можем научиться управлять стрессом.

Негативные поведенческие привычки:

• У меня есть молоток и все выглядит как палец. Или симптом лени. У меня уже есть молоток в руках, зачем тратить время, чтобы взять плоскогубцы? Пример. Приложение обращаеться к базе считывает всю таблицу целиком, потом выбирает необходимые записи.

• Шпион против шпиона. Есть люди, которые держат свои знания в секрете, это дает им чувство безопастности относительно своего места работы. Или еще хуже – они используют свои знания как оружие. Эта стратегия показывает эффектвность для них какоето время, но почти во всех случаях заканчиваеться плачевно. Взаимосотрудничество – очень хорошее средство для генерации идей. Это ключ к шагу генерирования идей. Чем больше вариантов решений, тем больше шансов на успех.

• Наблюдатели не-гориллы. Был проведен эксперимент. Группу людей попросили наблюдать за баскетбольным матчем в течении 30 сек – и считать количество пассов – передач мяча. Потом их спросили –не видили ли они что нибудь странного? Только несколько человек подняли руки – они видели то что для других было большим сюрпризом- в середине фильма – на середину зала вышел человек переодетый в гориллу и начал бить себя в грудь. Часто бывает, что человек со свежим взглядом, сразу указывает на очень логичное решение проблемы, над которой бились часами. Вообщем – часто попасть под влияние деталей достаточно легко.
  
• Гудини. Был знаменит способностью выбираться из любой тюрьмы на несколько часов. Однажды, в одной из попыток, он пытался открыть замок, но ему это не удавалось сделать в течении нескольких часов. Когда же он совсем отчаялся и сел на пол прислонившись к двери спиной, дверь сама открылась – т.к. была просто не запертой. Он попался на собственное предположение – пытаясь сделать невозможное – открыть незапертый замок.
• Стресс. Психологами было проведено исследование – двум группам было дано задание, но дной группе сказали, что на выполнение этой задачи требуеться 1 минута, а другой 3 минуты. Однако в обеих группах, выполенение было прервано ровно через 1 минуту. Оказалось, что в группе которая думала что у них есть больше времени, задание было выполнено в 2 раза лучьше чем в первой, хотя время выполнения было одинаково.
• Ошибки могут рассматриваться как неудача или как возможнось научиться. Например, в компании 3M, разрабатывали очень сильный клей, но в результате получили очень слабый, вместо того чтобы его выкинуть, он лег в основу для 3M отрывных заметок. Люди успешные в решение проблем – люди любознательные и используют вызовы как возможность научиться.
• Страус. Это ситуация когда проблемы игнорируються и не решаються, надеясь на то что они решаться сами. Иногда действительно, в сложных системах, при опр. обстоятельствах, внезапно моджет появиттся проблема, и так же внезапно исчезнуть, однако зачастую эти проблемы появляються все чаще и чаще, пока не настанет момент, когда их игнорировать уже возможности не будет. Поэтому лучьше всего решать проблему тогда когда она появляеться
• Основная характеристика здесь – завышенная уверенность в себе. Пример, ставить в продуктион изменения без тестирования на тестовой. Хорошая доза осторожности с здоровым риском, повысят стабильность системы.
• Крестоносец. Помню ходили слухи, что есть памады вызавающие рак, и чтоб проверить надо потереть золотым кольцом. Тоже самое – в компютероном мире, существует множество мифов. Люди успешные в решении проблем, стремяться протестировать сущесвующие общепризнанные взгляды на вещи.
• Маньяк. Человек который стремиться довести все до конца без учета необходимости. Например потратить неделю чтобы выйграть 1% в производительности

Решение проблем это неотъемлемая часть нашей работы, над которой мы зачастую не задумываемся. Мы можем бысто и качественно решать проблемы если сможем учитывать вышепрведенные моменты.

Впечатления о конфереции hotsos’06, Даллас, США

В марте, 2006 года, с 5-9 числа, предоставилась возможность посетить конференцию HOTSOS по настройке производительности баз Oracle, которая проходила в Далласе, штат Техас, USA. Эта конференция устраиваеться уже несколько лет подряд и хорошо себя зарекомендовала. Организатором конференции является консалтинговая фирма hotsos, которая специализируеться в области настройки производительности oracle систем и проходила в конференс зале одной из гостиниц.

На конференции присутствовали около 500 человек участников. Из выступающих, выступали наверное человек 6 технических людей из oracle, 1 человек из компании SUN, а также целый ряд всемирно известных экспертов –J. Lewis, T. Kyte и др. Приятно был удивлен втретив своего земляка Юрия Великанова, который также выступал на конференции с очень интересной темой. Приятно было, также увидеть выступление замечательного специалиста Tanel Poder из Эстонии.

Лекции проходили в двух сессиях параллельно, с 8.30 до 18.00, каждый день. Интересный момент происходил в конце каждого дня, на сцену ставили большой стол, за который садились ряд экспертов , и можно было задать любой вопрос этому президиуму. J. Lewis, на вопрос о будующем баз данных, спрогнозировал, что скоро мы будем запускать oracle на мобильных телефонах, там можно будет делать все что угодно, кроме разве что нормально позвонить 🙂 Вообщем было очень много информации, очень интересно и полезно. Было, конечно, что и не понарвилось. Несколько выступлений, на мой взгляд, были очень низкого уровня. На уровне студента который начал подготовеу за ночь до экзамена. Меня тогда это очень удивило, особенно на фоне многих ярких и интересных презентаций.

В целом, мероприятие очень понравилось, если есть возможность обязательно стоит посетить.