SBSPACENAME overiding PUT clause
David Grove (12.10.FC14) found a CLOB table's PUT clause sbspace was ignored in favor of SBSPACENAME. Andreas Legner asked about cluster replication and a non-logging sbspace, but logging was not the cause. IBM support said it is defect IT37406 (Java UDRs inserting CLOBs into the default sbspace), fixed in 14.10.xC7, with no 12.10 fix; the workaround is SET ENVIRONMENT SBSPACENAME.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Informix 12.10.FC14 Solaris 10 1/13 I have already opened a tech support case for this, but am posting here, in case anyone might recognize the problem and have a quicker answer. We have a table with a CLOB column. The table has a PUT clause defined, which specifies an sbspace in which we want the CLOBS stored. We also have the SBSPACENAME config parameter defined. It serves as a "catch-all" sbspace, in case there is an sblob-containing table without a PUT clause. We do NOT intentionally have any such tables. Using the SBSPACENAME parameter is a "safety net". The problem is that Informix is using the SBSPACENAME sbspace, rather then the PUT clause sbspace to store the CLOBS. This is a serious issue for us, and we really need Informix to use the PUT clause. Regards DG P.S. (Edit) the application code is written in Java, and resides on another physical server. Access Informix via JDBC driver. ------------------------------ David Grove ------------------------------
Just a shot in the dark: is cluster replication involved and this PUT clause sbspace possibly "non-logging"? ------------------------------ Andreas Legner ------------------------------
Ah, that resonates... you probably hit it. This server had been the primary in an RS pair. I had recently disabled logging on that space so that I could move a ton of sblobs without risking a long TX. In fact, I broke the mirror to avoid trucking a bunch o' bits across the WAN (primary and RSS are 600 miles apart), and have yet to re-establish mirroring. I just now re-activated logging for that sbspace, and will observe whether PUT now "triumphs" over SBSPACENAME. (Or do I need to bounce Informix to expect that?) I will observe results for the rest of the afternoon. During that time period there will be sufficient new sblobs generated that I can observe behavior and draw conclusions. Andreas, your posts are always like beacons in the night. Laser-like focus on the issue, with a thought that is either revealing, or resolving of, the issue. Thank you. DG ------------------------------ David Grove ------------------------------
Premature. I just inspected the online log, and observe that it reports that the (attempted) change to logging was already in effect. (I have turned logging off and on for that space so many times in recent days, that I had forgotten the current state, and just use the SQL API to turn logging on. Online log says already on.) So, my remarks about the status of the servers is true, but apparently (lack of) logging is not the source of the problem. DG ------------------------------ David Grove ------------------------------
The answer from Tech Support is that this is an Informix defect: IT37406 (idsdb00109227 ) : JAVA UDRS ARE INSERTING CLOBS IN DEFAULT SMART BLOB SPACE : Fixed in 14.10.xC7 Seems like we're "on a streak" with recent tech cases. First the APAR with the zombie sblobs. Now the (non-APAR) defect with Java UDRs storing sblobs in the wrong sbspace. "They" say that things come in threes. Wonder what's next. There is no fix in the 12.10 codestream. IBM did fix it in 14.* (which we can't use because we have Solaris 10, and Oracle has stated that they have not provided (and will not provide) an upgrade path from Solaris 10 to Solaris 11. You have to do a new bare metal install.]) Thankfully, Tech support does identify a work-around, in the form of using the "SET ENVIRONMENT SBSPACENAME" command. We will try that. It is not documented in the 12.10 documentation, but, if Tech Support is suggesting it, we will happily try it. Looks like "our work here is done". Thank you. DG ------------------------------ David Grove ------------------------------