|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Сабж ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2017, 17:42 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Интересные конечно результаты. Хотя с учетом того что не так много пока проголосовавших, значит не так и много. Скажем так, отвечают только те у кого были проблемы с целостностью баз, а у кого проблем не было те сюда и не ходят вообще, и их может быть значительно больше. И наверно еще интересны варианты, о предполагаемых причинах которые привели к нарушению целостности. Хотя бы в комментариях, и на каких версиях Caché случалось, чтобы примерно понять расклад по новым версиям. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2017, 10:40 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Декабрь 2015. Cache 2012.2.5, CentOS 6.x. Файл БД был "грязно" скопирован на другой сервер. Возникли ошибки типа 21, 25 и 26. Случай заинтересовал ISC, и они провели расследование, пытаясь выявить как вероятные причины порчи БД, так и разобраться в некоторых внутренних вопросах (в основном их, конечно, интересовало второе). Однозначно признали, что из-за грязного копирования могла возникнуть лишь ошибка типа 26. Отчёт о ней выглядел примерно так: Код: plaintext 1. 2. 3. 4. 5. 6.
По остальным ошибкам не было столь однозначного мнения. Ситуацию усложняло то, что целостность БД не проверялась перед копированием, поэтому какие-то ошибки возможно уже были, и новые ошибки наложились на старые. Случай отчасти поучительный для тех, кто не верил, что при грязном копировании (т.е., при копировании смонтированной БД) целостность может пострадать, но как говорится учёба прошла за чужой счёт. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2017, 12:31 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
DAiMor, месяца два назад я бы выбрал второй вариант, а сейчас первый. Творится какая-то мистика и ересь, каждую неделю обнаруживаются новые ошибки, вплоть до "The lower level block is degraded and can't be parsed". Но но в основном ошибка правой ссылки, но такая, что просто поправить ее нельзя, потому что в этом случае по сортировке следующий блок будет меньше, чем последняя запись сбойного. Приходится блок удалять. Админы, как водится, в отказ. Катастрофы с сервером случались, но в основном с сервером ничего не происходит, но даже не перезапускается между проверками. После исправления ошибок глобала сразу же проверяю его, т.е. вылазят не недоисправленные ошибки, а новые. Ломаются данные в индексных глобалах, где частое расщепление блоков. Я в недоумении. Последнее, что удивило - было сообщение об ошибке, но лог глянул не в день окончания проверки, посмотрел через пару дней, ошибку глазами в REPAIR не увидел. Перепроверил через INTEGRIT - нет ошибки. Сейчас смотрю логи новой проверки целостности - в глобале две ошибки, и одна из них в том же блоке, что и показало в предыдущий раз. Глазами пока еще не смотрел. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2017, 22:03 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н., Ого, тут явно что-то не так с сервером. Просто останавливать сервер в разгар рабочего дня, пиная на админов, что у них проблемы с железом. Так часто просто не может происходить, тут точно внешняя причина. Но способы выявления этого конечно зависят от конфигурации сервера, ну и конечно ОС. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2017, 22:43 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Мне довольно сложно представить себе частого появления ошибок. На моей практике проблемы возникали в основном по вине неправильного выклчения сервера, либо разрушений диска. Даже база в несколько терабайт, с ежедневным ростом по несколько гигабайт, где одних журналов на 100Гб в день набегает. И не было проблем с целостностью. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2017, 22:55 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Случай с исчезновением ошибки перестал был мистическим, ошибка просто переместилась в другой блок (видимо, произошло расщепление ошибочного блока) ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2017, 07:07 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н....произошло расщепление ошибочного блока...Такое возможно при ошибке в блоке указателей. При ошибке в блоке данных - вряд ли: если у него неверная правая связь, или последний узел, Cache просто откажется работать с этим блоком: <DATABASE>, и отстаньте. Мне случалось видеть "исчезающие ошибки" такого рода: БД > 1TB не удаётся проверить за ночь, и часть проверки неизбежно идёт в параллель с пользователями. При этом есть вероятность словить незавершённую запись. В Cache 2015.1 эти ошибки проявляются так: счётчик ошибок, записанный в начало протокола проверки, > 0, а в самом протоколе ошибок-то и нет. Что удобно, начиная с этой версии, в настройках задачи проверки целостности в качестве имени протокола можно указать каталог, куда будут складываться файлы протоколов проверки, не затирая друг друга. Количество хранимых файлов можно ограничить. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.07.2017, 10:27 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Не понимаю некоторых ошибок и причин их возникновения. Почему, например, Pointer Reference может не совпадать с первой записью в блоке (блок данных) и как это исправить. Была ушибочная запись в родительском блоке, удалил и заново вставил. В родительском поправилось, а в дочернем Pointer Referense так и остался старым. Или, почему Next Pointer Rereferense вообще может быть не похож ни на что: ни что - ни на первую запись следующего узла, ни на ссылку на следующий узел в родительском узле? Часто такое бывает, если нарушена сортировка глобала, запись в следующем блоке раньше по сортировке, чем последняя запись в предыдущем, но не только. И опять, как исправить? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 05:31 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
По-моему, Pointer Reference в блоке может не совпадать с первой записью просто потому, что обрезан. Число при этом округляется. Next Pointer Referense вроде бы удалось изменить повторной установкой Link-а. Странно, в другой ошибке это сделать не получилось (кажется) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 09:44 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н.Почему, например, Pointer Reference может не совпадать с первой записью в блоке (блок данных) и как это исправить.Это ошибка, на которую указывает проверка целостности? вообще заголовок блока не хранит такую информацию, так что Pointer Reference и Next Pointer Reference это чисто информационные данные и на них можно повлять только изменив первый узел блока. Заголовок всего то 28 байт, не так много информации можно туда вместить. А список узлов хранится как данные этого блока. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 10:45 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
DAiMor, нет, ошибка в Next Pointer Referense, просто меня самого сбивает, что у самого блока Pointer Referense хрен знает что. И если Next Pointer Referense - вычисляемый параметр, то почему в нем может быть ошибка? Не в Link-е, а именно в Next Pointer Referense. The lower block has a right link global reference that doesn't Match what was expected in the next pointer node's global reference. We would expect them to be equal. Я логически понимаю, что это избыточная информация, а блок всего 8Кб, да и я не работал с блоками на низком уровне в отличии от вас, но пока у меня создается ощущение, что Link и Next Pointer Referense хранятся отдельно. Может быть разные длины для вычисления Pointer Referense и Next Pointer Referense, из-за этого вычисляется неправильно? Но тогда это вообще тупо. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 11:13 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н.Link и Next Pointer Referense хранятся отдельно...Так и есть, только Link хранится в заголовке блока, а Next Pointer Referense берётся из блока указателя предыдущего уровня (нижнего уровня, если ошибка в блоке данных). Могли разойтись, например, так: при выполнении расщепления блока данных блок указателей нижнего уровня был перезаписан с учётом сего факта, а блоки данных - почему-то нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 11:26 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Alexey Maslov, Т.е. достаточно исправить указатель в родительском блоке? А то, что он, например, где-то отображается обрезанным, это не ошибка? А Способы поменять этот указатель какие? Я делал удаление и вставку записи в родительском блока, но при этом у меня получалось, что Link предыдущего блока автоматом сам не проставлялся. Еще можно удалять и добавлять первую запись в самом блоке, но из-за обрезки указателя меня смутило, что они не совпадаеют с данными. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 11:44 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
* не указателя, а Pointer Referense ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 11:45 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н., Ссылки на блоки могут идти из разных мест, и поэтому есть возможность проверить например есть блок указателей верхнего уровня, со ссылками на два узла нижнего уровня каждый узел ссылается на нижестоящий блок, первый из которых должен иметь ссылку на последующий за ним блок в списке указателей верхнего блока верхний блок 1. ссылка на блок 50 2. ссылка на блок 51 блок: 50 должна быть ссылка на блок 51 блок: 51 если в родительском это последний узел, то ссылки не будет ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 11:45 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н., написал и подумал, что возможна другая причина ошибки типа 24: изменился первый узел в некотором блоке данных (удалили узел глобала), а в блоке указателей осталась старая запись. Такой сценарий более вероятен, т.к. при ошибке расщепления скорее всего разбежались бы правый указатель блока данных и указатель на следующий блок в блоке указателей, что привело бы к ошибке типа 26: Код: plaintext 1. 2.
Нашёл у себя рецепты по ремонту БД при некоторых типах ошибок, конкретно: 9, 13, 14, 24, 26. Могу выложить куда-нибудь, если интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 11:52 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н.Я делал удаление и вставку записи в родительском блоке...Именно так это и лечится согласно моим шпаргалкам; сам не лечил ошибку типа 24 уже давно, и не могу это подтвердить. Блок А.Н....при этом у меня получалось, что Link предыдущего блока автоматом сам не проставлялсяВозможно, были ещё ошибки. Integrity может и не показать все ошибки с первого раза. Про обрезку указателя: не могу прокомментировать, не слышал о таком. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 12:03 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Нет, вы меня обманываете Если все вычисляется, скажите, откуда берется у блока 160685934 Next Pointer Referense = ^EnsHL7.Segment(7432,35)? **********Global EnsHL7.Segment is Not OK********** Error of type 24 while processing pointer block 157514517 which has a left neighbor pointer block of 157514516 The error occurred while processing node 651 which is ^EnsHL7.Segment(7428,2330146) pointing to the lower level block 160685934 The lower block has a right link global reference that doesn't Match what was expected in the next pointer node's global reference. We would expect them to be equal. The lower block's right link reference is ^EnsHL7.Segment(7432,35) The pointer block's next reference is ^EnsHL7.Segment(7428,2330247). ***We will continue checking with the next pointer block at this level. **********Global EnsHL7.Segment is Not OK********** Error of type 24 while processing pointer block 157514517 which has a left neighbor pointer block of 157514516 The error occurred while processing node 654 which is ^EnsHL7.Segment(7428,2330449) pointing to the lower level block 160685938 The lower block has a right link global reference that doesn't Match what was expected in the next pointer node's global reference. We would expect them to be equal. The lower block's right link reference is ^EnsHL7.Segment(7432,""...) The pointer block's next reference is ^EnsHL7.Segment(7428,2330550). ***We will continue checking with the next pointer block at this level. Block #: 157514517 Block # 157514517 Type: 6 BOTTOM POINTER Link Block: 157514518 Offset: 6148 Count of Nodes: 746 Collate: 5 First Node: ^EnsHL7.Segment(7428,2264477) Last Node: ^EnsHL7.Segment(7428,2339747) --more-- # Node POINTER 1 ^EnsHL7.Segment(7428,2264477) 160685052 2 ^EnsHL7.Segment(7428,2264578) 160685054 ***** 649 ^EnsHL7.Segment(7428,2329944) 160685932 650 ^EnsHL7.Segment(7428,2330045) 160685933 651 ^EnsHL7.Segment(7428,2330146) 160685934 652 ^EnsHL7.Segment(7428,2330247) 160685935 653 ^EnsHL7.Segment(7428,2330348) 160685937 ***** 745 ^EnsHL7.Segment(7428,2339646) 160686046 746 ^EnsHL7.Segment(7428,2339747) 160686049 ----------------------------------------------------------------------------------------------------------- Block # 160685934 Type: 8 DATA Link Block: 160685935 Offset: 7760 Count of Nodes: 257 Collate: 5 Big String Nodes: 0 Pointer Length:24 Next Pointer Length:21 Diff Byte:Hex 3F Pointer Reference: ^EnsHL7.Segment(7428,2330146) Next Pointer Reference: ^EnsHL7.Segment(7432,35) Next pointer stored? Yes --more-- # Node Data 1 ^EnsHL7.Segment(7428,2330146) |^~\&ERR|||0|I 2 ^EnsHL7.Segment(7428,2330146,0,33744131) 3 ^EnsHL7.Segment(7428,2330147) |^~\&MSH|^~\&|||MOLISVT|LABOR|20170723170537||ACK^R01^ACK|00000000000016872143|P|2.4 **** 256 ^EnsHL7.Segment(7432,34) |^~\&MSH|^~\&|||MOLISVT|LABOR|20170325053813||ACK^R01^ACK|00000000000014746399|P|2.4 257 ^EnsHL7.Segment(7432,34,0,29492664) ----------------------------------------------------------------------------------------------------------- Block # 160685935 Type: 8 DATA Link Block: 160685937 Offset: 6068 Count of Nodes: 202 Collate: 5 Big String Nodes: 0 Pointer Length:24 Next Pointer Length:24 Diff Byte:Hex 4C Pointer Reference: ^EnsHL7.Segment(7428,2330247) Next Pointer Reference: ^EnsHL7.Segment(7428,2330348) Next pointer stored? Yes --more-- # Node Data 1 ^EnsHL7.Segment(7428,2330247) |^~\&MSA|AA|6448760969403 2 ^EnsHL7.Segment(7428,2330247,0,33744199) *** 201 ^EnsHL7.Segment(7428,2330347) |^~\&ERR|||0|I 202 ^EnsHL7.Segment(7428,2330347,0,33744269) Хотя тут жесть в том, что порядок сортировки нарушен, в конце блока 160685934 данные по сортировке выше, чем в блоке 160685935 И как такие ошибки исправлять, кроме как удалять данные целыми блоками? Чистить несколько сотен записей в блоке 160685934 тоже как-то не хочется ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 17:16 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н., да где уж мне вас обмануть! :) Тем более, что-то ведь означают эти пункты меню: Код: plaintext 1. 2. 3. 4. 5. 6. 7.
Но ни разу (ни устно, ни письменно) мне не попадались советы что-то делать с ними. Когда ошибок много, то наверное да, удалять целыми блоками. При таком высоком проценте ошибок наверняка нарушена и логическая структура данных. Нарушение порядка сортировки в пределах одного блока данных может означать, что его образ испортился уже в памяти (в кэше глобалов), но здесь умолкаю. А техподдержка (WRC) на эту тему что говорит? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 18:37 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Блок А.Н.Хотя тут жесть в том, что порядок сортировки нарушен, в конце блока 160685934 данные по сортировке выше, чем в блоке 160685935Я смею предположить, что такое могло произойти по причине того, произошла ошибка при разбиении блока, новый блок записался, а разбитый не успел и остался в прежнем состоянии. И это полагаю может приводить к дальнейшим ошибкам, при попытке разместить новые данные, которые будут помещатся не в тот блок. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 19:53 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Судя по номерам блоков, база у вас не маленькая, сколько времени занимает проверка целостности? Думаю, стоит присмотрется к исходникам утилит REPAIR, Integrity, можно понять и алгоритмы проверки и как вообще устроена база. Тем более что этот код весь открыт, разве что $view с его магическими комбинациями понять не так просто. Только свое с примением функции $view на важной базе очень не рекомендую ничего делать, только на отдельной специальной базе для опытов. Чревато, на себе испытал, я таким образом удалил самый первый блок в базе со смещением, как так получилось я не знаю. Но чинил потом почти вручную, так как REPAIR меня послал. И со знаниями внутренностей Integrity, получить возможность быстро отсканировать проблемную ветку, очень полезно. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 20:06 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
DAiMor, проверка занимает чуть меньше суток. Ошибки проявляются с завидной регулярностью в разных глобалах, кроме еженедельной проверки я делаю еще проверку в середине недели. Не помню, чтобы полная проверка базы чего-нибудь не выявила. Ну и после исправления, конечно, тоже проверяю глобал. У меня конспирологическая теория, что данные внутри блоков уже много где с кривой сортировкой, которую проверка целостности не проверяет, а при разбиении блоков это проявляется. Нет подтверждения, что такое возможно, но вообще мало что могу придумать для объяснения того, что происходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 20:39 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Alexey Maslov, С Интерсистемс интересная история. Они отказываются поддерживать организацию, по крайней мере официально. Такая странная правовая коллизия, софт куплен в сторонней фирме, и лицензия на Каше идет вместе с софтом от этой фирмы, с Интерсистемс официальных отношений нет, на поддержку они поставить не могут, потому что организация ничего у них не покупала. Я могу, конечно спросить у инженеров что-то, и они мне отвечают, к ним претензий нет. Но такие серьезные вещи скорее всего нужно решать через спецов, более приближенных "к телу", обычно они работают на рубежом, личных контактов у меня с ними нет, а через WRC, как понимаете, задачу я поставить не могу. Blpntlen4 - block header pointer length field Blnextpntlen4 - header next pointer length field Blnextpntvalue4 - block header Discriminator byte Blnextpntoff - header indicator of stored next pointer Я так понимаю, Blpntlen4 и Blnextpntlen4 - длины Pointer Reference и Next Pointer Reference. Непонятно, зачем длины хранить в блоке, если сами значения не хранятся (или все-таки хранятся?) Не понимаю логику этих значений, смотрел, на мой взгляд, не совпадает ни с чем. Менять не понимая страшновато. Blnextpntvalue4 - нет догадок, о том, что это. Blnextpntoff - признак, что Link есть. Странно, это по Link-у нельзя понять? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 20:53 |
|
Были в вашей практике проблемы с целостностью баз данных Каше?
|
|||
---|---|---|---|
#18+
Полезно иногда заглядывать все таки в исходники не помню такого раньше. Но есть возможность запустить REPAIR для удаленной базы через ECP хотя судя по коду различия в работе минимальны, используется тот же набор команд для работы с блоками ... |
|||
:
Нравится:
Не нравится:
|
|||
27.07.2017, 21:55 |
|
|
start [/forum/topic.php?fid=39&msg=39495803&tid=1556325]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 148ms |
0 / 0 |