Comments 24
Я пытался добиться его исключения из SQL Server 2005 и SQL Server 2008, когда я был в должности, позволяющей добиваться этого
Нет чтобы добиваться автоматической дефрагментации после сжатия.
После — это тоже компромиссный вариант. Лучший вариант — это сразу сделать алгоритм, который будет избегать фрагментации по максимуму, но его Полу тоже реализовать не удалось, к сожалению.
Могли бы сделать дефрагментацию индексов при перемещении в новую файловую группу, а не заставлять это делать руками.
Как раз при перемещении в новую файловую группу дефрагментация делается. Она не делается, если мы работаем в рамках одной файловой группы. Если вы имеете в виду, что нужно автоматом создавать новую файловую группу и переносить туда индексы — то, ИМХО, выполнение такой операции на автомате имеет больше минусов, чем плюсов.
Очень интересная информация-сам на такое натыкался. Причем источник проблемы обнаружить сразу не удавалось.
Всегда считал «шринк» обрезкой файла, но никак не сжатием.
Я для переводов всегда стараюсь искать соответствие — как именно сам майкрософт переводит тот или иной термин.
Так что тут именно «Сжатие»:
https://technet.microsoft.com/en-us/library/ms189080.aspx
https://technet.microsoft.com/ru-ru/library/ms189080.aspx
Так что тут именно «Сжатие»:
https://technet.microsoft.com/en-us/library/ms189080.aspx
https://technet.microsoft.com/ru-ru/library/ms189080.aspx
А ведь ещё data compression присутствует.
А оно называется «Сжатие данных».
https://msdn.microsoft.com/ru-ru/library/cc280449.aspx
Вот такая путаница. Поэтому с Майкрософтом нужно быть начеку при переводе терминов. Именно поэтому, при знании английского, лучше пользоваться английскими терминами и английским же интерфейсом.
https://msdn.microsoft.com/ru-ru/library/cc280449.aspx
Вот такая путаница. Поэтому с Майкрософтом нужно быть начеку при переводе терминов. Именно поэтому, при знании английского, лучше пользоваться английскими терминами и английским же интерфейсом.
Хорошо бы первое упоминание термина пояснить в скобках английским оригиналом, чтобы не лезть в исходник статьи
Я думал об этом, но решил, что, если читатель знает английский, я с удовольствием порекомендую ему сразу перейти к оригиналу — это и полезнее и интереснее, а если читатель английского не знает и пользуется русским интерфейсом, то нагружать его сопоставлением терминов смысла не имеет. Было бы неплохо иметь словарик для ключевых терминов — как они переведены на русский — от самой компании Майкрософт, я бы сам им с удовольствием пользовался во время перевода, но я такого не нашел, к сожалению.
Может быть, термин «уплотнение» более адекватный.
А вот интересно, в случае скульных баз 1с все тоже самое?
У меня шринк каждый день идет, реиндекс раз в неделю (в воскр) База 130гб.
Отобрал несколько таблиц (по размеру и кол-ву записей), проверил avg_fragmentation_in_percent — везде примерно 0.03%
И автошринк включен, те все ровно не так как в статье. Может я как-то не так смотрю фрагментацию??
У меня шринк каждый день идет, реиндекс раз в неделю (в воскр) База 130гб.
Отобрал несколько таблиц (по размеру и кол-ву записей), проверил avg_fragmentation_in_percent — везде примерно 0.03%
И автошринк включен, те все ровно не так как в статье. Может я как-то не так смотрю фрагментацию??
Это касается всех баз на SQL Server, независимо от их происхождения. Про то, что обслуживающие 1С люди часто рекомендуют включать шринк — я знаю, и это мне очень не нравится, в частности поэтому я перевел статью от уважаемого автора.
Запрос для просмотра фрагментации есть в примерах в статье, так что если им пользуетесь — смотрите верно. То, что фрагментация у вас отсутствует — может быть счастливым стечением обстоятельств — это не значит, что так будет всегда.
Я не буду брать на себя ответственность и обязывать вас исключить шринк из обслуживания и выключить автошринк, потому что с возможными последствиями в виде возможного неконтролируемого роста базы разбираться потом вам, а не мне, но порекомендовать выключить эти опции все же могу, если готовы следить за размером базы и вовремя предпринять действия для контроля над ростом.
Запрос для просмотра фрагментации есть в примерах в статье, так что если им пользуетесь — смотрите верно. То, что фрагментация у вас отсутствует — может быть счастливым стечением обстоятельств — это не значит, что так будет всегда.
Я не буду брать на себя ответственность и обязывать вас исключить шринк из обслуживания и выключить автошринк, потому что с возможными последствиями в виде возможного неконтролируемого роста базы разбираться потом вам, а не мне, но порекомендовать выключить эти опции все же могу, если готовы следить за размером базы и вовремя предпринять действия для контроля над ростом.
Да, всё то же самое!
Рекомендация по шринку раз в день это из мохнатых методических материалов времен 1С: Предприятия 7.7 и SQL Server 2000. Это тогда уже было вредно, но пользовалось популярностью, т.к. позволяло высвобождать «ненужное» дефицитное место на диске, что очень грело душу на фоне того, что SQL база и так в 1,5-2 раза более объемна, чем файловый dbf-вариант.
Рекомендация разошлась по куче форумов и статей про установку и настройку SQL для 1С, и уже выросло целое поколение специалистов которые бережно хранят это священное знание.
Рекомендация по шринку раз в день это из мохнатых методических материалов времен 1С: Предприятия 7.7 и SQL Server 2000. Это тогда уже было вредно, но пользовалось популярностью, т.к. позволяло высвобождать «ненужное» дефицитное место на диске, что очень грело душу на фоне того, что SQL база и так в 1,5-2 раза более объемна, чем файловый dbf-вариант.
Рекомендация разошлась по куче форумов и статей про установку и настройку SQL для 1С, и уже выросло целое поколение специалистов которые бережно хранят это священное знание.
я бы перевел заголовок как "Почему вам не стоит сжимать файлы данных". "ваши" в данном случае — типичная ошибка — калька с английского языка. На русский это переводится словом "свои", или же вообще опускается
или даже "Не стоит сжимать файлы данных", а если совсем коротко, то "Не сжимайте файлы данных"
Я «ваше» мнение услышал, и с «вашим» мнением не согласен.
Слово «ваше» в данном случае, мне кажется, используется для усиления эффекта принадлежности, и вполне переводимо на русский, также для усиления эффекта. Можно и на английском сказать «Why you should not shrink data files», но смысл слегка меняется.
Мне очень нравится читать статьи Пола, у него весьма выразительная и точная манера письма — как правило, в его статьях нет лишних слов, все они несут какое то значение, и я стараюсь эту выразительность передать, как могу.
Слово «ваше» в данном случае, мне кажется, используется для усиления эффекта принадлежности, и вполне переводимо на русский, также для усиления эффекта. Можно и на английском сказать «Why you should not shrink data files», но смысл слегка меняется.
Мне очень нравится читать статьи Пола, у него весьма выразительная и точная манера письма — как правило, в его статьях нет лишних слов, все они несут какое то значение, и я стараюсь эту выразительность передать, как могу.
Интересно, но вам самому приятно читать? Уже по первым трем строчкам ощущается сильнейший перевод в лоб. Может надо на Хабре добавить кнопку — «Пожаловаться на перевод»?
«Одна из самых моих горячих проблем касается сжатия файлов данных. Несмотря на то, что я владел кодом сжатия, когда работал в Майкрософт, у меня не было шанса переписать его так, чтобы сделать его более приятным. Мне действительно не нравится сжатие.»
«А я любить сжатие!» Ваш перевод не так уж ужасен, но это уже 100500 подобного качества опус.
Мне, например, косноязычные статьи делать стыдно.
«Одна из самых моих горячих проблем касается сжатия файлов данных. Несмотря на то, что я владел кодом сжатия, когда работал в Майкрософт, у меня не было шанса переписать его так, чтобы сделать его более приятным. Мне действительно не нравится сжатие.»
«А я любить сжатие!» Ваш перевод не так уж ужасен, но это уже 100500 подобного качества опус.
Мне, например, косноязычные статьи делать стыдно.
Делаю как могу.
Мне перевод кажется достаточно хорошим — вполне возможно, что я не обладаю достаточным знанием русского, или просто не могу взглянуть на него со стороны, чтобы оценить его недостатки — для этого как раз есть функционал оценки статьи — пока оценки моих переводов плюсовые, поэтому я считаю, что не согласных с вашей оценкой качества больше, чем согласных. Смысла вводить отдельную кнопку для оценки перевода я не вижу — можно оценить качество перевода, поставив оценку статье.
Вы же, судя по тому, что в comment-only режиме — слишком остро оцениваете качество, не давая себе шанса делать ошибки. Попробуйте сделать хотя бы какой-то перевод, возможно ваша категоричность по отношению к чужим работам уйдет.
Мне перевод кажется достаточно хорошим — вполне возможно, что я не обладаю достаточным знанием русского, или просто не могу взглянуть на него со стороны, чтобы оценить его недостатки — для этого как раз есть функционал оценки статьи — пока оценки моих переводов плюсовые, поэтому я считаю, что не согласных с вашей оценкой качества больше, чем согласных. Смысла вводить отдельную кнопку для оценки перевода я не вижу — можно оценить качество перевода, поставив оценку статье.
Вы же, судя по тому, что в comment-only режиме — слишком остро оцениваете качество, не давая себе шанса делать ошибки. Попробуйте сделать хотя бы какой-то перевод, возможно ваша категоричность по отношению к чужим работам уйдет.
Sign up to leave a comment.
Почему вы не должны сжимать ваши файлы данных