<?php // Полная загрузка сервисных книжек, создан 2026-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
«Большой размер базы 1С (от 5 Гигабайт и более)»
Мне кажется вы имели ввиду большой размер выгрузки базы.
10 суток на удаление… Ужас.
Совсем недавно сворачивал 120 гб базу… Вся свертка, с учетом времени на бакапы и проверку, заняла порядка 3 часов.
Да, когда 120 Г достигает, пора сворачивать… Базы работают 7х24… Так что свертка занимает 5 минут — спокойно регистрируется узел обмена, запускается копия с пользователями и справочниками, выгружаются в xml остатки на дату из закрытого периода, из них автоматом формируется ввод начальных остатков… Собственно говоря, все, пользователям надо только сменить ярлычок для запуска новой ИБ.
(2) Фантастическое время, расскажите подробнее!
(3) Я правильно понял, что вы формируете новую базу с нач. остатками без оставления 2-3 последних лет?
Оптимизировал вариант удаления докуметов (очистка регистров+пометка на удаление документов)
методом фонового многопоточного (5-7 потоков) запуска на удаления разных регистров/документов. Удалось уменьшить время с 23ч до 6ч.
Хотя метод через выгрузку ХМЛ документов ввода остатков и рабочих документов текущих дней мне понравился (хотя может это и ‘боян’ и прошлый век в плане новизны)
Хотя, еще есть мнение, что база 100-200 и более Гб не размер, и тормозить не должна если обслуживается правильно и запросы оптимизированы, но меня такой размер пока настораживает.
Клиенты тож хотят избавится в рабочей базе от старых периодов. Пока так.
(3)
Это будет работать, если вы обрезаете базу на текущий момент. Тогда да — перебросили остатки, и готово.
На практике же момент свертки находится в прошлом на несколько месяцев, а то и лет. Вот сейчас могут быть свертки на 31.12.2016, или даже 31.12.2015. Перебрасывать через обмены три месяца, или целых 15 — будет еще дольше, чем обрезать.
(4)
Прямые запросы же. Хоть так делать и нельзя — лиц. соглашение, и все такое.
(8) Андрей, если под рукой есть ссылка на описание вашего метода, поделитесь плз.
(9)
Ссылок нет — методика самодельная. Сворачивать-обрезать можно по разному, нюансы у каждого случая свои. Поэтому адаптирую под заказчиков.
Добавлю. Была аналогичная задача по свёртке ERP, причём задним числом — смена собственника. В ERP обработка свёртки информационной базы пустая (очищен весь код). Пришлось эту обработку выдёргивать из торговли (пользуясь близостью конфигураций erp и ут11), немного править и уже сворачивать ERP.
(7)
1. 120 G — это не показатель объема базы в том смысле, что она будет тормозить… Не дождетесь (Если SQL). Причина в другом — при больших объемах время восстановления при авариях возрастает. Операции тестирования и исправления, или перемещения БД на другой сервер становятся неприемлемо долгими (файловых это тоже касается).
2. «Перебрасывать через обмены три месяца, или целых 15 — будет еще дольше, чем обрезать.» —
2.1 Обмен используется не типовой, самописный, работает на порядок быстрее. Простые команды записи и чтения XML, выгружаются только нужные поля (если базы неидентичны)
2.2 Обмен происходит в фоновом режиме порциями с регулируемой нагрузкой — пользователи могут и не замечать.
3. «Фантастическое время, расскажите подробнее! » — Все очень просто (когда уже все это выстрадал…)
3.1 Узел обмена регистрируется — по нему фиксируются новые или измененные объекты, чтоб ничего не упустить. В узле указывается ДатаНачалаОбмена — выбираем в закрытом периоде.
3.2 Создается копия текущей ИБ, в ней в конфигураторе удаляется все, кроме справочников и пользователей (их иногда бывает много). Затем записывается cf из старой ИБ. Это намного быстрее, чем удалять документы или их движения, проще в конфигураторе грохнуть.
3.2 Между новой и старой запускается обмен.
3.3 Из старой в новую заранее написанными обработками выгружаются остатки (по складам, взаиморасчетов с контрагентами, или для Бух — остатки по счетам загружаются в виде документа ВводНачальныхОстатков. Здесь самое интересное — по 01 и 02 счетам конечно же, остальное все типовое, легко делается. Есть варианты, но удобнее всего ручная выгрузка-загрузка через XML.)
3.4 сверка двух баз по складам, взаиморасчетам, счетам и т.д. на ДатуНачалаОбмена — сначала выгружал и сравнивал в экселе или как два файла, потом обработочку написал — из одной ИБ подкл к другой и сравнивает остатки на дату.
3.4 Из старой для новой обработкой регистрируются все документы после ДатыНачалаОбмена.
3.5 Сверка по остаткам на текущий момент.
3.6 Бывает необходимость переноса цен номенклатуры — в старой ИБ обработкой создается документ УчтановкаЦенНоменклатуры на ДатуНачалаОбмена+1 — он автоматом перетекает по обмену в новую ИБ.
3.7 Все пункты выполнялись не торопясь, планово, все спокойно работают, и их теперь можно сажать на новую ИБ — все справочники, остатки, цены и т.д. есть. Вот вроде все, ничего не упустил.
(12) а что с ИБ п 3.2, для чего она?
подозреваю что из неё делается периферийная для узла обмена из п.3.1 ?
(12)
1. Клиент, купивший конфигурацию за пол миллиона и вваливший еще очень много в ее внедрение найдет денег на холодный резерв с вероятностью 99.999. Отсутствие холодного резерва — скорее признак недальновидности администратора/ит-директора. Но скорее там будет горячий резерв в виде AAG или чего другого в случае не-MSSQL. База 100Гб — это вообще ни о чем.
3.2 пачка truncate table думаю будет значительно быстрее чем просто выгрузка/загрузка cf без остальных телодвижений в любой базе данных кроме файловой (файловая ERP? серьезно?). А также есть секционирование с присоединением/отсоединением секций и тому подобные ухищрения для быстрого сноса/добавления данных
Добрый день! Имеется база ERP 2.0, обновленная до текущего релиза. Практически типовая (добавлен 1 регистр сведений и отчет, которые не затрагивают типовую конфу). Объем базы 2 ГБ. Я правильно понимаю, необходимо доработать типовую обработку свертки ИБ (которая есть на ИТС)?
(15)
нет, от УТ 11 идентичного с ERP релиза, в самой ERP обработка есть, но без кода =)
(16)
Ясно, спасибо) Так обработка совсем нерабочая
(9) делюсь своим опытом
«3 часа для свертки» — это когда полгода ее испытываешь, экспериментируешь, оттачиваешь процесс, а затем из года в год прогоняешь одну и ту же базу. мое мнение!
(10) «Адаптация под заказчиков» занимает много времени, а вот свертка наверное да….. всего три часа…..
велкам ту май паблик пост
Большой размер базы — от 5 гигов. Сейчас просто DBA в Магните и Деловых линиях кофем подавились!
Если база тормозит при таком размере, значит проблема не в количестве данных, а в качестве их обработки.
Собственно я сюда зашел почитать про свертку, но ее попросили сделать, чтобы убрать из базы те типы документов, которыми уже не пользуются, по сути механизм отмер, а они периодически всплывают при обновлении.
Хорошая статья, но вот попалось на глаза такая ссылка на просторах инета насчёт сверки базы данных 1с
Что думаете?
(2)Каким средствами сворачивали?