One of my colleagues made a typo in a query today that led to me discovering this issue — I think it’s a bug, though it may just be how the language is defined. But certainly a subquery that cannot run should not act as if it returns TRUE. Part of me thinks there’s an implicit join going on or something, but I’m not sure how that’s working. Have a look.
I have a client with refreshes scheduled using MV refresh groups, and it took me a while to recall the view name, asking around and RTFM’ing. Since this situation comes up regularly, I wrapped up a quick script that parses job content, takes in account MV refresh groups, and outputs the database link(s) involved. I think it could be useful to few others so here it goes.
After the interesting comment storm on Doug’s blog when he posted some of Tim Gorman’s comments on the value of data in his career experiences as compared to the value of the applications manipulating that data, I hesitate a little to post this. But, I can’t stop myself because it’s such an interesting insight! So here it is!
Welcome to the 90th edition of Log Buffer, the weekly review of database blogs.
I spent way too long figuring out code that would simply load balance based on, always go to one server, go to another server only when the first server is down., again running into the problem where the manual hasn’t been updated. I have made a Forge snippet of this code, but it does not hurt to post it here.
After spending a long time on a project for a client that does a huge amount of data movement using SELECT INTO, I posted a Connect item asking for an enhancement where a minimally-logged insert would be available from a SELECT doing an INSERT into an existing table. One day the item was updated with a comment: “This is targetted to be available in SQL Server 2008.” I wasn’t sure exactly what this meant until the last few days, when Sunil Agarwal posted a series of three posts describing the enhancements to minimal logging in SQL Server 2008 — including the ability to do a minimally logged insert via a SELECT, to an existing table!
I recently imported the contents of an Oracle 8i database into an 11g database. After following the instructions for a typical setupI set up a database link to a remote SQL Server database, and called it SQLSERVER.. It turned out that dg4odbc has “hard coded” the quotes and this will need to be changed in odbc.ini. I should have looked more closely at the installation instructions — yes, the example shows QuotedId=Yes.
While doing a standard audit for a new client, I recommended a few changes to get better performance. Because I had several changes, I used the documentation and found that innodb_flush_log_at_trx_commit is a dynamic variable. I was surprised, because most operations dealing with file sizes and operations are not dynamic. So I searched for others who may have had the same error, and ended up getting an unintentional googlewhack.
Calling a group of people with common interests “community” is just as meaningless as saying I live in a “neighborhood”. There has to be a bond there. I am proud to be a part of the MySQL Community, which actually has forged bonds. If you are new to the MySQL community, feel free to come up and talk to me (or anyone, really) — during the conference, or otherwise. Even if you feel you have nothing to say, just say hello. And I must end with a disclaimer: I won last year’s “Community Advocate” award from MySQL, so I guess all in all, I’m still a community advocate.
My name is Vasu Balla, and I’ve been with Pythian for about four months now. I have worked on Oracle E-Business Suite instances for over five years, and I’ve never had a moment where I felt bored. I am constantly challenged with new technologies and new issues, and my Pythian team’s clients continue to present interesting issues. Our team recently encountered an issue a client had had with Oracle Configurator for two years. They had followed up with Oracle Tech Support for over a year and had eventually learned just to live with the problem. When Pythian came in, we were shocked to learn the history of the problem. It turned out to be one of the most exciting problems we’ve resolved.