|
Если вам нравится наш магазин - скажите об этом Google!
|
| 1 у.е. = 31.16 руб. |
| |
| Цены показывать: |
| |
|
|
| |
|
|
|
|
Система управления базами данных Линтер Linter Multiversion (на 1 процессор)
|
| Группа: |
Система управления базами данных Линтер Linter Multiversion
|
| Категория: |
СУБД/БАЗЫ ДАННЫХ
|
| Производитель: |
РЕЛЭКС
|
| Название производителя: |
Система управления базами данных Линтер Linter Multiversion (на 1 процессор) |
| Код: |
16-39-RELEX-SL |
| Язык интерфейса: |
Русский, Английский |
| Вид поставки: |
Коробка |
| Срок комплектации: |
от 10 до 20 дней |
| Платформы: |
Windows |
|
|
Коробочная поставка на 1 процессор.
Linter Multiversion - это СУБД с поддержкой версионной модели обработки данных.
В условиях непрерывного роста объёмов информации возможность параллельной обработки конкурирующих транзакций становится всё более актуальной. Linter Multiversion предназначена для разработки приложений, требующих обеспечения безконфликтности запросов на чтение и на запись в многопользовательской системе.
Linter Multiversion рекомендуется для тех приложений, в которых при использовании классического блокировочного сервера баз данных конфликт запросов на чтение и на запись начинает оказывать существенное влияние на производительность системы.
Linter Multiversion опирается на мощные возможности базовой версии Linter Standard. Система обеспечивает высокую доступность данных и более быструю обработку конкурирующих транзакций благодаря реализации многоверсионного хранения записей с поддержкой ANSI-уровней изолированности транзакций.
Linter Multiversion позволяет разработчикам создавать приложения, работающие под управлением различных операционных систем:
* Windows
* Linux
* FreeBSD
* SUN Solaris
* Mac OS X
* Unix System V
* HP-UX
* Android
* Windows CE
Многоверсионность позволила сделать чтение и модификацию данных независимыми процессами, т.к. модификация записи в таблице приводит к появлению новой версии этой записи. При этом в общем случае не требуется специального процесса "чистки" устаревших (неактуальных) версий, так как в системе реализован механизм их переиспользования.
Реализация механизма версионности позволила улучшить показатели распараллеливания при многопользовательской работе. При этом поддерживаются стандартные режимы работы транзакций от Dirty Read до Serializable.
Благодаря механизму многоверсионности каждая прикладная задача может долгое время независимо продолжать работу со своей версией изначальных данных. И только при команде фиксации транзакции потребуется синхронизация изменений сделанных с одними и теми же данным из различных программ.
Если две задачи изменили одни и те же данные, то успешная фиксация этих изменений возможна только для одной задачи. Изменения другой задачи не сохранятся.
При этом разработчикам следует учитывать, что механизм версионности сам по себе требует накладных расходов. При увеличении нагрузки (параллельно работающих транзакций) на сервер производительность версионного механизма начинает снижаться из-за частых обновлений, необходимых для поддержки различных версий данных.
- Доступ к базе данных Oracle средствами ADO.NET Entity Framework
При разработке программного обеспечения всегда руководствовался простым правилом, чем меньше в развивающемся проекте используется сторонних компонентов, платформ, технологий, тем лучше. Почти все гениальное - просто. К сожалению, у разработчика не всегда есть возможность свободного выбора средств и систем, с которыми он работает. Вот и мне достался проект Windows Forms + ODAC + Oracle DB Server.
- Мониторинг использования индексов в планах запросов в Oracle 10g
Для мониторинга использования индексов Oracle предлагает простой способ - включить мониторинг индекса и выключитьпо завершению значимого для данного индекса периода. Описание на сайте Oracle тут. В результате в представлении V$OBJECT_USAGE вы можете увидеть ответ "Yes" или "No".
- Экспорт - импорт БД oracle большого размера
Если вы читаете данную статью, то скорее всего Вас настигло несчастье. Экземпляр продуктивной БД доживает последние дни и вот вот перестанет вообще запускаться. Из RMAN-а вы восстановиться не можете, так как пользователи "наработали" достаточно большое количество данных, а архивные журналы с момента аварии безнадежно утеряны. Забегая вперед, отмечу, что с помощью ниже описываемого метода был произведен экпорт-импорт БД размером около 160GB за 18 часов.
|
| |
|
