ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / ASE 12.5.4 - стоит ли использовать большие курсоры
25 сообщений из 28, страница 1 из 2
  1  все
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476102
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
Всем добрый день.
Такой вопрос - загрузка данных - есть таблица источник и несколько таблиц получателей.
Источник состоит из 50 полей и может содержать до 100 000 записей.

Каждая запись из источника в цикле проходит некоторую проверку перед загрузкой в таблицы получатели.

Пытаюсь понять какой из 2 следующих вариантов лучше.

1. создать курсор только на ключи источника и далее в цикле обновлять получателей используя insert получатель select from источник where ключ = переменная ключа.
Подобным образом выполнять update from.

На 100 000 записей выходит 100 000 запросов к источнику.


2. создать курсор на все поля источника и потом в цикле просто фетчить их в переменные которые потом использовать для наполнения/обновления получателя.

Кажется, что этот вариант более быстрый, т.к. достаточно только 1 го запроса к источнику.

Но!
вместо 1 небольшого поля ключа, в курсоре будут все 50 полей - т.е. курсор выходит довольно здоровый (в смысле размера :-) )

Насколько ASE хорошо справляется с большими курсорами и не будет ли глюков?

И ещё вот такое соображение - вполне возможно, что в 1м варианте, сервер на этапе создания курсора с ключами, загрузит в память всю таблицу (даже если она и не привязана к выделенному буферу памяти) и тогда запросы будут выполняться без физического чтения, что по быстроте будет сопоставимо с использованием переменных.

В общем выходит что совершенно не очевидно какой из вариантов лучше.

Если у кого есть опыт работы с большими курсорами и с подобными задачами, поделитесь пожалуйста.

Заранее большое спасибо за отклик
...
Рейтинг: 0 / 0
17.02.2010, 19:39
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476121
antand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
antand
Гость
Kru,

Можно поподробнее про "некоторую проверку перед загрузкой"?
...
Рейтинг: 0 / 0
17.02.2010, 19:53
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476154
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
antandKru,

Можно поподробнее про "некоторую проверку перед загрузкой"?

Проверяется есть ли запись в получателе и потом соответственно выполняется insert или update.
Таблица источник, только читается.
Данные в ней не обновляются до следующей загрузки.
...
Рейтинг: 0 / 0
17.02.2010, 20:13
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476304
antand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
antand
Гость
Kru,

Так зачем тогда курсор, если можно одним запросом вставить все которых нет, в вторым обновить те которые уже есть таблице получателе?
...
Рейтинг: 0 / 0
17.02.2010, 22:22
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476377
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
antandKru,

Так зачем тогда курсор, если можно одним запросом вставить все которых нет, в вторым обновить те которые уже есть таблице получателе?

Дизайн БД так устроен, что для каждой вставляемой записи нужно при помощи специальной процедуры ключ получать. Поэтому одним запросом вставка не получится.
С обновлениями, тоже есть некоторые нюансы + при большом обновлении можно таблицу залочить.

Использование курсора - это неизбежная реальность.

Так что вопрос стоит какой курсор лучше использовать - широкий или узкий.
...
Рейтинг: 0 / 0
17.02.2010, 23:25
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476802
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

Есть общие правила, когда НЕОБХОДИМО использовать курсоры.
Это
когда записи обрабатываются в зависимости друг от друга
в каком-то порядке. (Например - проставить номер в возрастающем
порядке)

когда для обработки записей вызывается хранимая процедура

ну и возможно ещё какие-то РЕДКИЕ случаи.

Во всех остальных случаях, т.е. если не доказано, что
без курсора обойтись никак неьлзя, нужно использовать
запросы. Запросы просто быстрее и универсальнее.

В твоём случае я не вижу причин использовать курсоры.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.02.2010, 10:29
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476808
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

> И ещё вот такое соображение - вполне возможно, что в 1м варианте, сервер
> на этапе создания курсора с ключами, загрузит в память всю таблицу (даже
> если она и не привязана к выделенному буферу памяти) и тогда запросы

Сервер НИКОГДА специально не загружает в память всю таблицу.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.02.2010, 10:30
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36476819
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

> Дизайн БД так устроен, что для каждой вставляемой записи нужно при
> помощи специальной процедуры ключ получать. Поэтому одним запросом
> вставка не получится.

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

> С обновлениями, тоже есть некоторые нюансы + при большом обновлении
> можно таблицу залочить.

Используй DOL и настрой эскалацию блокировок, и всё будет ОК.

> Использование курсора - это неизбежная реальность.

Пока не видно.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.02.2010, 10:33
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36477026
antand
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
antand
Гость
Kru,

Оберни процедуру, которая дает ключ, в функцию и тогда можно получать ключ прямо в
insert .... select.....
Или, зная сколько записей вставлять, получи сразу все ключи и вставляй запросом уже без вызова процедуры.
...
Рейтинг: 0 / 0
18.02.2010, 11:35
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36477519
Mikle83
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mikle83
Участник
antandKru,
Оберни процедуру, которая дает ключ, в функцию и тогда можно получать ключ прямо в
insert .... select.....
Или, зная сколько записей вставлять, получи сразу все ключи и вставляй запросом уже без вызова процедуры.

Все б ничего, но в АСЕ 12.5.х функций нет...
Но можно переделать процедуру на работу не с одной записью, а на обработку датасета.

Вообщем я бы максимально старался уйти от курсоров...
...
Рейтинг: 0 / 0
18.02.2010, 13:37
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478274
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
Господа, всем большое спасибо за отклик,

Мне нужно писать процедуру именно в существующей среде и принять установленные в ней правила поэтому от цикла по записям уйти не получится.

Как я уже писал - ключи генерятся особой процедурой. База данных промышленная и просто так взять и заменить генератор ключей на identity никто не даст. Тоже самое в отношениии смены типа таблицы с APL на DOL.

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

Мне конечно, следовало об этом сразу написать, за что извиняюсь .

Можно действительно избежать именно курсора - просто добавить в промежуточную таблицу ещё одно поле со сквозной нумерацией - это не сложно сделать - и потом перебирать записиь по нему до тех пор пока не дойдёшь до конца.

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

Но! в данном случае как-то пугает арифметика - 100 000 запросов к таблице со 100 000 записей да ещё и 50 полей . Много читать придётся и при этом ещё что-то с диска!

Не будет ли более выгодным всё в курсор загнать?
Расчёт на то, что при заполнении курсора будет 100 000 чтений.
В случае же, с циклом, чтений будет значительно больше (пусть даже и по индексу).

Тоже вопрос - как ASE реально работает с курсорами ?
Будет ли он обязательно ждать окончания загрузки результата запроса в память или будет использовать подкачку, т.е. начнёт фетчить записи по мере их поступления и (т.к. он движется только вперёд), то возможно, что сразу после прочтения будет выкидывать записи из памяти (т.е. помечать память выделенную под эти записи как свободную и просто перезаписывать).

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

В общем, мне пока не очевидно, что в данной ситуации курсор это выигрышное или проигрышное решение.

Очень прошу помощи!

Заранее огромное спасибо
...
Рейтинг: 0 / 0
18.02.2010, 17:25
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478589
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
komrad
Участник
Kru

В общем, мне пока не очевидно, что в данной ситуации курсор это выигрышное или проигрышное решение.

Очень прошу помощи!

Заранее огромное спасибо

в общем, есть еще такой вариант:
начитать ID-шники записей в промежуточную таблицу
в цикле (не курсор!)
начало_цикла
по условию "пока есть запись в промеж.таблице":
- начитывать по одному (варианты: top x ; set rowcount 1)
- делать выборку из таблицы с параметром MRU ( ссылка - таким образом избавитесь от заполнения кэша данными из таблицы)
- обрабатывать начитанное согласно вашей процедуре
- удалять запись из промеж.таблицы с начитанным ID
конец_цикла

PS не уверен на счет top x в 12.5.4
...
Рейтинг: 0 / 0
18.02.2010, 19:24
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478590
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

> Очень прошу помощи!

ОК я вечером ещё вчитаюсь и подумаю.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.02.2010, 19:24
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478603
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

На некоторые всё же могу ответить сейчас.

> Тоже вопрос - *как ASE реально работает с курсорами*?

Быстро.

> Будет ли он обязательно ждать окончания загрузки результата запроса в
> память

Нет. Но в некоторых случаях может быть загрузка результатов в tempdb
в рабочую таблицу. Зависит от запроса.

или будет использовать подкачку, т.е. начнёт фетчить записи по
> мере их поступления и (т.к. он движется только вперёд),

Да, именно так и происходит. Про подкачку только не понял,
нет никакой подкачки.

то возможно, что
> сразу после прочтения будет выкидывать записи из памяти (т.е. помечать
> память выделенную под эти записи как свободную и просто перезаписывать).

Не будет, используется обычный механизм data cache. Если вытеснятся страницы
другими страницами, то они уйдут. Если нет - останутся.

Правда, этим можно управлять указывая стратегию использования кэша MRU/LRU.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.02.2010, 19:32
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478607
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
komrad
Участник
Kru
Но! в данном случае как-то пугает арифметика - 100 000 запросов к таблице со 100 000 записей да ещё и 50 полей . Много читать придётся и при этом ещё что-то с диска!

покажите
Код: plaintext
1.
sp_spaceused таблица
...
Рейтинг: 0 / 0
18.02.2010, 19:36
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478826
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
komradKru

В общем, мне пока не очевидно, что в данной ситуации курсор это выигрышное или проигрышное решение.

Очень прошу помощи!

Заранее огромное спасибо

в общем, есть еще такой вариант:
начитать ID-шники записей в промежуточную таблицу
в цикле (не курсор!)
начало_цикла
по условию "пока есть запись в промеж.таблице":
- начитывать по одному (варианты: top x ; set rowcount 1)
- делать выборку из таблицы с параметром MRU ( ссылка - таким образом избавитесь от заполнения кэша данными из таблицы)
- обрабатывать начитанное согласно вашей процедуре
- удалять запись из промеж.таблицы с начитанным ID
конец_цикла

PS не уверен на счет top x в 12.5.4

top x в 12.5.4 работает.
Цикл без курсора сделать не сложно и даже временную таблицу создавать не нужно.
(Ниже я привёл простой примерчик)
За подсказку про MRU большое спасибо - буду иметь ввиду на случай чрезмерного потребления памяти.
Но, всетаки цикл по записям подразумевает 100 000 запросов, и в этом то и основной вопрос - не лучше ли заменить его на курсор.

Ниже я привёл 2 варианта возможного решения.

Решение без курсора
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
-- создаем таблицу для примера
create table #test (i int, j int, y int)
go
-- индексируем
create unique nonclustered  index idx_tes on #test(i)
go
-- наполняем
declare @i smallint
select @i =  0 

while @i <  10 
begin
    select @i=@i+ 1 
    insert into #test
    values (@i, @i+ 10 , @i+ 20 ) -- произвольные значения для j и y
    
end

-- собственно сам пример
declare @i int, @j int, @y int, @i_max int
select @i =  1  ,  @i_max = max(i)+ 1  from #test -- выполняем запрос для определения диапазона ключей
while (@i <  @i_max)
begin
    select @j = j, @y = y from #test where i = @i --выполняем запрос на каждой итерации
    print "our variables: %1!, %2!, %3!", @i, @j, @y
    select @i = @i+ 1 
end
Решение с курсором
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
-- с таблицей созданной выше
declare c cursor for select * from #test
go
declare @i int, @j int, @y int, @i_max int
open c -- выполняем запрос только 1 раз
fetch c into @i, @j, @y -- далее только работаем с переменными.
while (@@sqlstatus= 0 )
begin
    print "our variables: %1!, %2!, %3!", @i, @j, @y 
    fetch c into @i, @j, @y
end 

close c
go

deallocate cursor c
go
...
Рейтинг: 0 / 0
18.02.2010, 23:05
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478829
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
komradKru
Но! в данном случае как-то пугает арифметика - 100 000 запросов к таблице со 100 000 записей да ещё и 50 полей . Много читать придётся и при этом ещё что-то с диска!

покажите
Код: plaintext
1.
sp_spaceused таблица

Самой таблицы и данных пока нет. Есть спецификация определяющая её структуру и ожидаемый объем данных.
...
Рейтинг: 0 / 0
18.02.2010, 23:06
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478830
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
MasterZiv
Kru wrote:

> Очень прошу помощи!

ОК я вечером ещё вчитаюсь и подумаю.


Большое спасибо
...
Рейтинг: 0 / 0
18.02.2010, 23:06
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478839
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

> 2. создать курсор на все поля источника и потом в цикле просто фетчить
> их в переменные которые потом использовать для наполнения/обновления
> получателя.
>
> Кажется, что этот вариант более быстрый, т.к. достаточно только 1 го
> запроса к источнику.

Конечно же это лучше. Вместо двух запросов будешь делать один.

> вместо 1 небольшого поля ключа, в курсоре будут все 50 полей - т.е.
> курсор выходит довольно здоровый (в смысле размера :-) )

Строки в ASE храняться построчно, как записи. Поэтому если читается хотя
бы одно поле НЕ из ключа -- читается ВСЯ запись. Поэтому нет смысла
что-то экономить.

Если делать в курсоре фетч только ключа, то
у тебя будет
0) позиционирование в индексе и фетч индексной записи (запись курсора)
1) позиционирование в индексе и фетч индексной записи, затем позиционирование
в таблице по ROWID и фетч записи данных.

Второй твой вариант:

0) позиционирование в индексе и фетч индексной записи, затем позиционирование
в таблице по ROWID и фетч записи данных.

> Насколько ASE хорошо справляется с большими курсорами и не будет ли глюков?

Глюков не будет, с большими справится. Но 100 тыщ -- это 100 тыщ, тут никуда
не деться. Если тебе всё это перепихивать надо в другую таблицу, то это будет
долго.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.02.2010, 23:15
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478849
Kru
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Kru
Участник
MasterZiv
Kru wrote:

На некоторые всё же могу ответить сейчас.

> Тоже вопрос - *как ASE реально работает с курсорами*?

Быстро.
Тогда может быть не так уж и плохо их использовать?

> Будет ли он обязательно ждать окончания загрузки результата запроса в
> память

Нет. Но в некоторых случаях может быть загрузка результатов в tempdb
в рабочую таблицу. Зависит от запроса.

или будет использовать подкачку, т.е. начнёт фетчить записи по
> мере их поступления и (т.к. он движется только вперёд),

Да, именно так и происходит. Про подкачку только не понял,
нет никакой подкачки.
Под подкачкой я имел ввиду ассинхронность загрузки - по аналогии с выводом записей на экран.
Записи отображаются, но запрос продолжает работать и добавлять новые записи.
Извиняюсь за неправильно использованный термин. Но ответ опять в пользу курсора. Обработка записей начинается сразу, не дожидаясь окончания запроса

то возможно, что
> сразу после прочтения будет выкидывать записи из памяти (т.е. помечать
> память выделенную под эти записи как свободную и просто перезаписывать).

Не будет, используется обычный механизм data cache. Если вытеснятся страницы
другими страницами, то они уйдут. Если нет - останутся.

Правда, этим можно управлять указывая стратегию использования кэша MRU/LRU.
Полезно знать про возможность MRU/LRU, в случае проблем с памятью.
Но если прочитанные страницы просто вытесняются, т.е. сервер их не удерживает, то скорее всего MRU/LRU даже и не понадобится.
Управление памятью, тоже в пользу курсора


В общем-то пока кажется, что курсор более хорошее решение чем цикл с запросами.
...
Рейтинг: 0 / 0
18.02.2010, 23:21
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36478982
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Kru wrote:

> Но если прочитанные страницы просто вытесняются, т.е. сервер их не
> удерживает, то скорее всего MRU/LRU даже и не понадобится.

Чаще всего стратегия именно LRU, т.е. накопление
(определяется она оптимизатором).

> В общем-то пока кажется, что курсор более хорошее решение чем цикл с
> запросами.

Это-то всегда да.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
19.02.2010, 01:56
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36479330
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
komrad
Участник
Kru
В общем-то пока кажется, что курсор более хорошее решение чем цикл с запросами.
для данной задачи - может быть
а в общем случае, при конкурентной работе с исходной таблицей, курсор всем остальным подгадит
...
Рейтинг: 0 / 0
19.02.2010, 10:26
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36479471
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
komrad wrote:

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

Погоди, это ж от запроса и таблицы зависит.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
19.02.2010, 11:20
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36479813
Фотография komrad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
komrad
Участник
MasterZiv
komrad wrote:

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

Погоди, это ж от запроса и таблицы зависит.

ага, поэтому написал что в общем случае...
лучше заранее напрячься и подумать, чем потом по живому разгребать ;)
...
Рейтинг: 0 / 0
19.02.2010, 13:05
| Ответить | Цитировать | Написать  
ASE 12.5.4 - стоит ли использовать большие курсоры
    #36480104
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
komrad wrote:

> ага, поэтому написал что в общем случае...
> лучше заранее напрячься и подумать, чем потом по живому разгребать ;)

Так запрос в курсоре и тот же запрос без курсора одинаковые блокировки
наложит (ну, почти одинаковые, там есть очень незначительные нюансы).
Правда, на потенциально разное время, но всё же я думал, что
что с курсором, что без, -- всё равно почти что для concurrency.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
19.02.2010, 14:36
| Ответить | Цитировать | Написать  
25 сообщений из 28, страница 1 из 2
  1  все
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / ASE 12.5.4 - стоит ли использовать большие курсоры
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=55&fpage=30&tid=2010730]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 45ms
get topic data:
 12ms
get forum data:
 2ms
get page messages:
 60ms
get tp. blocked users:
 2ms
others: 14ms
total:  163ms
созд. / загр.: 163ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]