Recently during the Exadata patch, one database node reported an issue during the patchmgr and stopped the patch apply. The error was related to missing volumes (LVDoNotRemoveOrUse) at LVM. During the post, you can check the error, but please take attention that it changes some LVM config file contents. So, check correctly the step executed and (if possible) open pro-active SR to be sure what you will be doing.
Sometimes even a perfectly running server can pass over issues after a simple reboot. And was exactly that occurred recently with one Exadata database node. And was not the first time that the same error appears (and since there is no well-documented step by step to fix it I documented them below). So, check how to fix the issue related to the read-only locking_type of LVM detected by dracut.
Em diversos artigos no MOS encontramos informações importantes resumidas a uma simples nota de rodapé ou a uma única linha no meio do texto. Geralmente isso nos leva a pesquisar mais, nos aprofundar no assunto. Foi isso que aconteceu quando estava começando a trabalhar com o Exadata em 2010. Eu estava garimpando algumas notas no MOS atrás de informações sobre o uso do Exadata com OLTP e encontrei uma breve referência ao uso de Hugepages.
Estava lendo a nota MOS# 1067520.1 (que é uma das principais notas sobre desempenho para o Exadata) e lá estava a seguinte informação: “Hugepages should be used, as this reduces the page table size and also reduces process startup time. Review MOS Note 361323.1 and Note 401749.1 for details on hugepages”.
Era uma informação literalmente solta no meio do texto e achei melhor investigar. A nota MOS# 361323.1 tinha o sugestivo nome de “HugePages on Linux: What It Is… and What It Is Not…” e era uma ótima introdução ao que é Hugepages. Já tinha ouvido sobre Hugepages e Oracle, mas isso era para Oracle 9 em ambientes 32 bits com mais de 4GB de memória.