Pull to refresh

Comments 23

Хорошая попытка, Oracle, но наши заказчики уже требуют миграции с вашей БД т.к. ценик для них стал за гранью здравого смысла, да и к 12 версии ряд вопросов есть:

  • Один заказчик чуть не потерял свою базу т.к. отказалась запускаться pluggable БД и несколько неплохих специалистов так и не смогли за день ее оживить, бэкапы спасли.
  • Кстати о бэкапах: бэкап в 11 версии идет 10 минут, бэкап 12 версии после переноса из 11 идет 50 минут.
То есть вы без техподдержки? О каком тогда ценнике вы говорите? А если с техподдержкой, то где детали? Номер бага?
я выступал в качестве стороннего наблюдателя, занимались спеца заказчика.
То есть, если уточнить — то сторонний наблюдатель, да еще и не специалист по Oracle? И вы категорически уверены, что ошибки были именно оракла, а не человеческий фактор?
Да, сторонний. Я ничего категорически не утверждаю и не исключаю человеческий фактор, тем более что тогда 12 версия только вышла.
Однако игнорировать реакцию заказчиков на ценник невозможно по понятным причинам.
Как и игнорирование увеличения время бэкапа в 5 раз: раньше версию обновляли за 20 минут, теперь час при учете того, что непосредственно обновление как было 10 минут, так и осталось, а бэкап перед обновлением выполняется 50 минут вместо 10.
У Оракла уйма настроек в том числе и касающихся бэкапа...
Ну и к слову, у меня ни на одной из баз переведенных на 12с таких проблем не было.
Сервер HP 12 ядер, 128Гб память, RAID5 SAS диски, тестовая БД, активности на сервере нет, используем expdp.

`
;;;
Export: Release 12.1.0.1.0 — Production on Tue Mar 15 17:01:09 2016

Copyright © 1982, 2013, Oracle and/or its affiliates. All rights reserved.
;;;
Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 — 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/****@TESTDB SCHEMAS=TEST032 EXCLUDE=STATISTICS DIRECTORY=DATA_PUMP_DIR DUMPFILE=TEST032-2016.03.15.DMP LOGFILE=TEST032-2016.03.15.DMP.LOG
Estimate in progress using BLOCKS method…
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 1.921 GB

...

Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Tue Mar 15 17:57:21 2016 elapsed 0 00:56:01

`
1321 таблица, 2 самые толстые по миллиону записей и занимают чуть более 400Мб.
419 пустых таблиц.
Всего 1.9 ГБ? В техподдержку писали? В принципе, могу помочь, если отправите на почту лог, и желательно ash report во время дампа.

зы. Хотя бы на форум написали бы — давно бы уже кто-нибудь помог.
Поддержки у нас нет, основная деятельность у меня — разработка на C# и оракл мне более интересен с точки зрения разработчика (с этой стороны тоже не все гладко).

Насчет помощи — спасибо за предложение, попробую собрать нужное.
UPD: Проблему с backup'ом спокойно решили.
Да, посмотрим как он будет вести себя в течении недели после изменений.

Спасибо за помощь.
ETCDema
Oracle Database — это очень сложное программное обеспечение. К сожалению, в нём, как и в других программных продуктах, встречаются Bugs. Bugs могут быть и в Oracle 11.2 и в Oracle 12.1. Например, Bug 18793246 EXPDP slow showing base object lookup during datapump export causes full table scan per object. Oracle рекомендует проводить тестирование при переходе на новую версию и, конечно, иметь лицензии и техническую поддержку.
Сколько уже раз говорить что expdp это не бэкап.
Строго говоря, да, expdp не относится ни к RMAN backup, ни к user-managed backup, но Oracle сам смущает новичков, например тут:

Logical backups contain logical data such as tables and stored procedures. You can use Oracle Data Pump to export logical data to binary files, which you can later import into the database. The Data Pump command-line clients expdp and impdp use the DBMS_DATAPUMP and DBMS_METADATA PL/SQL packages.
Очередная маркетинговая статья на техническом ресурсе.

Oracle быстрее Hana в два раза! На каком железе? В какой конфигурации? Что за тест? Неизвестно.

Oracle "более лучше" масштабируется! Хотя даже начальных математических знаний достаточно, чтобы понять — примерно одинаково: просто посмотрите, насколько увеличивается производительность при увеличении количества ядер. Вангую, что на 504 ядрах Oracle все также будет в два раза лучше в тайном синтетическом тесте и даст примерно 4М попугаев.
Вы просто не в курсе, на самом деле, это достаточно нашумевшие результаты: это был родной тест от SAP, можете прочитать white paper и все спецификации тут:
http://www.oracle.com/technetwork/database/in-memory/overview/benefits-of-dbim-for-sap-apps-2672504.html
https://blogs.oracle.com/exadatapartnercommunity/entry/oracle_database_in_memory_vs
https://www.oracle.com/corporate/features/oracle-powers-sap.html
Спасибо, этих ссылок не хватало в статье.
kanikeev
Подробное описание теста можно найти здесь http://www.oracle.com/technetwork/database/in-memory/overview/benefits-of-dbim-for-sap-apps-2672504.html
Это был стандартный SAP BW-EML Benchmark.
О "более лучше" масштабируется. Неудачный перевод с английского, приносим извинения. Имелось в виду, что для достижения Oracle результатов SAP HANA требуется большее количество процессоров и оперативной памяти. Кроме того, Oracle опубликовал результаты тестов для 1, 2, 4 и 8 узлов, которые показывают почти линейную горизонтальную масштабируемость Oracle In-Memory. О характере горизонтальной масштабируемости SAP HANA можно только предполагать, т.к. доступны результаты тестирования для 1 и 7 узлов.
Спасибо за ссылку, жаль ее не было в самой статье.
Ждем, что ответит SAP.
Мы уже говорили о том, что от тяжелых монолитных приложений ИТ-отрасль переходит к веб-сервисам.

лучше поздно, чем никогда...
Sign up to leave a comment.