ODBC driver для SQL 2000

Kon · Post by **Kon** » 02 Oct 2003 21:03

Кто нибудь знает если существует ODBC driver для SQL Сервера который бы поддерживал TRANSACTION ISOLATION LEVEL READ UNCOMMITTED?

Стандартный driver не имеет этой функции. Я знаю что Sybase driver поддерживает это, но они не гарантируют что Sybase и SQL 2000 совпадают.

tengiz · Post by **tengiz** » 02 Oct 2003 21:18

Имеет. См. MSDN Online - SQL Server 2000 - Adjusting Transaction Isolation Levels:

...ODBC applications call SQLSetConnectAttr with Attribute set to SQL_ATTR_TXN_ISOLATION and ValuePtr set to SQL_TXN_READ_UNCOMMITTED, SQL_TXN_READ_COMMITTED, SQL_TXN_REPEATABLE_READ, or SQL_TXN_SERIALIZABLE...

Не говоря уже о том, что можно просто вызвать SQLExec и выполнить "SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED".

Kon · Post by **Kon** » 02 Oct 2003 22:42

SQL_ATTR_TXN_ISOLATION нужно выставлять программатически. Я ни в код ни в SQL лезть не могу.

PeopleSoft соеденяется с SQLoм через System DSN который я создаю на сервере.
когда я создаю эту DSN то опции для выставления isolation level тaм нету.

Я пытался открывать DSN в notepad и добавлять
SQL_ATTR_TXN_ISOLATION =SQL_TXN_READ_UNCOMMITTED
или
READ_ISOLATION_LEVEL=RU
или
READ_ISOLATION_LEVEL= READ_UNCOMMITTED
но это не работает.

Поэтому я ищу где купить другой драйвер для SQLa.

VYLE · Post by **VYLE** » 03 Oct 2003 00:12

Kon wrote:PeopleSoft соеденяется с SQLoм через System DSN который я создаю на сервере.
когда я создаю эту DSN то опции для выставления isolation level тaм нету.

Я пытался открывать DSN в notepad и добавлять
SQL_ATTR_TXN_ISOLATION =SQL_TXN_READ_UNCOMMITTED
или
READ_ISOLATION_LEVEL=RU
или
READ_ISOLATION_LEVEL= READ_UNCOMMITTED
но это не работает.

Поэтому я ищу где купить другой драйвер для SQLa.

Если PeopleSoft сам программно устанавливает уровень изоляции, то Вам никакие настройки драйвера скорее всего не помогут.

SkyWalker · Post by **SkyWalker** » 03 Oct 2003 01:02

В System DSN этого прописать не получится. Этот параметр надо задавать атрибутом соединения на самом клиенте.

Насчет 3-rd party драйвера посмотрите вот это: http://www.datadirect-technologies.com

tengiz · Post by **tengiz** » 03 Oct 2003 01:31

Kon, если Вы хотите менять уровень изоляции по умолчанию для чужого написанного и отлаженного приложения, причём на READ UNCOMMITTED, то Вы серьёзно рискуете целостностью данных. Вы уверены, что это именно то, что Вам нужно?

Kon · Post by **Kon** » 03 Oct 2003 04:30

Для отчетов ето не повредит, мне нужно избавиться от постоянного blocking

tengiz · Post by **tengiz** » 03 Oct 2003 04:53

Kon wrote:Для отчетов ето не повредит, мне нужно избавиться от постоянного blocking

Вообще-то это повредит и отчётам тоже - Вы можете получите нарушение целостности на бумаге. Возможно очень важной и очень официальной. У Вас какой уровень поддержки от MS имеется? Может, Вас просто к правильным людям нужно направить?

Dmitry67 · Post by **Dmitry67** » 03 Oct 2003 08:42

Kon wrote:Для отчетов ето не повредит, мне нужно избавиться от постоянного blocking

Мне кажется это второй вопрос о тормозах отчетов PeopleSoft при работе с MS SQL изза blocking

Dmitry67 · Post by **Dmitry67** » 03 Oct 2003 08:44

А, вот
http://forum.privet.com/viewtopic.php?t=43963

Так ничего сделать и не удалось ?

P.S. SQL server 2003 со snapshots спасет отца русской демократии

А пока можно сделать transaction log backup во вторую базу и отчеты запускать там

zVlad · Post by **zVlad** » 03 Oct 2003 12:43

Кстати, ODBC driver for DB2 имеет такую возможность конфигурирования. Я имею в виду уровень изоляции. И это совершенно нормально и понятно. Дело видимо в том что в программировании для DB2 принято пользоваться умолчанием для уровня изоляции, который затем устанавливается (меняется внешним образом), а также возможностью устанавливать уровень явно, но на уровне отдельного оператора. Типа:

Select ... from .... WITH UR

Кстати, мистер Коn, я тут на Вас ссылался когда мы обсуждали замену реплики для репортинга на прямой доступ к продакшн базе. Я был против, но вспомнив что Вы писали как Вам удалось настройками выкрутиться, я все таки присоединился к этому течению. Не надо конечно понимать то что я сказал буквально. Я и когда соглашался не очень то в это верил, но уж очень хочется уйти от репликации в MS SQL базу (до этого у нас был Oracle для реплики - тоже не подарок, но как то поспокойней было) - а там бы разобрались что делать и кто виноват.
Выходит у Вас, Kon, не все так безоблачно как мне казалось.
Совершенно солидарен с Tengiz - так произвольно играть с уровнем изоляции недело, а тогда остается репликация?
:pain1:

Что Tengiz скажет ?

Kon · Post by **Kon** » 03 Oct 2003 20:20

Настройки действительно помогли, и на сегодняшний день я сплю спокойно, но у начальства есть планы купить добавочные модули к PeopleSoft и соответственно увеличить количество пользователей в 3 раза.

Я боюсь что с планируемым обьемом работы мои настройки перестанут помогать. Пользователи и PeopleSoft согласились что некоторые отчеты можно без проблем читать и с dirty reads. Для етих отчетов я и построил реплицированую базу на другом сервере. Но репликация с exclusive locks постоянно воюует с shared locks от отчетов.

Я только что повесил трубку после общения с PeopleSoftом. Оказывается они официально поддерживают dirty reads для ограниченных отчетов. Их способ это создать views типа "select * from table kaka (nolock)".

zVlad · Post by **zVlad** » 03 Oct 2003 23:45

Kon wrote:..... Пользователи и PeopleSoft согласились что некоторые отчеты можно без проблем читать и с dirty reads. Для етих отчетов я и построил реплицированую базу на другом сервере. Но репликация с exclusive locks постоянно воюует с shared locks от отчетов.....

Ну вот Вы меня опять озадачили

разве dirty read-у нужен какой-либо lock? Откроюсь сразу - в DB2 dirty read не запрашивает никаких lock-ов. Что-то Вы все мое понимание этих проблем пермешали. Вы ранее выяснили, что репликация может спасти онлайн процессинг от дэдлоков, но если оставить репортинг как есть (те без dirty read) то репортинг будет наезжать на репликацию и наоборот. Dirty же read спасет всех и без репликации ценой, может быть (как выяснилось) неправильных данных в отчетах.
Укажите, что я не правильно излагаю.

Kon · Post by **Kon** » 04 Oct 2003 14:36

zVlad,
вы абсолютно правы.
Репликация была поставлена что бы снять часть нагрузки (CPU/IO/память) c transactional базы.

zVlad · Post by **zVlad** » 04 Oct 2003 14:55

Kon wrote:zVlad,
вы абсолютно правы.
Репликация была поставлена что бы снять часть нагрузки (CPU/IO/память) c transactional базы.

Я вроде бы о нагрузке ни слова не говорил. Мы же вроде бы о concurency миркуем. :pain1:

tengiz · Post by **tengiz** » 04 Oct 2003 16:28

Kon wrote:Но репликация с exclusive locks постоянно воюует с shared locks от отчетов.

Какая у Вас точно модель репликации?

Я только что повесил трубку после общения с PeopleSoftом. Оказывается они официально поддерживают dirty reads для ограниченных отчетов. Их способ это создать views типа "select * from table kaka (nolock)".

И что, в их системе изначально присутствуют такие view или пользователь самостоятельно может вносить эти изменения (nolock hint) при необходимости?

Я боюсь что с планируемым обьемом работы мои настройки перестанут помогать. Пользователи и PeopleSoft согласились что некоторые отчеты можно без проблем читать и с dirty reads. Для етих отчетов я и построил реплицированую базу на другом сервере.

Это очень интересно смотрится - при разрешённых грязных чтениях, в отчёты попадут данные от незавершённых транзакций. В том числе и от тех, которые впоследствии окажутся откаченными. В итоге отчёт будет содержать сведения, которых никогда бы не было в согласованной базе данных.

Dmitry67 · Post by **Dmitry67** » 04 Oct 2003 16:35

Уж лучше тогда readpast
тоже хрень но поменьше

zVlad · Post by **zVlad** » 04 Oct 2003 16:38

tengiz wrote:
Kon wrote:Но репликация с exclusive locks
.........
Это очень интересно смотрится - при разрешённых грязных чтениях, в отчёты попадут данные от незавершённых транзакций. В том числе и от тех, которые впоследствии окажутся откаченными. В итоге отчёт будет содержать сведения, которых никогда бы не было в согласованной базе данных.

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

Dmitry67 · Post by **Dmitry67** » 04 Oct 2003 16:52

zVlad wrote:
tengiz wrote:
Kon wrote:Но репликация с exclusive locks
.........
Это очень интересно смотрится - при разрешённых грязных чтениях, в отчёты попадут данные от незавершённых транзакций. В том числе и от тех, которые впоследствии окажутся откаченными. В итоге отчёт будет содержать сведения, которых никогда бы не было в согласованной базе данных.

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

Если отчет за прошедшие даты то и блокировок от OLTP особо быть не должно... Хотя... если читаются почти все записи (OLAP например), и идет full table scan (так как почти все записи) то как раз dirty read будет нормальным решением

zVlad · Post by **zVlad** » 04 Oct 2003 17:46

Dmitry67 wrote:
zVlad wrote:
tengiz wrote:
Kon wrote:Но репликация с exclusive locks
.........
.

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

Если отчет за прошедшие даты то и блокировок от OLTP особо быть не должно... Хотя... если читаются почти все записи (OLAP например), и идет full table scan (так как почти все записи) то как раз dirty read будет нормальным решением

А вот и нет, Dmitry67, попробуй залочить запись с DATE_FIELD = CURRENT DATE, и выполнить запрос SELECT * FROM tttt WHERE DATA_FIELD < CURRENT DATE with and without "nolock" hint. И так ясно что запросу захочется посмотреть ту запись, которая залочена - а вдруг она подходит или будет подходить по завершении транзакции залочившей ее. Ведь так?

Dmitry67 · Post by **Dmitry67** » 04 Oct 2003 17:52

zVlad wrote: А вот и нет, Dmitry67, попробуй залочить запись с DATE_FIELD = CURRENT DATE, и выполнить запрос SELECT * FROM tttt WHERE DATA_FIELD < CURRENT DATE with and without "nolock" hint. И так ясно что запросу захочется посмотреть ту запись, которая залочена - а вдруг она подходит или будет подходить по завершении транзакции залочившей ее. Ведь так?

Так я это и говорю
Проверить то он ее проверит
Но тут нас спасет от ожидания hint (nolock) или (readpast)
А на consistecy отчета это не повлияет потому что мы предполагаем что все изменения происходят СЕГОДНЯ а отчет строим за все дни кроме сегодня
То есть тут dirty read реально поможет

tengiz · Post by **tengiz** » 04 Oct 2003 19:08

zVlad wrote:Это могут быть статистические отчеты, или отчеты за прошедшие периоды тогда как OLTP имеет дело с текущей датой например. Для чего ведь грязное чтение было создано, а так получается возможность есть, но пользоваться ей никак нельзя.

Dmitry67 wrote:А на consistecy отчета это не повлияет потому что мы предполагаем что все изменения происходят СЕГОДНЯ а отчет строим за все дни кроме сегодня. То есть тут dirty read реально поможет

Вы что, господа, шутите что-ли? Если на согласованность отчёта грязное чтение не влияет, это означает, что читателя с писателем на самом деле можно развести по данным. "Цена вопроса" в ваших примерах - правильный индекс по дате. И никакого грязного чтения не нужно. Не говоря уже о том, что такой индекс здесь полезен даже безотносительно к блокировкам.

Kon · Post by **Kon** » 04 Oct 2003 22:49

Какая у Вас точно модель репликации?

Transactional

И что, в их системе изначально присутствуют такие view или пользователь самостоятельно может вносить эти изменения (nolock hint) при необходимости?

Views нужно создавать в ручную, а потом заменять названия таблиц на views.

Относится это только к historical data. Также, пользователи понимают (и согласны) что это point-in-time отчеты, и к тому времени когда отчет лежит у них на столе цифры могут быть уже другими.

Dmitry67 · Post by **Dmitry67** » 06 Oct 2003 07:57

tengiz wrote:Вы что, господа, шутите что-ли? Если на согласованность отчёта грязное чтение не влияет, это означает, что читателя с писателем на самом деле можно развести по данным. "Цена вопроса" в ваших примерах - правильный индекс по дате. И никакого грязного чтения не нужно. Не говоря уже о том, что такой индекс здесь полезен даже безотносительно к блокировкам.

tengiz !

Итак, если у нас есть table sales, 1'000'000 rows с полем SaleDate datetime
И мы строим отчет по всем закрытым периодам
select count(*) from Sales where SaleDate<'20031001' = 998000 rows
тогда как в октябре
select count(*) from Sales where SaleDate>='20031001' = 2000 rows

то какой план выберет SQL для выбора 998000 записей ? Правильно, full table scan. И напорется на блокировку

tengiz · Post by **tengiz** » 06 Oct 2003 19:37

Dmitry67 wrote:...то какой план выберет SQL для выбора 998000 записей ? Правильно, full table scan. И напорется на блокировку

Ну-ну. А если всё-таки чуть-чуть подумать и сделать правильный индекс, как я уже писал, а не абы какой?

Привет

ODBC driver для SQL 2000

ODBC driver для SQL 2000

Re: ODBC driver для SQL 2000