|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Вопрос к практикующим DBA у которых базы находяться на виртуалках. Суть: Есть: БД (будем считать ее однонодовой) , данные расположены на ASM. Экземпляр и данные под VMWARE, ASM расположен на VMDK. Админы собираются ее переносить "на горячую" из одной локации в другую. Информация (Oracle Databases on VMware Best Practices Guide) говорит о том, что VMware как бы поддерживается Oracle (хотя там все настолько мутно написано, учитывая то, что оракл из виртуализаций поддерживает только свою виртуалку). Вопрос к тем, кто проделывал подобное, насколько это безопасно с точки зрения консистентности БД, есть ли тут какие-то подводные камни ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 12:59 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Добрый день ну как бы цепляем новые диски-луны на виртуалку конфигурируем asmlib / or udev (что там в работе) смотрим на доступное для ASM kfod verbose=true, disks=all status=true op=disks asm_diskstring='<куда смотреть>' добавляем новое и делаем ребаланс удаляем старое и делаем ребаланс ALTER DISKGROUP DATA ADD DISK '.....' NAME .... REBALANCE POWER 5; ALTER DISKGROUP DATA DROP DISK...... REBALANCE POWER 5; Конечно-же предварительно ставим тестовую виртуалку и такой-же конфигурацией и такими-же версиями софта, заливаем данные и проверяем после игришь с ASM. Раз читали best practices for VmWare и было непонятно - то продолжаем читать до просветления. Вдруг там какой-то волшебный параметр У меня это работает на реальном железе, Hyper-V and Oracle VM Удачи ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 15:33 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Спасибо большое. Но, тут вопрос вот в чем. - Админы ЦОДА собрались переносить "на горячую" ноду с АСМ-ом на VMDK. Именно на горячую. То есть огромная БД, пока она работает ее переносят средствами VMWARE в другое хранилище, затем старую БД останавливают и включают новую. Непонятно как с консистентностью блоков при этом будет ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 15:54 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
quot A K, К счастью вмварь поддерживает Oracle :) В целом механизм переноса таким образом корректен, массово используется. Но вот с какими заморочками - хз, смотрите бумажки от мвари по этой теме ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 15:59 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
понятно. Большое спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 16:14 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Безопасно. Это называется storage vmotion, там никакой особой магии нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 18:37 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
vmotion, Да. Но, дело не в магии. Просто непонятно. Смотрите - БД к примеру десятки террабайт. Переноситься она будет несколько дней, за это время она, будучи высоконагруженной, генерит около террабайта архивредологов, а может и больше. Это же все эти террабайты измений нужно отслеживать, что бы потом в конце копирования получить абсолютно консистентную копию БД в реальном времени. И это всё без применения потом архивредологов. А как же тогда, заявление Оракл, что ASM-БД копируются и переносятся только через RMAN. Зачем тогда вообще RMAN, если можно вот так вот делать копии БД. То что сейчас делают копии БД с помощью снятия копий с виртуалки (без РМАН-а), это понятно и обыденно, но я читал, что это не рапространяется на ASM, для него нужно по-прежнему применять только RMAN. Плюс для консистентности нужно все равно потом донакатить дельту архивредологов (как минимум если из виртуального клона БД мы хотим получить копию консистентную по времени созданную позже этой копии). Но выходит что сейчас можно и без РМАН-а и без архивредологов, на живую перенести с помощью vmotion огромную, высоконагружденную БД под АСМ и при этом нет необходимости применять в конце архивредологи для согласования блоков. Как то это не очень укладывается в сознании. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 20:24 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
A K, Разница в том, что vmware старается обеспечить консистентность дискового образа, а rman - datafile В штатном режиме, этого хватает, но бывают тонкости ... Например, в одной большой, большой организации, работала сильно нагруженная база Как backup для восстановления, использовался HP Continues (блоковая репликация томов) несколько раз, переключение на резервную копию проходило удачно. И вот в один, не очень удачный момент, произошёл очередной сбой. При попытке поднять базу, посыпались ошибки. Поднять копию не удалось. пришлось восстанавливаться из backup и накатывать честные archivelog Тут выясняется, что текущая версия базы, имеет bug с parallel recovery. И восстановление очень сильно затянулось. Долго не могли понять что произошло. "Доктора" как с Оracle, так и с HP пытались обнаружить проблему. В конце концов обнаружили "суслика". Оказалось, в этот момент работал фоновый процесс дефрагментации, который никто особо не настраивал, и про который было сказано, но как-то невнятно, бо это сильно низкоровневый уровень. Если бы не сбой, что все было бы нормально, но что-то пошло не так. Где и что там что сбойнуло, не озвучивалось, но результат был налицо. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.05.2019, 21:05 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
A K, не путайте vmotion (перенос работающей ВМ с одного гипервизора на другой при неизменном общем сторадже) и описанный здесь storage vmotion (перенос vmdk-файлов ВМ с одного стораджа на другой при работе ВМ на одном гипервизоре). Первый случай, кстати, может негативно воздействовать на экземпляр в случае очень высокой активности памяти ВМ, особенно с медленной сетью vmotion, и, как следствие, продолжительного stun-а («заморозки» ВМ на финальном участке переезда с гипервизора на гипервизор) - если этот stun продлится более 3 секунд (случай, впрочем, исключительный, обычно это величины не более порядка десятков и сотен миллисекунд), экземпляр гаантированно завалится. При storage vmotion тоже будет stun, но очень короткий. RMAN здесь вообще не при чём, т.к. переезд осуществляется на уровне ниже, чем это может «увидеть» ОС или приложение. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2019, 09:38 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
И еще, есть юридическая мина использования vmware Для использования не лицензированных гипервизоров для разворачивания VM с поднятой Oracle Database, Oracle требует покупки лицензий на все ядра, всех физических серверов VMware Были случаи успешного юридического решения судебных споров с Oracle, но... 1) окончательно, в этой юридической битве титанов, точка еще не поставлена. 2) ведения этих битв требует колоссальных ресурсов. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2019, 10:10 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Oracle требует покупки лицензий на все ядра, всех физических серверов VMware Если хосты в кластере Если нет - то лицензируется только хост ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2019, 10:42 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
landyOracle требует покупки лицензий на все ядра, всех физических серверов VMware Если хосты в кластере Если нет - то лицензируется только хост Все верно, но судя по вопросу ТС, у них первый случай ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2019, 11:36 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Уже много раз говорено - лицензировать нужно ядра только тех гипервизоров, на которых ВМ с БД Oracle фактически работает. Бремя доказательства вины (нарушения условий лицензионного соглашения) лежит на истце. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2019, 12:00 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Vadim Lejnin Разница в том, что vmware старается обеспечить консистентность дискового образа, а rman - datafile В штатном режиме, этого хватает, но бывают тонкости ... Это понятно. Уровень vmware копирования и восстановления образа (vmotion - копирование файла) в новом месте осуществляеться исключительно средствами самого vmware без привлечения каких либо механизмов оракла в том числе и архивредологов. Получается что, Оракл БД как бы даже не знает о происходящем и в этом процессе не учавствует никаким образом. Просто после горячего переезда, включается инстанс с копией-БД и все работает, без неконсистентных блоков внутри бд, как будто никакого копирования не происходило. Это понятно, и это в идеале. На практике, судя из вашей очень интересной истории получаются "забавные" ситуации. Из чего я делаю вывод, что всегда после таких операций сразу нужно делать верификацию всех датафайлов БД на предмет бэдов. Поражает другое: технологии уже дошли до такого, что гиганские объемы данных перемещаются, и что самое важное поддерживаются при этом в консистентном состоянии практически в реальном времени, без особой деградации производительности работающей перемещаемой системы в процессе переноса. Но исходя из ваших постов, получается, что эта технология работает пока не очень стабильно. Scott Tiger A K, не путайте vmotion (перенос работающей ВМ с одного гипервизора на другой при неизменном общем сторадже) и описанный здесь storage vmotion (перенос vmdk-файлов ВМ с одного стораджа на другой при работе ВМ на одном гипервизоре). Первый случай, кстати, может негативно воздействовать на экземпляр в случае очень высокой активности памяти ВМ, особенно с медленной сетью vmotion, и, как следствие, продолжительного stun-а («заморозки» ВМ на финальном участке переезда с гипервизора на гипервизор) - если этот stun продлится более 3 секунд (случай, впрочем, исключительный, обычно это величины не более порядка десятков и сотен миллисекунд), экземпляр гаантированно завалится. При storage vmotion тоже будет stun, но очень короткий. RMAN здесь вообще не при чём, т.к. переезд осуществляется на уровне ниже, чем это может «увидеть» ОС или приложение. Интересно. Они собираются переносить и работающую ноду и АСМ-сторадж. Ну сторадж, это 2-м способом однозначно. А вот как работающую ноду, не знаю :) Но, судя по всему 1-м. Относительно RMAN-а - это понятно :). Просто я его упоминаю в контексте альтернативного, старого и надежного способа переноса (как правило с созданием стендбая) данных. Обсуждаю сравнение, чем лучше и надежнее делать эту самую миграцию. Ведь и тем и другим способом осуществляеться перенос и бэкапирование, а то, что они работают на очень разных слоях (ниже ОС (виртуалка) и в среде операционки (рман)) - так кто ж с этим спорит. И еще хотелось бы прояснить такой момент. Как происходит при vmotion переключение между старым и новым экземпляром БД. Ведь в момент окончания копирования и актуализации файла с данными и ноды на новом месте, нужно так успеть погасить старый экземпляр, что бы не потерялись последнии транзакции. Да, с лицензиями все нормально. Итак! Получается, что все же пока (технологии условно аппаратного переноса пока еще не совершенны) лучше переносить данные старым добрым рман-стендбай-методом. Ну а если у ЦОД-цев БД не завалиться (из за vmotion) и перенос пройдет относительно успешно, нужно сразу же проводить верификацию БД на предмет бэдов. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.05.2019, 12:01 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
A Kvmotion, Да. Но, дело не в магии. Просто непонятно. Смотрите - БД к примеру десятки террабайт. Переноситься она будет несколько дней, за это время она, будучи высоконагруженной, генерит около террабайта архивредологов, а может и больше. Это же все эти террабайты измений нужно отслеживать, что бы потом в конце копирования получить абсолютно консистентную копию БД в реальном времени. И это всё без применения потом архивредологов. А как же тогда, заявление Оракл, что ASM-БД копируются и переносятся только через RMAN. Зачем тогда вообще RMAN, если можно вот так вот делать копии БД. То что сейчас делают копии БД с помощью снятия копий с виртуалки (без РМАН-а), это понятно и обыденно, но я читал, что это не рапространяется на ASM, для него нужно по-прежнему применять только RMAN. Плюс для консистентности нужно все равно потом донакатить дельту архивредологов (как минимум если из виртуального клона БД мы хотим получить копию консистентную по времени созданную позже этой копии). Но выходит что сейчас можно и без РМАН-а и без архивредологов, на живую перенести с помощью vmotion огромную, высоконагружденную БД под АСМ и при этом нет необходимости применять в конце архивредологи для согласования блоков. Как то это не очень укладывается в сознании. VMware не занимается "отслеживанием". Делает снапшот и сначала переносится он, а потом дельта. Потом дельта применяется, потом дельта за время применения предыдущией дельты и так далее, пока оставшаяся деальта не станет малой и тогда vmware просто замораживает ввод-вывод исходной виртуалки и быстро переключает ее на новый диск. Так вот при определенной скорости генерации изменений (т.е. дельты на исходном диске) миграция просто никогда не закончится. А оракл там, асм не асм не имеет вообще никакого значения. И консистентность будет обеспечена в любом случае. А опасаться надо описанного выше. Там по результатам мигрируемая виртуалка может просто встать колом и будет долго ждать отмены миграции и консолидации. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2019, 03:36 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Не много по другому миграция делается, но сути дела это не меняет. Во-первых, при инициировании миграции, VMware vSphere копирует все файлы виртуальной машины, за исключением виртуальных дисков, на новое целевое виртуальное хранилище. Во-вторых, в VMware vSphere включается технология Changed Block Tracking для диска виртуальной машины. VMware vSphere отслеживает изменяющиеся блоки и записывает эти данные в битовый массив. Обычно этот битовый массив хранится в памяти VMware ESX / ESXi. Далее VMware vSphere «пре-копирует» диск виртуальной машины и swap-файл с целевого устройства на хранилище назначения (первая итерация). В это время виртуальная машина может продолжать запись в виртуальный диск. В это время некоторые блоки диска меняются и отслеживаются технологией Changed Block Tracking. Далее изменившиеся данные посылаются vSphere на целевой диск и применяются там (вторая итерация). При этом во время такого копирования данные на исходном диске также изменятся и также эти изменения отследятся Changed Block Tracking. Таким образом, итерации будут продолжаться до тех пор, пока объем изменений не будет настолько мал, что они будут переданы мгновенно на целевой виртуальный диск. Теперь ESX вызывает «быстрый приостанов-старт» виртуальной машины (fast suspend/resume). Виртуальная машина «приостанавливается» (suspend) на хосте ESX и процесс, реализующий виртуальную машину, запускает ее уже с целевого хранилища (resume). Именно в этот момент происходит последняя итерация копирования изменившихся данных исходного диска на целевой vmdk. Таким образом, виртуальные диски исходного и целевого виртуального хранилищ оказываются идентичны, после чего происходит resume виртуальной машины. После того, как виртуальная машина запустилась с целевого хранилища, ее виртуальные диски и другие файлы на исходном хранилище уничтожаются. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2019, 03:40 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Scott TigerУже много раз говорено - лицензировать нужно ядра только тех гипервизоров, на которых ВМ с БД Oracle фактически работает. Бремя доказательства вины (нарушения условий лицензионного соглашения) лежит на истце. Oracle on VMware – adding non-standard terms to your Oracle agreement 05 September 2018 https://www.itassetmanagement.net/2018/09/05/oracle-on-vmware-adding-non-standard-terms-to-your-oracle-agreement/ Different ways of counting VMware’s vSphere technology provides different functionalities, depending on the specific version used. Due to the different functionalities offered, different ways of counting the required number of licenses are applicable. Below is a simple overview of the major rules that should be taken into account: VMware’s vSphere ESXi up to 5.0 In older versions of VMware’s vSphere ESXi, up to 5.0, shared storage is required for the virtual machines running Oracle to move throughout the VMware environment. In these situations, the Oracle software is installed on shared storage and the entire cluster(s) connected to the shared storage have the ability to run Oracle. As a result of this, Oracle requires you to license all the physical cores of the physical ESXi hosts that are part of the cluster that is connected to shared storage within the VMWare environment. VMware’s vSphere ESXi 5.1 – 6.0 In newer versions of vSphere ESXI, 5.1 and later, shared storage is no longer required to live migrate a running virtual machine. A virtual machine running Oracle can move anywhere within the vCenter Server Instance and shared storage no longer serves as the install point for Oracle. As a result of this, Oracle requires you to license all the physical cores of all the physical ESXi hosts that are part of the same vCenter Server Instance, including across datacenters within the vCenter Server Instance, since the end user has the ability to move the virtual machine running Oracle software to any server within the vCenter Server Instance. VMware’s vCenter 6.0 and higher With vCenter Server 6.0 or higher, a running virtual machine can move across vCenter Server Instances which impacts licensing across the entire environment. As a result of this, Oracle requires you to license all the physical cores of all the physical ESXi hosts of all the vCenter Server Instance(s) which have hosts with ESXi 5.1 or later hypervisors. Non-Standard Language Non-Standard Language Due to these changing rules for more recent VMware releases, the number of licenses required (as per Oracle’s counting policies as explained above) – and the associated cost – is becoming increasingly high. As such, a growing number of organsiations are successfully adding specific non-standard language to their Oracle license agreement, e.g. through an amendment on their Oracle Master Agreement (OMA). This allows them to “ring-fence” their Oracle on VMware environment and has become a rather standard process within Oracle. Your Oracle Sales representative is responsible for driving this procedure internally within Oracle and for receiving approval to add non-standard language to your agreement. In order to obtain such approval, you will need to have 3 components which address the isolation of the network and storage layer outside of virtualization software features / functionalities. The following details need to be included to obtain this approval from Oracle: 1. Architectural Diagram : You need to create an architectural diagram illustrating the existing configuration and planned configuration. In such a diagram, you are required to explain how the network and/or storage layers isolate the Oracle clusters/servers. In addition, you need to detail any specific technology you may use to achieve this goal (e.g. LUN masking) 2. Physical Hosts & Storage Layer : You are required to detail how the physical hosts and storage layer are isolated utilizing technology outside of virtualization control. 3. Audit Proof : You need to be able to prove how the environment can be quantified and measured during the course of an audit. This could for example be done in the form of network admin screenshots that demonstrate how the hosts are isolated and storage admin screenshots that demonstrate how storage is restricted to only the Oracle hosts. Non-Standard Language = Нестандартная формулировка (не язык!) То же самое, в переводе Google translate [b] Различные способы подсчета [/ b] Технология VMware vSphere предоставляет различные функции в зависимости от конкретной используемой версии. В связи с различными предлагаемыми функциями применяются разные способы подсчета необходимого количества лицензий. Ниже приведен простой обзор основных правил, которые следует учитывать: [b] vSphere ESXi от VMware до 5.0 [/ b] В более старых версиях VMware vSphere ESXi вплоть до 5.0 для виртуальных машин, работающих под управлением Oracle, требовалось общее хранилище для перемещения по среде VMware. В этих ситуациях программное обеспечение Oracle устанавливается в общем хранилище, и все кластеры, подключенные к общему хранилищу, могут запускать Oracle. В результате этого Oracle требует от вас лицензирования всех физических ядер физических хостов ESXi, которые являются частью кластера, подключенного к общему хранилищу в среде VMWare. [b] VMware vSphere ESXi 5.1 - 6.0 [/ b] В более новых версиях vSphere ESXI, 5.1 и более поздних версиях, общее хранилище больше не требуется для динамической миграции работающей виртуальной машины. Виртуальная машина под управлением Oracle может перемещаться в любое место внутри экземпляра vCenter Server, и общее хранилище больше не служит точкой установки для Oracle. В результате этого Oracle требует от вас лицензирования всех физических ядер всех физических хостов ESXi, являющихся частью одного экземпляра vCenter Server, в том числе через центры обработки данных в экземпляре vCenter Server, поскольку конечный пользователь имеет возможность перемещать виртуальная машина, на которой запущено программное обеспечение Oracle, на любой сервер в экземпляре vCenter Server. [b] VMware vCenter 6.0 и выше [/ b] В vCenter Server 6.0 или более поздней версии работающая виртуальная машина может перемещаться между экземплярами vCenter Server, что влияет на лицензирование во всей среде. В результате этого Oracle требует от вас лицензирования всех физических ядер всех физических хостов ESXi всех экземпляров vCenter Server, которые имеют хосты с гипервизорами ESXi 5.1 или новее. [b] Нестандартный язык [/ b] Из-за этих изменяющихся правил для более поздних выпусков VMware количество требуемых лицензий (согласно описанным выше политикам подсчета Oracle) и связанные с этим затраты становятся все более высокими. Таким образом, все большее число организаций успешно добавляют определенный нестандартный язык в свое лицензионное соглашение Oracle, например, путем внесения изменений в свое Генеральное соглашение Oracle (OMA). Это позволяет им «ограждать» свой Oracle на среде VMware и стало довольно стандартным процессом в Oracle. Ваш представитель по продажам Oracle отвечает за выполнение этой процедуры внутри Oracle и за получение разрешения на добавление нестандартного языка в ваше соглашение. Чтобы получить такое одобрение, вам необходимо иметь 3 компонента, которые предназначены для изоляции уровня сети и хранилища от функций / функций программного обеспечения для виртуализации. Для получения этого одобрения от Oracle необходимо указать следующие данные: 1. [b] Архитектурная схема [/ b]: Вам необходимо создать архитектурную схему, иллюстрирующую существующую конфигурацию и запланированную конфигурацию. На такой диаграмме вам необходимо объяснить, как уровни сети и / или хранилища изолируют кластеры / серверы Oracle. Кроме того, вам необходимо детализировать любую конкретную технологию, которую вы можете использовать для достижения этой цели (например, маскировка LUN) 2. [b] Физические хосты и уровень хранилища [/ b]: вам необходимо подробно описать, как физические хосты и уровень хранилища изолированы с использованием технологий, не связанных с управлением виртуализацией. 3. [b] Аудиторское подтверждение [/ b]: Вы должны быть в состоянии доказать, как можно измерить и измерить среду в ходе аудита. Это можно сделать, например, в виде снимков экрана сетевого администратора, которые демонстрируют, как изолированы хосты, и снимков экрана администратора хранилища, которые показывают, как хранилище ограничено только узлами Oracle. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2019, 14:33 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
SQL*PlusScott TigerУже много раз говорено - лицензировать нужно ядра только тех гипервизоров, на которых ВМ с БД Oracle фактически работает. Бремя доказательства вины (нарушения условий лицензионного соглашения) лежит на истце. Oracle on VMware – adding non-standard terms to your Oracle agreement 05 September 2018 https://www.itassetmanagement.net/2018/09/05/oracle-on-vmware-adding-non-standard-terms-to-your-oracle-agreement/ Different ways of counting Таких ничем (минимально должны быть отсылки на oracle.com) не подкреплённых и часто противоречивых статей в интернете много, в то время как условия лицензирования в общем случае не менялись последние много лет. Конечно, внести дополнительные условия в OMA - тоже вполне допустимый вариант, избавляющий, например, от необходимости выступать ответчиком. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2019, 17:24 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
Scott TigerSQL*Plusпропущено... пропущено... Таких ничем (минимально должны быть отсылки на oracle.com) не подкреплённых и часто противоречивых статей в интернете много, в то время как условия лицензирования в общем случае не менялись последние много лет. Конечно, внести дополнительные условия в OMA - тоже вполне допустимый вариант, избавляющий, например, от необходимости выступать ответчиком.Всё так. Но лучше не эксплуатировать производственные базы данных в среде VMware. Лучше их использовать на голом железе или под управлением Oracle VM. В этом случае вы будете иметь систему, которая поддерживается вендором, и будете избавлены от риска неожиданных затрат и/или других ненужных неприятностей. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2019, 18:47 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
SQL*Plus Всё так. Но лучше не эксплуатировать производственные базы данных в среде VMware. Лучше их использовать на голом железе или под управлением Oracle VM. В этом случае вы будете иметь систему, которая поддерживается вендором, и будете избавлены от риска неожиданных затрат и/или других ненужных неприятностей. Согласен !!! Но, к огромному сожалению сейчас тенденция такова, что скоро всё ПО и БД и приложения будут на виртуалках. Ничего не останеться на железяках, как раньше. Хотим мы этого или нет - такова реальность и изменить тут ничего не получиться. Всем спасибо за комменты. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 18:33 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
A KSQL*Plus Всё так. Но лучше не эксплуатировать производственные базы данных в среде VMware. Лучше их использовать на голом железе или под управлением Oracle VM. В этом случае вы будете иметь систему, которая поддерживается вендором, и будете избавлены от риска неожиданных затрат и/или других ненужных неприятностей. Согласен !!! Но, к огромному сожалению сейчас тенденция такова, что скоро всё ПО и БД и приложения будут на виртуалках. Ничего не останеться на железяках, как раньше. Хотим мы этого или нет - такова реальность и изменить тут ничего не получиться.Тогда придётся резервировать средства на риски "неожиданных затрат". И было бы хорошо сразу доложить об этом руководству. Глядишь, и "неизменяемая" реальность изменится! :-) Is Oracle Changing their Position on VMWare? by Craig Guarente | May 14, 2018 https://palisadecompliance.com/oracle-vmware-position/ Despite having nothing in their contracts that require Oracle customers to license software on processors where Oracle was never used, Oracle continues to push their line that customers using VMWare need to pay more than customers who run on bare metal or those that use Oracle’s virtualization technology. Перевод на русский от GoogleНесмотря на то, что в их контрактах нет ничего, что требовало бы от клиентов Oracle лицензировать программное обеспечение на процессорах, где Oracle никогда не использовалась, Oracle продолжает настаивать на том, что клиенты, использующие VMWare, должны платить больше, чем клиенты, работающие на голом железе или те, которые используют технологию виртуализации Oracle. Прочитайте эту короткую статью целиком. В ней есть еще много интересного. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 18:49 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
A Kскоро всё ПО и БД и приложения будут...жду-не дождусь. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2019, 19:52 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
-2-A Kскоро всё ПО и БД и приложения будут...жду-не дождусь.Ждёте не дождётесь, когда придётся резервировать средства на риски "неожиданных затрат"? :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.05.2019, 11:15 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
to -2- и SQL*Plus - вы правы оба. SQL*Plus - прочитал я вашу статью по лицензиям. Да, действительно много очень интересного. Что поделать, технологии бегут вперед, Оракл рискует потерей прибылей в этой гонке технологий. -2- а вы, навереное из ярых поклонников виртуализации - сейчас таких становиться всё больше и больше. Ну а если объективно, абстрагироваться от лицензий, рынка ит.д. а чисто технически посмотреть на вопрос, то что можно увидеть: 1. Безусловно БД лучше ставить на голое железо. Причем любые БД, особенно высоконагруженные. На это есть масса причин, обсуждать которые очень долго. 2. Технологии виртуализации, в первую очередь благодаря переходу с харда на схд (то есть революционным прорывам в аппаратной части), сильно продвинулись за последние годы, так что сейчас даже на Виртуальных машинах, скорость работы с переферией стала намного выше, чем ранее на обычном голом железе. 3. Крупные вендоры начинают беспорядочно менять свои правила извлечения прибыли от продажи продуктов, пытаясь противостоять виртуализации на своем уровне (ужесточая правила покупок), так как их старые правила лицензирования, не были подготовлены к такому повороту событий, будучи жестко привязанные к аппаратным конфигурациям. 4. Как следствие этого + иных причин, многие потребители услуг БД, начинают массово переходить на свободное програмное обеспечение (Постгресс, и даже NoSQL решения), благо апапратные мощности уже сейчас позволяют строить решения сопоставимые по производительности и прочим критериями качества. Как то так. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.05.2019, 13:37 |
|
Перенос БД с АСМ под VMWARE на новое хранилище
|
|||
---|---|---|---|
#18+
A K-2- а вы, навереное из ярых поклонников виртуализацииГде в моем сообщении "виртуализация"? Многоточие обобщает скептицизм к относительности, выраженной словом "скоро", и к абсолютизму, выраженному словом "всё". ... |
|||
:
Нравится:
Не нравится:
|
|||
23.05.2019, 13:55 |
|
|
start [/forum/topic.php?fid=52&msg=39816753&tid=1882476]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
32ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
others: | 305ms |
total: | 447ms |
0 / 0 |