990x.top
Простой компьютерный блог для души)
Debug Dump Files — что это такое и можно ли удалить?
Приветствую друзья! Не все файлы можно удалять в Windows. Да, есть временные файлы, которые называются temp-файлы, для них даже существует специальная папка Temp (%temp%). Еще есть log-файлы, в которых содержится информация о работе программы, как об успешных операциях, так и об ошибках. А еще есть файлы, которые содержат много специфичной информации именно об ошибке — сегодня о таких мы поговорим.
Debug Dump Files — что это такое?
Служебные файлы, созданные отладчиком Windows. Содержат данные об условиях, при которых произошла ошибка/сбой.
Отвечу коротко — если компьютер работает нормально, без глюков — можно спокойно удалить. Но даже если есть глюки — 95% что эти файлы так и останутся бесполезными.
Файлы нужны только для анализа, чтобы понять причину ошибки/сбоя. То есть сами по себе они лежат без дела, но могут понадобиться, если вы захотите узнать почему произошла ошибка или сбой. Обычно в этом нужно разбираться, чтобы изучить файл, также могут быть нужны специальные программы для анализа.
Debug Dump Files это что-то вроде снимка системы на момент ошибки. Могут иметь расширение *.dmp, они могут быть скрытыми, в них может быть также содержимое оперативной памяти на момент ошибки.
Например при ошибке синий экран — тоже создается дамп-файл, анализ которого можно выполнить в утилите BlueScreenView:
Но опять же — провести анализ, выявить причину может только опытный пользователь.
Debug Dump Files — можно ли удалить?
Как мы уже выяснили — да. Только не стоит удалять вручную, лучше это дело доверить встроенному компоненту очистки системы.
Чтобы удалить Debug Dump Files, а также другие мусорные данные:
Также очистку диска можно выполнить из свойств диска — правой кнопкой по диску (в окне Мой компьютер) > свойства > на вкладке Общие будет кнопка Очистка диска:
Это Windows 7, в Windows 10 должно быть все примерно так, но почему-то лично у меня этой кнопки нет. Но команда cleanmgr при этом работает.
Собственно окошко с вкладкой, где можно выбрать что удалять:
Поверьте — встроенная чистилка мусора пожалуй самая безопасная из всех чистилок. Точно к ошибкам не приведет.
Иногда Debug Dump Files могут занимать прилично много места, поэтому конечно их стоит удалить:
Также, если я не ошибаюсь, то в CCleaner есть аналогичная опция — Memory Dumps и возможно что это тоже самое что и Debug Dump Files:
Но если вы неопытный пользователь, то советую вам чистить систему только встроенным инструментом (cleanmgr).
Описание некоторых пунктов из очистки
Скажу честно — при очистке я ставлю галочки везде и еще никогда не было с этим проблем. Даже CCleaner и то считается безопасной чистилкой, что тогда стоит говорить про встроенный инструмент.
Русские Блоги
Веб-мастер WordPress должен: BigDump импортировать файлы базы данных MySQL размером более 2M
При восстановлении базы данных через phpMyAdmin возникнет ошибка
Это связано с тем, что размер вашего файла SQL слишком велик, что превышает возможности обработки phpMyAdmin. Эта ситуация особенно заметна, когда скорость сети относительно низкая. Например, веб-мастер пытается использовать phpMyAdmin для восстановления после перегрузки сети в 20:00 по выходным. Эта проблема может возникнуть при резервном копировании больших баз данных MySQL.
Очевидно, что phpMyAdmin подходит только для восстановления резервных копий относительно небольших файлов SQL. Для восстановления очень большой резервной копии базы данных MySQL необходимо перейти на специальный инструмент восстановления, а именно:BigDump ！
Введение в инструмент импорта базы данных BigDump
Демонстрация использования инструмента восстановления базы данных BigDump
1. Получите файл BigDump и установите
Мы загружаем инструмент BidDump и разархивируем его, чтобы получить файл bigdump.php. Нет сомнений в том, что в файле bigdump.php должны быть установлены некоторые параметры, иначе как он узнает учетную запись подключения к импортируемой базе данных?
Установите параметры подключения к базе данных MySQL для импорта
Вообще говоря, просто установите эти элементы. Для некоторых специальных баз данных вам также необходимо установить кодировку символов базы данных в строке 66 ниже. Этот параметр не установлен в файле bigdump.php. Исходный текст:
Если ваша база данных находится в кодировке UTF-8, то здесь необходимо изменить:
Обратите внимание, что дефис следует удалить. Как показано ниже:
Затем загрузите установленный файл bigdump.php на сайт Joomla, рекомендуется загрузить его во временный каталог / tmp.
2. Загрузите файл резервной копии базы данных MySQL.
Теперь вам нужно загрузить файл резервной копии базы данных в каталог / tmp, где находится bigdump.php. Учитывая размер файла, мы загружаем файл в формате zip через FTP программу FileZilla, а затем удаленно распаковываем его с помощью компонента менеджера ресурсов eXtplorer, установленного в бэкэнде Joomla, и нажимаем Получите файл gate2.sql в каталоге / tmp.
3. Запустите инструмент BigDump.
Введите URL-адрес, по которому bigdump.php находится в адресной строке браузера, и нажмите Enter, чтобы запустить этот файл. Например, эта демонстрация выполняется на локальном тестовом сервере, поэтому соответствующий рабочий URL-адрес:
Если URL-адрес, который вы ввели, правильный, вы должны увидеть следующий экран:
На изображении выше вы также можете увидеть функцию загрузки файла.Нажмите кнопку «Обзор», и вы сможете загрузить файл SQL (или его сжатый пакет) для импорта. Но мы не рекомендуем использовать эту функцию. Для больших файлов лучше всего подходит загрузка по FTP.
4. Запустите функцию импорта BigDump.
Щелкните ссылку «Начать импорт» на рисунке выше, и вы увидите следующий экран:
Щелкните ссылку «Начать импорт» на изображении выше.
Снимок экрана выше был сделан через некоторое время после начала импорта. Видно, что BigDump успешно импортирует файл SQL. В таблице показан не только размер файла, но также количество импортированных байтов и общий прогресс.
Через некоторое время (около 20 минут) этот файл SQL размером 150 МБ, наконец, будет импортирован, и вы увидите следующий экран:
Наконец, импортирован файл SQL размером 150 МБ
Там, где изначально отображался индикатор выполнения, теперь отображается сообщение:
“Congratulations: End of file reached, assuming OK”
Это означает: достигнут конец файла, и это должно быть успешно. Когда вы видите эту новость, можете не сомневаться. BigDump успешно импортировал файл резервной копии SQL в указанную вами базу данных MySQL.
Примечание. После успешного завершения восстановления базы данных не забудьте удалить инструмент резервного копирования bigdump.php и ваш файл SQL!
Меры предосторожности при использовании инструмента импорта базы данных BigDump
1. Перед началом импорта необходимо очистить целевую базу данных.
Если целевая база данных содержит записи, BigDump не может быть импортирован и остановится с ошибкой. Поэтому очистите целевую базу данных перед запуском файла bigdump.php (желательно удалить все содержимое).
2. Используемый файл SQL не может содержать расширенные вставки.
Возможно, с этой проблемой столкнутся многие пользователи, впервые использующие BigDump. Это связано с тем, что phpMyAdmin по умолчанию установил флажок «Использовать вставку расширения» при экспорте базы данных.
Убрать галочку «Extension Insertion» на панели phpMyAdmin
3. Как заставить Akeeba Backup работать с BigDump?
Мы рекомендуем вам использовать Akeeba Backup для создания резервных копий файлов. Итак, могу ли я использовать Akeeba Backup для создания резервной копии базы данных, а затем импортировать ее через BigDump? Конечно, это возможно. Однако для этого нужны особые навыки. Мы представим его в подробном описании Akeeba Backup в этом руководстве.
4. Ошибка тайм-аута все еще возникает при импорте с помощью BigDump.
5. Что делать, если сервер MySQL перегружен?
Бизнес-история
Вход на сайт
Последнее видео
Страницы
Авторская энциклопедия
Вы здесь
3.2. Перенос на хостинг объемистой базы данных с помощью программы BigDump
Процесс переноса базы данных с локальной машины на удаленный хостинг в целом похож на процесс ее переноса в обратном направлении, что мы уже делали в разделе 1.2 настоящей «киноэпопеи». Во всяком случае, основные шаги те же: 1) создаем базу данных; 2) импортируем в нее сохраненный резервный файл; 3) проверяем, все ли корректно импортировалось.
Первый шаг довольно прост в том случае, если для интерфейса используется та же прога, что и на локальном компьютере, в данном случае — phpMyAdmin. А вот со вторым шагом несколько сложнее.
Вы, наверное, помните, что на локальную машину база данных у меня с ходу не перенеслась из-за того, что ее объем превысил прописанные лимиты. И проблема была решена после того, как я изменил эти самые лимиты, прописав соответствующие циферки в файле php.ini.
Подобная же проблема возникла, когда я стал «заливать» базу обратно на хостинг. Положение еще более усугубило то, что она раздулась в процессе апгрейда раза в полтора. Короче, получил я по темечку следующим широковещательным сообщением: Вероятно, размер загружаемого файла слишком велик. Способы обхода данного ограничения описаны в документации.
Вся пакость ситуации в том, что ни я, ни подавляющее большинство пользователей удаленных хостингов ни к файлу php.ini, ни ко многим другим настройкам доступа не имеют. Посему приходится выкручиваться более хитрыми способами. Благо, эти самые способы подсказывает сама программа phpMyAdmin. А именно, при переходе по ссылке на документацию в вышеприведенном окошке мы находим перечисление разнообразных возможностей «хода конем», хотя и на буржуйском языке. Из них наиболее подходящим мне показалось использование программы BigDump:
Подсвеченное на рисунке название программы ведет на сайт www.ozerov.de/bigdump, откуда можно без труда скачать ее дистрибутив:
Дистрибутив сей представляет собой архив, состоящий всего из одного файла bigdump.php. Распаковываем его, переносим в удобное место, открываем любым удобным редактором — хоть Word’ом, хоть «Блокнотом», лично я пользуюсь Notepad++.
Итак, заходим в файл bigdump.php и ищем там раздел Database configuration. У меня он изначально выглядел вот так:
Теперь нам надо поменять параметры доступа к файлу. Это делается уже в других разделах файла.
Другие изменения лучше делать после попытки использования утилиты (ИМХО, конечно). Для этого надо создать папку dump на вашем хостинге и закачать туда наш измененный файл bigdump.php — так, чтобы его можно было запустить в строке вашего браузера, типа: Имя_сайта/dump/bigdump.php. В ту же папку dump закидываем и «дамп» вашей базы данных.
Теперь — запускаем файл по только что упомянутому адресу. Должно окошко следующего вида:
Смело нажимаем на Start Import и смотрим, что произойдет дальше. Лично у меня высветилось сообщение: Stopped at the line 2964 (Остановлено на линии 2964). После чего — комментарии, основная суть коих выражена в первом предложении: At this place the current query includes more than 300 dump lines (На этом месте текущий запрос включает более 300 линий дампа):
Ничего страшного не произошло: просто мы перед запуском файла bigdump.php не внесли в него всех необходимых изменений. Т. е., в нем тоже есть свои ограничения. Но сложность в том, что мы не всегда заранее знаем, под какие из них подпадет наша база данных. Собственно, для этого мы и запустили утилиту до того, как начали делать дальнейшую правку.
Здесь я исправил число 300 на 30000 — возможно, малость переборщил… но хватило.
Да, и после каждого неудачного запуска bigdump.php (типа описанного выше) следует очищать от данных ту таблицу MySQL, в которую происходит загрузка. Иначе рискуете получить сообщения об ошибках типа следующего (Error at the line. ), и чистить ее все равно придется:
После всех нужных изменений должно наконец открыться окно нормальной работы программы, выглядящее следующим образом:
После заливки — посмотрите на вновь закачанную таблицу и выполните с ней какие-нибудь манипуляции. Например, сравните с исходной таблицей на вашей машине, как это сделал я. На правильном языке этот процесс называется «тестирование».
После всего этого — со спокойной совестью удаляйте с хостинга папку dump вместе со всем ее содержимым.
Bigdump что это за папка
Staggered MySQL Dump Importer
Description: Staggered import of large and very large MySQL Dumps (like phpMyAdmin dumps) even through the web servers with hard runtime limit and those in safe mode. The script imports only a small part of the huge dump and restarts itself. The next session starts where the last was stopped.
This code is originally written by Alexey Ozerov.
Note 1: BigDump will fail processing large tables containing extended inserts. An extended insert contains all table entries within one SQL query. BigDump isn’t able to split such SQL queries. In most cases BigDump will stop if some query includes to many lines. But if PHP complains that allowed memory size exhausted or MySQL server has gone away your dump probably also contains extended inserts. Please turn off extended inserts when exporting database from phpMyAdmin. If you only have a dump file with extended inserts please ask for our support service in order to convert it into a file usable by BigDump.
Note 2: If you want to upload the dump files via web browser give the scripts writing permissions on the working directory (e.g. make chmod 777 on a Linux based system). You can upload the dump files from the browser up to the size limit set by the current PHP configuration of the web server. Alternatively you can upload any files via FTP. Some web servers disallow script execution in the directory with writing permissions for security reasons. If you changed the permissions on the working directory and you are getting a server error when running the script restore the permissions to their normal state (chmod 755) for directories.
Note 5: BigDump is currently not able to restore a single dump file with multiple databases inside (switched by the USE statement). BigDump is also not able to restore a single specific database from the dump file containing multiple databases.
Note 7: GZip support is only available with PHP 4.3.0 and later. Using a huge GZip compressed dump file can cause the script to exceed the PHP memory/runtime limit since the dump file has to be unpacked from the beginning every time the session starts. If this happens use the uncompressed dump. It’s your only chance.
War dieser Beitrag hilfreich? Empfehlen Sie ihn weiter!
Usage
Advanced notes
Note 1: BigDump will fail processing large tables containing extended inserts. An extended insert contains all table entries within one SQL query. BigDump isn’t able to split such SQL queries. In most cases BigDump will stop if some query includes to many lines. But if PHP complains that allowed memory size exhausted or MySQL server has gone away your dump probably also contains extended inserts. Please turn off extended inserts when exporting database from phpMyAdmin. If you only have a dump file with extended inserts please ask for our support service in order to convert it into a file usable by BigDump.
Note 2: If you want to upload the dump files via web browser give the scripts writing permissions on the working directory (e.g. make chmod 777 on a Linux based system). You can upload the dump files from the browser up to the size limit set by the current PHP configuration of the web server. Alternatively you can upload any files via FTP. Some web servers disallow script execution in the directory with writing permissions for security reasons. If you changed the permissions on the working directory and you are getting a server error when running the script restore the permissions to their normal state (chmod 755) for directories.
Note 5: BigDump is currently not able to restore a single dump file with multiple databases inside (switched by the USE statement). BigDump is also not able to restore a single specific database from the dump file containing multiple databases.
Note 7: GZip support is only available with PHP 4.3.0 and later. Using a huge GZip compressed dump file can cause the script to exceed the PHP memory/runtime limit since the dump file has to be unpacked from the beginning every time the session starts. If this happens use the uncompressed dump. It’s your only chance.
