Много текстовых файлов в один большой текстовый файл
Вы не можете использовать mysql клиент для соединения с mssql сервером. MSSQL является основанным на Windows сервисом базы данных SQL, в то время как MySQL является другим протоколом в целом, и MSSQL является другим протоколом в целом. Это - протокол TDS, который разделяет их оба. Если Вы хотите соединиться с сервисом MSSQL от инструмента на Unix, то существует набор их. Можно использовать FreeTDS, PyMSSQL, подход ODBC/JDBC.
Если Вы ищете некоторые готовые инструменты подхода затем существуют немногие, я знаю:
http://sqldump.sourceforge.net/
Смотрите на них.
Flimzy,
утилита mysqldump поддерживает файлы резервного копирования базы данных к местоположению локального диска, но mssql или sybase, кажется, не предлагают эту гибкость непосредственно. В MSSQL однако можно записать файлы резервного копирования базы данных в пути UNC как сетевые ресурсы, которые являются, иначе может быть назван как путь удаленной файловой системы, смонтированный локально на mssql сервере базы данных. Существует ftp поддержки также непосредственно от BACKUP DATABASE Сама команда SQL, таким образом, можно загрузить файлы резервного копирования базы данных как поток к местоположению загрузки ftp. Различия в пропускной способности и ограничения протокола должны быть взяты в перспективу, все же. Было бы хорошо использовать пути UNC, если Вы можете установить долю winbind/smb на своей локальной машине и можете сделать ее доступной через домен рабочей группы/AD и затем доступной для сервера MSSQL; если существуют сетевые ограничения пропускной способности. Если бы это локально, я пошел бы для него, удостоверившись, что все элементы защиты покрыты.
Если бы это - ftp, это было бы просто, так как администрирование ftp абсолютно локально, и можно ограничить путь загрузки в области файловой системы ftp. Вам нужно не беспокойство требований пользователя присоединения/AD самбы и так далее. Просто сервис ftp как чистое сетевое местоположение с, возможно, права доступа осуществляются. BTW, удостоверьтесь, что Ваши дампы защищаются, если бы это - производство, я вдвойне, несомненно, заставил бы их защитить :-)
Нет cat не буферизует все файлы, прежде чем это начнет запись.
Однако, если у Вас есть большое количество файлов, можно столкнуться с проблемой с количеством аргументов, переданных cat. По умолчанию ядро Linux только позволяет постоянному числу аргументов быть переданным любой программе (я не могу помнить, как получить значение, но это - несколько тысяч в большинстве случаев).
Для решения этой проблемы, можно сделать что-то вроде этого вместо этого:
find -mindepth 2 -maxdepth 2 -type f -exec cat {} \; > bigtextfile.txt
Это будет в основном звонить cat отдельно для каждого файла, найденного find.
В:
cat */* > bigtextfile.txt
Оболочка расширится */* в отсортированный список (нескрытых) файлов соответствия, и выполнится cat с теми путями к файлам как аргументы.
cat откроет каждый файл в свою очередь и запишет на его stdout, что он читает из файла. cat не будет содержать больше чем один буферизует полный данных (что-то как несколько килобайтов) за один раз в памяти.
Проблема, с которой можно встретиться, хотя то, что список аргументов cat является столь большим, что это достигает предела размера аргументов execve() системный вызов. Так, Вы, возможно, должны разделить тот список файлов и работать cat несколько раз.
Вы могли использовать xargs для этого (здесь с GNU или BSD xargs для нестандартного -r и -0 опции):
printf '%s\0' */* | xargs -r0 cat -- > big-file.txt
(потому что printf создается в оболочке, она не проходит execve системный вызов, таким образом, не через его предел).
Или имейте find составьте список файлов и выполните столько же команд кошки по мере необходимости:
find . -mindepth 2 -maxdepth 2 -type f -exec cat {} + > big-file.txt
Или портативно:
find . -path './*/*' -prune -type f -exec cat {} + > big-file.txt
(остерегайтесь хотя это вопреки */*, это будет включать скрытые файлы (и файлы в скрытых каталогах), не искать файлы в символьных ссылках на каталоги, и список файлов не будет отсортирован).
Если на последней версии Linux, можно снять предел на размер аргументов путем выполнения:
ulimit -s unlimited
cat -- */* > big-file.txt
С zsh, Вы могли также использовать zargs:
autoload zargs
zargs -- */* -- cat > big-file.txt
С ksh93, можно использовать command -x:
command -x cat -- */* > big-file.txt
Все они делают то же самое, разделяют список файлов и работают как многие cat команды по мере необходимости.
С ksh93 снова, можно двигаться execve() предел при помощи встроенного cat команда:
command /opt/ast/bin/cat -- */* > big-file.txt
-
1IIRC, способность использовать
+на-execизfindограничен GNU, находят. – Patrick 10.04.2013, 23:38 -
2@Patrick. Нет, это наоборот.
+является стандартным, и GNUfindбыл один из последних, которые будут поддерживать его (в 2005). – Stéphane Chazelas 10.04.2013, 23:42
Если количество файлов является слишком большим, */* даст слишком большой список аргументов. Если так, что-то вдоль строк сделает:
find . -name "*.txt" | xargs cat > outfile
(идея состоит в том, чтобы использовать find взять имена файлов и превратить их в поток; xargs прерывания это устремляется вверх в управляемые части для предоставления cat, какой concatenes их в поток вывода xargs, и это входит outfile).
-
1Однако не, что это принимает, ни одни из имен файлов не содержат SPC, ВКЛАДКУ, Новую строку, одинарную кавычку, символы обратной косой черты или двойная кавычка. – Stéphane Chazelas 10.04.2013, 23:35