RAC позволяет Вам главное - быть совершенно спокойным, что Ваше присутствие не потребуется во время сбоя. И Вы можете .. да хоть наслаждаться камином в районе полярного круга...just checking the performance from time to time...:)
сдается мне, что во время сбоя присутствие понадобится в любом случае...даже при наличии рака...хотя бы просто потому, что число узлов в кластере конечно :D
Дима Волков может спокойно продолжать наслаждаться камином в районе полярного круга. RAC не требует присутствия во время сбоя. В этом и состоит одна из идей высокой готовности RAC, т.к. мы запускаем СУБД одновременно на нескольких физически разделенных машинах.
Но вот если сбой произошел на диске (например, corruption базы), то RAC уже не спасет и понадобится еще и Data Guard, который для некоторых случаев позволяет задать автоматическую логику переключения на standby базу. Вот мы привели пример ситуации, когда и рака стало недостаточно.
Чтобы постоянно наслаждаться камином районе полярного круга и быть при этом совершенно спокойным надо подумать об очень обширном списке рисков. Для каждого риска есть множество технологий, которые закрывают этот риск. Это целая наука. Называется Risk Management. Смысл ее в том, что практически любой риск можно закрыть или существенно уменьшить -- были бы деньги :^). Организации внимательно смотрят на каждый риск и решают, будут ли они инвестировать в уменьшение риска, либо они принимают риск каким он есть.
Но некоторые риски нельзя закрыть даже за деньги. Например, риск того, что DBA в какой-то момент умрет и забудет пароль от Oracle Wallet. Этот риск можно немного уменьшить. Например, DBA может переехать из-за полярного круга в Швейцарию, где хороший климат -- были бы деньги, но жизнь любого человека даже в Швейцарии все равно конечна. В отличие от полярного круга, в Швейцарии существует ненулевая вероятность, что на DBA может упасть самолет, поэтому надо иметь двух DBA, а еще лучше трех или четырех и т.д. и т.п.
Аналогичную теорию можно развернуть про уязвимость rac с той точки зрения, что количество узлов в нем конечно... :^)
Oracle 9i,10g,11g OCP, 10g Certified RAC Expert, Oracle ACE.
В различное время своей жизни я работал в Oracle Corp & IBM Corp, но данный блог всегда являлся моим личным мнением и никак не был связан с моим работодателями:
"
The views expressed on this blog are my own and do not necessarily reflect the views of my employer."
Мой Linkedin profile:
linkedin.com/in/dsvolk
Skype, Hangouts: dsvolk
сдается мне, что во время сбоя присутствие понадобится в любом случае...даже при наличии рака...хотя бы просто потому, что число узлов в кластере конечно :D
ОтветитьУдалитьranger.
Дима Волков может спокойно продолжать наслаждаться камином в районе полярного круга. RAC не требует присутствия во время сбоя. В этом и состоит одна из идей высокой готовности RAC, т.к. мы запускаем СУБД одновременно на нескольких физически разделенных машинах.
ОтветитьУдалитьНо вот если сбой произошел на диске (например, corruption базы), то RAC уже не спасет и понадобится еще и Data Guard, который для некоторых случаев позволяет задать автоматическую логику переключения на standby базу. Вот мы привели пример ситуации, когда и рака стало недостаточно.
Чтобы постоянно наслаждаться камином районе полярного круга и быть при этом совершенно спокойным надо подумать об очень обширном списке рисков. Для каждого риска есть множество технологий, которые закрывают этот риск. Это целая наука. Называется Risk Management. Смысл ее в том, что практически любой риск можно закрыть или существенно уменьшить -- были бы деньги :^). Организации внимательно смотрят на каждый риск и решают, будут ли они инвестировать в уменьшение риска, либо они принимают риск каким он есть.
Но некоторые риски нельзя закрыть даже за деньги. Например, риск того, что DBA в какой-то момент умрет и забудет пароль от Oracle Wallet. Этот риск можно немного уменьшить. Например, DBA может переехать из-за полярного круга в Швейцарию, где хороший климат -- были бы деньги, но жизнь любого человека даже в Швейцарии все равно конечна. В отличие от полярного круга, в Швейцарии существует ненулевая вероятность, что на DBA может упасть самолет, поэтому надо иметь двух DBA, а еще лучше трех или четырех и т.д. и т.п.
Аналогичную теорию можно развернуть про уязвимость rac с той точки зрения, что количество узлов в нем конечно... :^)