2014 Annual Bloggers Meetup
|
The Annual Oracle Bloggers Meetup, one of our favorite events of OpenWorld, is happening at usual place and time thanks to Oracle Technology Network and Pythian. What: Oracle Bloggers Meetup 2014 When: Wed, 1-Oct-2014, 5:30pm Where: Main Dining Room, Jillian’s Billiards @ Metreon, 101 Fourth Street, San Francisco, CA 94103 (street view). Please comment with “COUNT ME IN” if coming — we need to know the attendance numbers. Read more are at Alex Gorbachev‘s latest blog post. |
Eliminar disco LVM de un VolumeGroup perdido
|
Si borramos quitamos los discos físicos de un VolumeGroup que tiene discos lógicos aún activos veremos que en cada comandos de LVM se nos queja: # vgdisplay /dev/vg2/export: read failed after 0 of 4096 at 161057013760: Input/output error /dev/vg2/export: read failed after 0 of 4096 at 161057071104: Input/output error /dev/vg2/export: read failed after 0 of 4096 at 0: Input/output error /dev/vg2/export: read failed after 0 of 4096 at 4096: Input/output error --- Volume group --- VG Name vg0 (...) Podemos quitar dichos errores mediante dmsetup, primero mediante la opción ls podemos identificar todos los dispositivos que considera activos: # dmsetup ls local-var (253:3) local-log (253:2) local-mysql (253:1) local-pgsql (253:0) vg2-export (253:4) Vemos que el último corresponde al error del volume group eliminado que no se desactivaron los discos previamente. Mediante dmsetup remove lo eliminamos: # dmsetup remove vg2-export Si repetimos algún comando LVM veremos que ha desaparecido el error: # lvdisplay --- Logical volume --- LV Path /dev/local/var LV Name var VG Name local (...) Tags: LVM Relacionados
Eliminar disco LVM de un VolumeGroup perdido was first posted on September 1, 2014 at 7:01 am. |
Estado de la batería de una controladora PERC
Anteriormente hemos visto que podemos ver la capacidad de carga de la batería de una controladora RAID PERC y un check de nagios para detectar cuando se pasa de WriteBack a WriteThrough, pero podemos forzar el cambio a WriteBack sin batería, por lo que necesitamos saber el estado de la batería.
Podemos ver el estado de la batería mediante megacli. Mediante -AdpBbuCmd -GetBbuStatus tenemos el valor “isSOHGood”
SOH significa “State Of Health“, por lo tanto nos indica si la batería esta bien o mal:
- Si obtenemos un No, deberemos reemplazarla:
# MegaCli -AdpBbuCmd -GetBbuStatus -aALL | grep -e '^isSOHGood' isSOHGood: No
- Si obtenemos Yes, es que la batería aún esta funcionando:
# MegaCli -AdpBbuCmd -GetBbuStatus -aALL | grep -e '^isSOHGood' isSOHGood: Yes
Relacionados
- Ver los slots de discos libres con megacli
- Ver los discos físicos y lógicos de una controladora PERC
- Historias para no dormir: La batería fantasma
- Cambiar la política de cache de controladora RAID con MegaCLI
- Añadir un RAID con MegaCLI
Estado de la batería de una controladora PERC was first posted on January 20, 2014 at 9:01 am.
LOB Update by Jonathan Lewis
This note is about a feature of LOBs that I first desribed in “Practial Oracle 8i” but have yet to see used in real life. It’s a description of how efficient Oracle can be, which I’ll start with a description of, and selection from, a table:
create table test_lobs (
id number(5),
bytes number(38),
text_content clob
)
lob (text_content) store as text_lob(
disable storage in row
cache
)
;
-- insert a row
SQL> desc test_lobs
Name Null? Type
----------------------- -------- ----------------
ID NUMBER(5)
BYTES NUMBER(38)
TEXT_CONTENT CLOB
SQL> select id, bytes, dbms_lob.getlength(text_content) from test_lobs;
ID BYTES DBMS_LOB.GETLENGTH(TEXT_CONTENT)
---------- ---------- --------------------------------
1 365025 365025
1 row selected.
I’ve got a table with a single CLOB column holding a single row. The size of the single CLOB is roughly 365KB (or about 45 blocks of 8KB). Old hands who have had to suffer LONG columns will recognise the trick of recording the size of a LONG as a separate column in the table; it’s a strategy that isn’t really necessary with LOBs but old coding habits die hard. It’s quite hard to find details of how much space has been used in a LOB segment (thespace_usage procedure in the dbms_space package doesn’t allow you to examine LOBSEGMENTs), but I did a coupld of block dumps to check on this LOBSEGMENT and it had allocated 46 blocks on the first insert.
So here’s the clever bit – how big will the LOBSEGMENT grow when I update that one CLOB ?
It’s common knowledge (to users of LOBs) that the undo mechanism Oracle has for LOBs is simply to leave the old LOB in place and create a new one – so the intial response to the question might be to guess that the LOBSEGMENT will grow to roughly double the size. But it doesn’t have to be like that, at least, not if you update the LOB the way I happen to have done, which is like this:
declare
m_length integer;
m_lob clob;
begin
select
text_content,
dbms_lob.getlength(text_content)
into m_lob, m_length
from
test_lobs
where
id = 1
for update
;
dbms_output.put_line('Lob size: ' || m_length);
dbms_lob.write(
lob_loc => m_lob,
amount => 17,
offset => 1,
buffer => 'This is an update'
);
commit;
end;
/
My code very specifically changes only the first 17 bytes of the LOB. So how much does Oracle have to do to effect this change ? The LOB-handling mechanisms are smart enough to work out that only the first (of 45) blocks in the LOB need to be changed, so Oracle need only add one block to the segment and write the new version of the first LOB block to that one block. (In fact the segment – which was in a tablespace using freelist management – grew by the “standard” 5 blocks from which Oracle selected just one block to add to the LOB.)
So how does Oracle keep track of the whole LOB if it can change it one piece at a time ? This is where the (notionally invisible and you don’t need to know about it) LOBINDEX comes into play. Oracle maintains an index keyed by (LOB_ID, chunk_number) *** pointing to all the chunks of a LOB in order, so when you update a single chunk Oracle simply creates an updated copy of the chunk and changes the appropriate index entry to point to the new chunk. So here’s an image representing our one LOB value just after we’ve created it and before we’ve updated:
And then we “modify” the first chunk – which means we have to add a chunk (which in this case is a single block) to the segment, create a new version of the first chunk, modify the index to point to the new block, and add an index entr – keyed by time-stamp – to the end of the index to point to the old chunk; something like this:
Now, when we run a query to select the LOB, Oracle will follow the index entries in order and pick up the new chunk from the end of the LOBSEGMENT. But the LOBINDEX is protected by undo in the standard fashion, so if another long-running query that started before our update needs to see the old version of the LOB it will create a read-consistent copy of the relevant index leaf block– which means that from its perspective the index will automatically be pointing to the correct LOB chunk.
The index is actually quite an odd one because it serves two functions; apart from pointing to current lobs by chunk number, it also points to “previous” chunks by timestamp (specifically the number of seconds between Midnight of 1st Jan 1970 and the time at which the chunk was “overwritten”). This makes it easy for Oracle to deal with the retention interval for LOBs – any time it needs space in the LOBSEGMENT it need only find the minimum timestamp value in the index and compare it with “sysdate – retention” to see if there are any chunks available for re-use.
To sum up – when you update LOBs, and it’s most beneficial if you have an application which doees piece-wise updates, you leave a trail of old chunks in in the LOBSEGMENT. The version of the LOB you see is dictated by the version of the index that you generate when you request a copy of the LOB at a given SCN.
*** Footnote: My description of the LOBINDEX was an approximation. Each index entry carries a fixed size “payload” listing up to eight lob chunks; so the (LOB_ID, chunk_number) index entries in a LOBINDEX may point to every 8th chunk in the LOB. The significance of the “fixed size” payload is that the payload can be modified in place if the pointer to a LOB chunk has to be changed – and this minimises disruption of the index (at a cost of some wasted space).
Reflexiones (y novedades) sobre la demanda de Oracle a Google
Reflexiones (y novedades) sobre la demanda de Oracle a Google: “
Desde ayer a la madrugada el mundo tecnológico está conmovido por la demanda presentada por Oracle contra Google por violación de patentes y derechos de copyright básicamente al hacer al lenguaje Java parte de la plataforma Android. Pero al tratar la cuestión en la blogósfera estamos olvidando de mencionar algunos aspectos bastante importantes y al mencionar las patentes incluídas en la demanda sin profundizar toda la cuestión parece una locura. A ver, primero estamos olvidando de notar (en muchos artículos que he visto, es en los comentarios donde se dice) que el lenguaje de programación Java es 100% GPL y existen además el OpenJDK y IcedTea, con los cuales podemos trabajar con Java en un entorno completamente libre. El mismísimo Richard Stallman dio el ok para que los programadores trabajemos con Java. Ocurre que el panorama en Java ME es más bien distinto y si alguien quiere implementar la tecnología en desarrollos privativos, debe pagar licencias a Sun (ahora Oracle). Entonces, en este sentido, la ley estaría del lado de Larry.
Por otro lado, el principal punto en el que el tratamiento de la noticia está siendo bastante amarillista se ve reflejado en titulares como “Oracle entierra el espíritu de Sun”, en el que se pone a Sun Microsystems como una compañía buena y respetable (por no decir pura e inmaculada) que fue adquirida por el gigante y malvado Oracle y todo lo que conocemos hoy en día. Claro que Sun tenía una política corporativa mucho más respetable que la de Oracle, ¿pero están famliarizados con el concepto ‘zona de grises‘? Las cosas suelen ser más complejas que eso. El día de hoy y en respuesta a la demanda, James Gosling, creador del lenguaje que renunció a su puesto tras la adquisición de Oracle, escribió una entrada en su blog personal titulada apropiadamente “Finalmente, el ventilador está salpicando la mierda‘. Bastante corta, en ella dice:
Oracle presentó una demanda por patentes contra Google. ¡Qué sorpresa! Durante las reuniones entre Sun y Oracle, cada vez que se mencionaba la situación entre Sun y Google, podíamos ver brillar los ojos de los abogados de Oracle. Pero presentar demandas por patentes nunca estuvo en el código genético de Sun.
Hay dos lecturas de la entrada, pero para comprenderla es genial complementar su lectura con declaraciones realizadas en el mes de marzo por Jonathan Schwartz, ex CEO de Sun, también en su blog personal:
Entiendo el valor de las patentes -con fines ofensivos y, aún más importante, defensivos. Sun posee algunas de las licencias más importantes de internet, por lo que nadie en la industria podría venir por nosotros sin temer un contra ataque. Y no hay mejor defensa que un buen ataque.
No todo era claro bajo el Sol
A ver, Gosling es un ingeniero/desarrollador, le puedo dar el lujo de cierta inocencia, pero si no estaba en Sun presentar demandas, ¿para qué las acumulaban como tesoros en una caja fuerte? Además, el propio Schwartz, con un puesto jerárquico altísimo en la compañía, reconocía la importancia de las patentes. No sólo eso, sino que todos en Sun sabían lo que sucedería al vender la compañía a Oracle. Además, el conflicto no es nada nuevo: hace un par años ya había habido problemas entre Sun y Google por la utilización de Java ME, la micro edición de la plataforma para dispositivos de ‘recursos limitados’ y la máquina virtual Dalvik, que convierte archivos .class generados por el compilador de Java en archivos .dex utilizables por el SDK de Android. El conflicto recién se calmó en la época del lanzamiento de Android y de la liberación del código de Java. Y recordemos antes aún Sun había iniciado acciones contra Microsoft por… adivinaron, incumplimiento de patentes.
La cuestión es simple, dinero. Sí, eso viene diciéndose en todos lados, ya sé, pero sólamente se dice que Oracle quiere dinero y con muchas ganas. El problema es que Oracle quiere encontrar una manera de monetizar los más de cinco mil millones de dólares que gastó en Sun. Java es muy bonito, una de las tecnologías más importantes, “la más importante que Oracle haya adquirido”, en palabras del propio Larry Ellison, pero no por nada Sun, a pesar de todas sus políticas, estaba rumbo a la bancarrota. Y enfrentémoslo, la situación económica de Sun empeoró al hacer algunos de sus productos open source, es una tristísima realidad. No IBM ofreció tan poco por la compañía (a pesar de utilizar enormemente Java) y fue vendida tan barato al peor de los postores. Java tendrá toda la importancia que quieran, ¿pero cómo se justifica una inversión tan grande? Bien, en Sun lo sabían.
Claro, vendieron la compañía al malvado Oracle (la FSF europea apoyó a Oracle, pues había prometido que no utilizaría las patentes de Sun para dañar a la comunidad open source), pero no sé que habría ocurrido de no haberse producido ninguna transacción. Al principio parecía todo muy lindo, pero luego nos enteramos que en el mismo seno de Sun había discusiones en cuanto al open source y a la monetización de una empresa que estaba en caída libre. No tiene mucho sentido especular, pero lo que digo es que de no haberse vendido la empresa a Oracle, no sé si no estaríamos en estos mismos momentos ante una demanda Sun versus Google, pues algo tenían que hacer y como bien dijo Schwartz, conocían el valor de las patentes. Lamentablemente para Google, Oracle debe tener unos abogados cientos de miles de dólares mejores que los de Sun. El momento elegido, hay que reconocerlo, es el peor posible pues vino tras el fin de LinuxCon, evento del cual participó Oracle, demostrando claramente un doble discurso digno de los peores políticos latinoamericanos.
La demanda (y la respuesta de Google)
Con respecto a la demanda, seguramente lleguen a un acuerdo y Google le pague a Oracle una importante suma de dinero que nunca conoceremos y Larry Ellison se quede un poco más tranquilo, aunque es posible también (que roguemos que así sea) la SFLC y la Public Patent Foundation invaliden las patentes, teniendo en cuenta el área ambigua en que están siendo utilizadas y con una licencia GPL. Ayudaría también a Google reemplazar todas las persiones de Java dentro de Android por OpenJDK. Pero el problema, como hemos dicho en este blog varias veces, son las patentes aplicadas al software. Aún tratándose de software libre, somos víctimas de las patentes (¡RMS tenía razón!) .Creo que las renuncias de algunos de los ingenieros más creativos de Sun, personas que participaron de algunos de los momentos más importantes de los últimos tiempos, que colaboraron en la creación de BSD y algunos de los protocolos y estándares que todos damos por sentado no tienen tanto que ver con prácticas nefastas de Oracle sino que demuestra un fracaso. El fracaso de una compañía con una profunda preocupación por la tecnología pero con una preocupante falta de conducción. Y eso, queridos amigos, es un pecado.
Volviendo al asunto en cuestión, Google acaba de romper el silencio y realizó una breve declaración a TechCrunch:
Estamos desepcionados de que Oracle haya decidido atacar a Google y la comunidad open source con esta demanda sin sentido. La comunidad de Java va mucho más allá de cualquier corporación y trabaja todos los días por construir una web mejor. Defenderemos con toda nuestra fuerza los estándares open source y continuaremos trabajando con la industria en el desarrolo de la plataforma Android.
Google es, recordemos, uno de los responsables del uso actual de Java, gracias a Android y el GWT. En conclusión, toda la situación es un gran #fail y no es un buen día para ser un Java developer. ¿La esperanza? Claro que hay esperanza y es el OpenJDK: con él podemos utilizar, además de Java, lenguajes interesantísimos como Scala, Clojure y Groovy y ports de Python, Ruby, Erlang y un largo etcétera, que se convierten así en el futuro de una plataforma que supera al lenguaje para el que fue creada. Independiente del resultado, en palabras del creador del blog CodeMonkeysm, una de las voces más respetadas en el mundo de la programación:
Creo que la demanda de Oracle acercará a la gente a OpenJDK -y eventualmente, el Java de Oracle morirá.
Reflexiones (y novedades) sobre la demanda de Oracle a Google escrita en Bitelia el 14 August, 2010 por federico-erostarbe
Enviar a Twitter | Compartir en Facebook
Systems Computers U.S.A. Inc.© 