Oracle10g на Линухе - быстрее всех!

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 15:25

А как кастати в DB2 с UNICODE ?

zVlad · Post by **zVlad** » 04 Mar 2004 16:08

We have problem with cases in replication product, which does uniform works for all of hundreds of tables: it generates UPDATE or DELETE statements like, for example:

DELETE FROM tab1 where c1='Ftype' (becasuse in DB2 rows with c1='Ftype' were deleted). The same time other rows are existing with c1='FTYPE' on both DB2 and MS SQL sites. MS SQL deletes all rows with either 'Ftype' or 'FTYPE'. Then someone updates in DB2 rows with c1="FTYPE" - replication stuff on MS SQL issues: "Where clause does not match any rows." We are in trouble.

What would you recommend here?

How would you comment this:

"...assuming there is a record with PK = 'W123P',

INSERT INTO <the table> (PK, ...) VALUES ('W123p', ...) will fail because SQL Server considered they are the same, the side-effect of "case-insentive" code page.

UPDATE <the table> SET PK = 'W123p' WHERE PK = 'W123p' will change 'W123P' to W123p' because the where clause can find the record."

Above was a part of our investigation of problem happened with replication from DB2 to MS SQL. Above was provided to us from MS SQL guy, who knows MS SQL for sure. It was in 2002. Maybe things are changed since there. I don't know.
I am totally confused hearing about case sensetive, and case insensetive in relation to information, to DATA. There are no rules other than direct comparison of codes, and 'a' should never been considerated to be equival to 'A' in either circumstances. NEVER. Those pieces of DATA are ALWAYS different.

zVlad · Post by **zVlad** » 04 Mar 2004 16:12

Dmitry67 wrote:А как кастати в DB2 с UNICODE ?

As I know, UNICODE is supported in DB2 as it could be expected and desired. Ver. 8 DB2 catalog itself is in UNICODE.

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 16:26

zVlad wrote:We have problem with cases in replication product, which does uniform works for all of hundreds of tables: it generates UPDATE or DELETE statements like, for example:

DELETE FROM tab1 where c1='Ftype' (becasuse in DB2 rows with c1='Ftype' were deleted). The same time other rows are existing with c1='FTYPE' on both DB2 and MS SQL sites. MS SQL deletes all rows with either 'Ftype' or 'FTYPE'. Then someone updates in DB2 rows with c1="FTYPE" - replication stuff on MS SQL issues: "Where clause does not match any rows." We are in trouble.

What would you recommend here?

How would you comment this:

"...assuming there is a record with PK = 'W123P',

INSERT INTO <the table> (PK, ...) VALUES ('W123p', ...) will fail because SQL Server considered they are the same, the side-effect of "case-insentive" code page.

UPDATE <the table> SET PK = 'W123p' WHERE PK = 'W123p' will change 'W123P' to W123p' because the where clause can find the record."

It was part of our investigation of problem happened with replication from DB2 to MS SQL.
I am totally confused hearing about case sensetive, and case insensetive in relation to information, to DATA. There are no rules other than direct comparison of codes, and 'a' should never been considerated to be equival to 'A' in either circumstances. NEVER. Those pieces of DATA are ALWAYS different.

Если Вы можете менять саму базу то я бы ее переделал на case-sensitive
Если же это не ваш продукт и Вы не имеете права менять такие вещи то тогда возникает противоречие - продукт третьей фирмы тредует чтобы база была case-insensitive, а репликатор чтобы была caase-sensitive... Тут не знаю что посоветовать
Какой из случаев в данном случае ?

zVlad · Post by **zVlad** » 04 Mar 2004 16:32

Dmitry67, you mean that our MS SQL guys could re-create database and make it works like DB2 does, and 'a' would be never the same as 'A'. If your answer definatelly 'Yes' then I don't understand why our MS SQL guys still don't tell us about it. Just few weeks ago I was involved in data change we did to fix that case problem, and I saw myself SQL Server worked as case-insensetive product. We desire to have SQL Server be case-sensetive for long long time.

Merle · Post by **Merle** » 04 Mar 2004 16:33

zVlad wrote: What would you recommend here?

Сходу можно предложить два варианта.
1. "радикальный": Изменить столбец "c1" с явным указанием COLLATION, в названии которого присутствует .._CS_.. - Case Sencitive. Например, Latin1_General_CS_AI.
Не подходит, в том случае, если есть другие запросы, которые рассчитывают на то, что значение не чуствительно к регистру.

2. Указать нужный COLLATION прямо в запросе.
DELETE FROM tab1 where c1 COLLATE Latin1_General_CS_AI = 'Ftype'

Вот, рабочий пример:

Code: Select all

create table #er (c1 nvarchar(200))
GO

insert into #er (c1) values('aaaAA')

--- удаляем с учетом регистра
---
DELETE FROM #er where c1 COLLATE Latin1_General_CS_AI = 'aaaaa' 
--- 0 rows affected

--- удаляем без учета регистра
---
DELETE FROM #er where c1 COLLATE Latin1_General_CI_AI = 'aaaaa'
--- 1 rows affected

То же самое и со всеми остальными Вашими задачками.

zVlad · Post by **zVlad** » 04 Mar 2004 16:51

Thank you, guys. I have submitted question to our MS SQL people. Waiting for respond.

zVlad · Post by **zVlad** » 04 Mar 2004 17:14

To Merle. While I am waithing for respond from our SQL people, I think none of what you recommended could be helpful in our case. Imagine, there are hundreds of tables which we have to replicate from DB2 to SQL Server. Software we are using is multi-platform, and inter-platform. Vendor name was BMC, then Striva, and finally now it is "Informatica". So it is impossible to change names of columns (thousands of columns). It is also difficult to figure out when COLLATE must be applied in SQL statement, you know, SQL statements are generated on fly. In uniform fashion.
I went to SQL Server Enterprise Manager, I tried to create table with case sensitive column data type. There is nothing there to specify it :pain1:

Do you mean it works somehow if one creates column with special name conventions?

Also I looked at database properties, and I did't see anything related to case sensitivity there.

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 18:44

2 zVlad
Я тоже люблю болешь case sensitive
Но по умолчанию если поставить то он будет case-insensitive
sensitivety задается

1 для всего сервера при инсталляции
2 при создании базы (но если collation базы не совпадает с collation сервера то могут быть сюрпризы с временными таблицами)
3 Наконец при создании каждой таблицы и колонки

collаtion базы и сервера есть точно в enterprise, просто вы наверное ищете слова case sensitivity а надо искать collation
таблицы из Enterprise я не создаю и не помню есть ли тамcollation
В create table разумеется есть

Учтите что если базу перелить и изменить collation то нкторе ператоры SQL могут перестать быть синтактически коррекными по оняным причинам то есть продукт может перестать работать

vc · Post by vc » 04 Mar 2004 18:52

zVlad,

zVlad wrote:To Merle. While I am waithing for respond from our SQL people, I think none of what you recommended could be helpful in our case. Imagine, there are hundreds of tables which we have to replicate from DB2 to SQL Server. Software we are using is multi-platform, and inter-platform. Vendor name was BMC, then Striva, and finally now it is "Informatica". So it is impossible to change names of columns (thousands of columns). It is also difficult to figure out when COLLATE must be applied in SQL statement, you know, SQL statements are generated on fly. In uniform fashion.
I went to SQL Server Enterprise Manager, I tried to create table with case sensitive column data type. There is nothing there to specify it Do you mean it works somehow if one creates column with special name conventions?

Also I looked at database properties, and I did't see anything related to case sensitivity there.

If you have a SQL SERVER 2000, you can make a in the table case-sensitive even if the whole installation is case-insensitive.

E.g.:

Code: Select all

create table t1(x varchar(10) collate SQL_Latin1_General_Cp437_CS_AS primary key)

---collate SQL_Latin1_General_Cp437_CS_AS defines it as case sensitive

VC

vc · Post by vc » 04 Mar 2004 19:01

zVlad wrote:To Merle. While I am waithing for respond from our SQL people, I think none of what you recommended could be helpful in our case. Imagine, there are hundreds of tables which we have to replicate from DB2 to SQL Server. Software we are using is multi-platform, and inter-platform. Vendor name was BMC, then Striva, and finally now it is "Informatica". So it is impossible to change names of columns (thousands of columns). It is also difficult to figure out when COLLATE must be applied in SQL statement, you know, SQL statements are generated on fly. In uniform fashion.
I went to SQL Server Enterprise Manager, I tried to create table with case sensitive column data type. There is nothing there to specify it Do you mean it works somehow if one creates column with special name conventions?

Also I looked at database properties, and I did't see anything related to case sensitivity there.

Forgot to mention ...

This statement will create a case-sensitive _database_:

Code: Select all


CREATE DATABASE myDB
COLLATE SQL_Latin1_General_Cp437_CS_AS
ON PRIMARY
( NAME = myDB_dat,
   FILENAME = 'd:\program files\microsoft sql server\mssql\data\myDb_dat.mdf',
   SIZE = 10,
   MAXSIZE = UNLIMITED,   
   FILEGROWTH = 5 )
LOG ON
( NAME = myDb_log,
   FILENAME = 'd:\program files\microsoft sql server\mssql\data\myDb_log.ldf'
   SIZE = 5,
   MAXSIZE = UNLIMITED,
   FILEGROWTH = 2 )

Of course, you would use appropriate paths for the files.
VC

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 19:12

При создании базы в Enterpise есть такая штучка куда давить чобы изменить case-sensitivity

vc · Post by vc » 04 Mar 2004 19:12

zVlad wrote:To Merle. While I am waithing for respond from our SQL people, .. Also I looked at database properties, and I did't see anything related to case sensitivity there.

Also:

Code: Select all



-- to find out the database collation (the database name is test):
select convert(sysname,DatabasePropertyEx('test','Collation'));

-- to change the db collation:
alter database test collate <whatever>;

-- to find out all the column collations in a table:
select name, collation from syscolumns where id=object_id('t1')

-- to change the collation for a column:
alter table t1 alter column c1 char(10) COLLATE <whatever>

VC

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 19:19

2 vc
Я сейчас проверить не могу
Но мне кажется что изменить collation у колонки по которой создан индекс так посто не удасться
Или можно ? Я не пробовал
Аналогичо интересно провеить что будет пи изменеии collation базы CS -> CI, если в базе есть таблицы A и a

zVlad · Post by **zVlad** » 04 Mar 2004 19:42

On my question:

"...why don't change it to case sensitive? Like we have in DB2."

our SQL Server guy answered:

"...will be performance hit to the database. using UCase(..) will force SQL Server to scan the table rather than utilizing indexes. and more problem with table joins."

I don't really undestand what he meant saying "...and more problem with table joins". But what I know now that dispite the fact that our replication problem could be fixed by using case sensitive it will never be possible to have because of other issues would happen if we do it.
Forget about it.

tengiz · Post by **tengiz** » 04 Mar 2004 20:05

zVlad wrote:On my question:

"...why don't change it to case sensitive? Like we have in DB2."

our SQL Server guy answered:

"...will be performance hit to the database. using UCase(..) will force SQL Server to scan the table rather than utilizing indexes. and more problem with table joins."

zVlad, по этим обрывкам информации непонятно вообще в чём была исходная проблема. Переход на case insensitive, напротив, немного поднимет производительность, так как сравнение символов будет делаться двоичное, а не через таблицы, поэтому те проблемы о которых они пишут - это проблемы проектирования и реализации, а платформа тут не при чём. ucase для joins использовать не нужно, при условии, что DRI сделана правильно. В общем, я так и не понял, в чём исходная проблема и почему при collation по умолчанию не удаётся с ней справиться. Единственное, что может быть помехой - если репликация делается из case-sensitive системы и case-insensitive система обнаруживает нарушения уникальности. Но - это проблема дурного проектирования приложения. Причём, именно того, которое case-sensitive. Во времена SQL Server 4.2 (1994) всё было совсем наоборот - binary sort order, используемый им по умолчанию, был крайне неудобен для большинства обычных случаев. Современные умолчания (dictionary sort order) при наличии гибкости регулировать collation на уровне отдельной колонки - гигантский шаг вперёд.

flip_flop · Post by **flip_flop** » 04 Mar 2004 20:08

tengiz wrote:
flip_flop wrote:...Алаверды - Почему?

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

Тенгиз,
Следствие неизбежной избыточности проявляется в силиконе по всем статьям - площади, потребляемой мощности, быстродействию, стоимости. Лет десять назад проигрыш выражался и в 10 и в 100 раз. Однако сейчас положение выравнивается. Кроме того комплексные решения (от Xilinx, например) являются гетерогенными - ядро FPGA и тщательные custom IP (IO, processors, memory, serial links). Последние новости от Xilinx и Алтера впечатляют. Дискуссии ASIC vs FPGA vs "DSP/controllers/conventional processors" не утихают. Вот старая (1999), но IMHO хорошая ссылка: http://brass.cs.berkeley.edu/documents/rc_dac99.html

По вопросу "mainstream" я не знаю по всем областям. Однако использование FPGA в DSP и embedded systems мне кажется недостаточным - предпочитают обычные kонтроллеры и/или программируемюе DSP процессоры, хотя умелое воплощение алгоритмов в FPGA может повысить еффективность на порядки. К тому же методы проектирования FPGA приближаютса ближе к программированию - дизайнер может быть из области computer science, в отличие от chip design.

Дисклаймер: Вышеприведенные положения к вопросу о FPGA и "mainstream" являются всего лишь частным мнением человека, "вышедшего погулять" в новую интересную область (то бишь дилетанта) и могут не отражать действительного положения вещей.
Так что учитывая моё невежество в этой области, я осмелюсь продолжить этот тост за здравие всех дилетанствующих

Алаверды?

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 20:15

Я согласен с tengiz
Похоже что ваши SQL guys ищут excuse чтобы этого не делать
ucase при верно описанном collation у колонок не нужен вообще

vc · Post by vc » 04 Mar 2004 20:16

Dmitry67 wrote:2 vc
Я сейчас проверить не могу
Но мне кажется что изменить collation у колонки по которой создан индекс так посто не удасться
Или можно ? Я не пробовал
Аналогичо интересно провеить что будет пи изменеии collation базы CS -> CI, если в базе есть таблицы A и a

No, you cannot change the collation for an indexed column unless you drop the index

Yes, you can change the db collation regardless of the table name case.

By the way, the table name case-sensitivity (introduced by a case-sensitive collation) is contrary to the '92/'99 statndards.

VC

tengiz · Post by **tengiz** » 04 Mar 2004 20:19

zVlad wrote:но если вы о микропрограммировании процессоров, то в тех мэйнфрэйм это уже давно используется. Я имею в виду микропрограммное изменение логики работы процессора. Если к примеру обнаруживается ошибка на этом уровне, то процессор менять не нужно - нужно лишь перезагрузить память микропрограмм. Еще это используется для расширения набора команд процессора, например, командами совсем другого процессора. К командам процессора мэйнфрэйм можно было добавить команды Минск-32.

Нет, мы говорили о другом. Речь шла о технологии программируемых логических устройств: это некая болванка, в которой изначально отсутствует какой-либо глубокий смысл. Она исходно представляет из себя набор логических элементов, регистров и пр. россыпью, между которыми в результате электрического "программирования" делаются "соединения". В итоге получается узкоспециализированное устройство в точности соответствующее Вашим нуждам. Например, можно из "болванки" путём "прошивки" сделать полноценный z80 или, скажем, контроллер флоппи диска. Т.е. вместо сложного и дорогого цикла проектирования и изготовления "обычных" интегральных схем, для которого требуется целый завод, небольшая фирма может для себя изготовить мелкую серию нужных ей устройств.

В общем, отличие от микропрограммирования здесь в том, что "программа" в конечном счёте трансформируется не в набор команд, а в электрические связи между элементами на кристалле.

Вроде я нигде не наврал. А если наврал, flip_flop и dB13 меня поправят.

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 20:22

И что же будет с двумя таблицами A и a ?
А что кстати говорит стандарт о case-sensitivity имен колонок (не таблиц) и данных ?

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 20:25

"Я об этом тоже догадался. Только немного раньше Вас" (c) Принц Флоризель
В смысле мне такая идея по поводу процессоров тоже приходило в голову
В частности приходило в голову что 99% времени приходитя на крошечный самый самый вложенный цикл который можно запогрммировать в таком железном виде и все будет просто летать

flip_flop · Post by **flip_flop** » 04 Mar 2004 20:28

tengiz wrote:
zVlad wrote:но если вы о микропрограммировании процессоров, то в тех мэйнфрэйм это уже давно используется. Я имею в виду микропрограммное изменение логики работы процессора. Если к примеру обнаруживается ошибка на этом уровне, то процессор менять не нужно - нужно лишь перезагрузить память микропрограмм. Еще это используется для расширения набора команд процессора, например, командами совсем другого процессора. К командам процессора мэйнфрэйм можно было добавить команды Минск-32.

Нет, мы говорили о другом. Речь шла о технологии программируемых логических устройств: это некая болванка, в которой изначально отсутствует какой-либо глубокий смысл. Она исходно представляет из себя набор логических элементов, регистров и пр. россыпью, между которыми в результате электрического "программирования" делаются "соединения". В итоге получается узкоспециализированное устройство в точности соответствующее Вашим нуждам. Например, можно из "болванки" путём "прошивки" сделать полноценный z80 или, скажем, контроллер флоппи диска. Т.е. вместо сложного и дорогого цикла проектирования и изготовления "обычных" интегральных схем, для которого требуется целый завод, небольшая фирма может для себя изготовить мелкую серию нужных ей устройств.

В общем, отличие от микропрограммирования здесь в том, что "программа" в конечном счёте трансформируется не в набор команд, а в электрические связи между элементами на кристалле.

Вроде я нигде не наврал. А если наврал, flip_flop и dB13 меня поправят.

Все верно. Только вместо "обычных" я бы поставил "специализированных" (программисты любят жаргонное словечко "заточенные") и то скорее в эмоциональном контексте - называть некоторые шедевры "обычными" не представляется возможным :wink:

tengiz · Post by **tengiz** » 04 Mar 2004 20:46

Dmitry67 wrote:В частности приходило в голову что 99% времени приходитя на крошечный самый самый вложенный цикл который можно запогрммировать в таком железном виде и все будет просто летать

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

Dmitry67 · Post by **Dmitry67** » 04 Mar 2004 20:57

tengiz, замчатеьня история
а Вы подумайте какие перспективы открываются с помщью таких спецпроцессоров или с помью мссивнопарралельных структур
Наприе каждый элемент такой матрицы мжет проверять like pattern своегодесятка записей
В итоге имеет full table scan по like 'some complicated pqttern' в течение микросекунд
А есть ли увас там ребята которые занимаются подобными вещами, то есть удаленными от внедреия мжет на десятки лет ? или просто потом скупаются интересные идеи на корню ?