execute statement
execute statement
Значит так в процедуре сначала идет:
execute statement 'create table A (...)';
а потом идет
execute statement 'insert into table A (...)values(...)';
и вот при запуске процедуры на инсерт ругается Table unknown.
Что нужно сделать чтобы не ругалось?
execute statement 'create table A (...)';
а потом идет
execute statement 'insert into table A (...)values(...)';
и вот при запуске процедуры на инсерт ругается Table unknown.
Что нужно сделать чтобы не ругалось?
Re: execute statement
прекратить вызывать DDL в Execute Statement. Зачем такие извраты?Что нужно сделать чтобы не ругалось?
Re: execute statement
мне нужно создавать контрольные точки состояния таблицы на дату(то есть там будет А_01012010) и складывать все в одну таблицу вариант не подходит.
Я так понимаю эту проблему можно обойти только так: создание таблицы запихнуть в одну процедуру, а инсерты в другую.
Или же акие извраты можно как-то вместе выполнить?
Я так понимаю эту проблему можно обойти только так: создание таблицы запихнуть в одну процедуру, а инсерты в другую.
Или же акие извраты можно как-то вместе выполнить?
Re: execute statement
почему нельзя создать таблицу с клиента?
правильно сортируется только японский формат даты - yyyymmdd, а не та фигня, что Вы написали. Рекомендую поменять, пока не поздно.таблицы на дату(то есть там будет А_01012010)
Re: execute statement
Посмотрели, подумали и решили, что наверное правильнее будет разбить на 2 процедуры.
За дату спасибо. Тему можно закрыть. Чет не могу найти где ее закрыть
За дату спасибо. Тему можно закрыть. Чет не могу найти где ее закрыть
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: execute statement
По религиозным мотивам?nevadimka писал(а):складывать все в одну таблицу вариант не подходит.
Re: execute statement
не парьтесь. темы закрывают тут только модераторы. и лично я темы действительно закрываю очень редко.Тему можно закрыть. Чет не могу найти где ее закрыть
Насчет глубокого смысла с разделением данных по таблицам советую подумать. "Состояние таблицы на дату" это весьма странная идея. Обычно если в данных интересует дата, то дата уже является столбцом таблицы. А с размерами таблиц у ФБ проблем нет.
Re: execute statement
Проблема в том что прибольших обьемах таблицы вставка в нее замедляется и решили сделать архивную, чтобы боевая таблица была все время небольшого размера. И когда она выростает перекидывать данные в архивную. И какбы что бы после такого получить результат, процес выглядит следующим образом: дропаем индексы, переносим инфо, делаем бекап/рестор, создаем индексы. А это по времени очень долго и производственый процесс стоит. По-этому решили делать много таблиц. Я против, заказчик требует))
Пробовал почитать вашу статью http://www.ibase.ru/devinfo/fb1tbtech.htm, чтобы привести хоть какие-то аргументы против, но тяжело воспринимается. Может вы свои мысли напишите на такой вот случай:
Таблица А - размер около 50Гб и таблица Б - размер припустим 1Гб
и нужно вставить 1млн записей, какой приблизительно будет выигрыш во времени привставке в таблицу Б
Пробовал почитать вашу статью http://www.ibase.ru/devinfo/fb1tbtech.htm, чтобы привести хоть какие-то аргументы против, но тяжело воспринимается. Может вы свои мысли напишите на такой вот случай:
Таблица А - размер около 50Гб и таблица Б - размер припустим 1Гб
и нужно вставить 1млн записей, какой приблизительно будет выигрыш во времени привставке в таблицу Б
Re: execute statement
1. что значит "большие объемы"?Проблема в том что прибольших обьемах таблицы вставка в нее замедляется
2. насколько замедляется?
причин замедления может быть несколько - большое количество индексов, select или вызовы процедур в триггерах на вставку, check constraints в виде select, и т.д.
Попытайтесь изложить условия задачи максимально полно, т.к. непонятно, что Вы делаете, и как получается.
ужас.дропаем индексы, переносим инфо, делаем бекап/рестор, создаем индексы.
никакой, если на этих таблицах не будет всякого шлака, о котором я написал выше. В плохо разработанной БД, например, если в триггере на вставку есть select, производительность вставки может замедляться пропорционально количеству записей. Я теоретизирую, потому что все зависит от этого select.и нужно вставить 1млн записей, какой приблизительно будет выигрыш во времени привставке в таблицу Б
Поэтому такие таблицы, в которые вставляется масса данных, должны быть вычищены от любых действительно замедляющих действий.
гм, что тяжело воспринимается? статья написана предельно простым языком, да и весь тест проще некуда.но тяжело воспринимается.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: execute statement
Не совсем так. Pointer pages при поиске места под вставку сканируются последовательно. Так что если в таблицу идут только вставки и никогда - удаления, то время вставки будет расти с увеличением таблицы. Я бы от балды назвал цифру в 10-20%. Тут многое зависит от размера записи, размера страницы, нагрузки и т.д. и т.п.kdv писал(а):никакой, если на этих таблицах не будет всякого шлака, о котором я написал выше.и нужно вставить 1млн записей, какой приблизительно будет выигрыш во времени привставке в таблицу Б
Re: execute statement
Не нужно делать непроверенных и неправильных утверждений. Тем более от балдыDimitry Sibiryakov писал(а):Pointer pages при поиске места под вставку сканируются последовательно. Так что если в таблицу идут только вставки и никогда - удаления, то время вставки будет расти с увеличением таблицы. Я бы от балды назвал цифру в 10-20%. Тут многое зависит от размера записи, размера страницы, нагрузки и т.д. и т.п.
Re: execute statement
см. статистику по скорости вставки на моем тесте терабайтной БД.Я бы от балды назвал цифру в 10-20%.
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: execute statement
Мнда, опять я сел в лужу... А патч опять надо рихтовать, чтобы в конце каждой РР не оставалось ссылок на недоиспользованные страницы. А может и не надо... Всё равно в супере доступ сериализуется, а в классике новый коннект таки сканирует страницы с начала, хоть и один раз.hvlad писал(а):Не нужно делать непроверенных и неправильных утверждений. Тем более от балды
Re: execute statement
Может вам будет интересно.
Так выложу инфо к сведенью, что могу и что мне известно.
В таблицу идет только вставка, апдейтов и удалений нет. Триггеров нет. Вот в принципе ддл:
За день идет вставка около 2 млн записей, при чем если 1 млн на протяжении дня, то второй в конце, где и есть критичность времени.
Когда таблица перевалила за 40 Гб, то создали вторую и вставку делали туда. выиграли порядка 15 минут, что где-то и есть 10-20 %. Потом разбили еще одну таблицу ну и тоже получили выигрыш во времени.
Сервер Классик 2.0.5 стоит на Линуксе РХ с железом все в полном порядке. БД около 300Гб или даже больше
Ну так проблема вылезла в другом, что не хватает времени на переливку с текущей таблицы в архивную, так как выходных не хватает на бекап/рестор.
Потому и решили например делать таблицу раз в квартал. На этой таблице завязано очень много процедур, по этому и пытаемся что-то придумать через execute statement.
Так выложу инфо к сведенью, что могу и что мне известно.
В таблицу идет только вставка, апдейтов и удалений нет. Триггеров нет. Вот в принципе ддл:
Код: Выделить всё
CREATE TABLE AC (
ACID INTEGER NOT NULL,
TRID INTEGER NOT NULL,
DID INTEGER NOT NULL,
CID INTEGER NOT NULL,
AMT DOUBLE PRECISION NOT NULL,
CCY CHAR(3) NOT NULL,
ODATE DATE NOT NULL,
REALDAT DATE default 'TODAY' NOT NULL,
COMMENTS VARCHAR(160),
INID INTEGER,
AMID INTEGER NOT NULL,
CAMID INTEGER
);
ALTER TABLE AC ADD CONSTRAINT PK_AC PRIMARY KEY (AC);
CREATE INDEX IND_AC_COPD ON AC (CID, ODATE);
CREATE INDEX IND_AC_DOPD ON AC (DID, ODATE);
CREATE INDEX IND_AC_INID ON AC (INID);
CREATE INDEX IND_AC_ODATE ON AC (ODATE);
Когда таблица перевалила за 40 Гб, то создали вторую и вставку делали туда. выиграли порядка 15 минут, что где-то и есть 10-20 %. Потом разбили еще одну таблицу ну и тоже получили выигрыш во времени.
Сервер Классик 2.0.5 стоит на Линуксе РХ с железом все в полном порядке. БД около 300Гб или даже больше
Ну так проблема вылезла в другом, что не хватает времени на переливку с текущей таблицы в архивную, так как выходных не хватает на бекап/рестор.
Потому и решили например делать таблицу раз в квартал. На этой таблице завязано очень много процедур, по этому и пытаемся что-то придумать через execute statement.
Re: execute statement
а зачем вы b/r делаете? И сколько времени занимает бэкап, и сколько рестор, по отдельности?так как выходных не хватает на бекап/рестор.
Есть-ли смысл хранить все в одной БАЗЕ? То есть, чем оправданы мучения с 300гиг базой, при условии хранения данных "с датчиков"?
Re: execute statement
Ну так 5 индексов на таблице, конечно не будет такое летать. Они небось после первого млн ещё и по диску размазаны, вот и начинает притормаживать вставка.nevadimka писал(а):За день идет вставка около 2 млн записей, при чем если 1 млн на протяжении дня, то второй в конце, где и есть критичность времени.
Когда таблица перевалила за 40 Гб, то создали вторую и вставку делали туда. выиграли порядка 15 минут, что где-то и есть 10-20 %. Потом разбили еще одну таблицу ну и тоже получили выигрыш во времени.
Re: execute statement
Если уж ТАК сильно печёт и по другому не получается - сделайте себе таблиц на 5 лет вперёд
Re: execute statement
Та да создать ручками это не проблема. хоть на десять лет. Если продавать функционал,то нужно чтобы все было автоматизировано, а то скажут, что заплатили денюжку и еще вручную талицы создают.
Чтобы хранить это в другой БД, а к этому все движется, так нужно сначала сделать вот этот механизм архивирования, так как одна запись тащит за собой по вторичному ключу вторую и т.д., плюс нужно переписывать процедуры и ПО.
А так проблема изначально была, чтобы запихнуть create и insert в одну процедуру, но от этого отказались и перенос данных решили делать порциями а не сразу всю.
Всем спасибо за советы и ответы
Чтобы хранить это в другой БД, а к этому все движется, так нужно сначала сделать вот этот механизм архивирования, так как одна запись тащит за собой по вторичному ключу вторую и т.д., плюс нужно переписывать процедуры и ПО.
А так проблема изначально была, чтобы запихнуть create и insert в одну процедуру, но от этого отказались и перенос данных решили делать порциями а не сразу всю.
Всем спасибо за советы и ответы
-
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: execute statement
Э-э-э... При вставке миллиона записей выйграли 15 минут?.. А сколько вообще у вас этот миллион вставляется?..nevadimka писал(а):За день идет вставка около 2 млн записей, при чем если 1 млн на протяжении дня, то второй в конце, где и есть критичность времени.
Когда таблица перевалила за 40 Гб, то создали вторую и вставку делали туда. выиграли порядка 15 минут, что где-то и есть 10-20 %. Потом разбили еще одну таблицу ну и тоже получили выигрыш во времени.
Сервер Классик 2.0.5 стоит на Линуксе РХ с железом все в полном порядке. БД около 300Гб или даже больше
Лично я в таком случае первым делом подключил UPS и выключил FW. Мой тест вставки это ускоряет в три раза.