Thread

Oracle on the hook to pay data centre investors even if site has no electricity

158 points · 154 comments · Betelbuddy

gchamonlive · 1790335420 · focus · HN ↗
A too-big-to-fail about to fail certain it'll be bailed out? Another comment* raised a question about investments in fuel cells that could have been just for show. Are they doing max damage to leech as much cash as possible before implosion or it's just... I mean, it's oracle it's a mystery to me how they make so much money with selling crapware, so it might just be business as usual?
*<a href="https://news.ycombinator.com/item?id=49842884">https://news.ycombinator.com/item?id=49842884
1. philipallstar · 1790336197 · focus · HN ↗
  I don't love Oracle, but they made so much money selling the best relational database on the planet for 40 years.
  1. jiggawatts · 1790337165 · focus · HN ↗
    "The best", but you'll be sued if you publish benchmarks: <a href="https://en.wikipedia.org/wiki/David_DeWitt#DeWitt_Clause" rel="nofollow">https://en.wikipedia.org/wiki/David_DeWitt#DeWitt_Clause
    Every time I use Oracle, I regret it.
    Just this month, I tried to hook it up to a modern .NET app with the latest Oracle client and discovered that if you cancel a transaction, the connection enters a broken state and is returned to the connection pool, "infecting it". After a half a dozen of those, the whole app server just dies with endless cancellation related exceptions. This isn't even the only such bug, apparently there's a whole family of pool-corruption bugs that have workaround config settings and everything!
    This was with version 23.26.301 which suggests that they've had a lot of major releases, bug fixes, etc... but basic functionality like "connect successfully to the database server every time" is totally broken and has been for many years.
    The issue tracker forums have tumbleweeds rolling through them and play the sound of wolves howling in the distance to provide just the right kind of "what are you still doing here?" ambiance.
    scrlk · 1790342697 · focus · HN ↗
    > there's a whole family of pool-corruption bugs that have workaround config settings and everything
    Back in 2018, a former Oracle developer explained what it was like working on Oracle DB: <a href="https://news.ycombinator.com/item?id=18442941">https://news.ycombinator.com/item?id=18442941
    > Here is how the life of an Oracle Database developer is:
    > - Start working on a new bug.
    > - Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.
    > - Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
    > - Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
    > - Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
    > - Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
    > - Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
    > - Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
    Seems like their comment is still valid today.
    giva · 1790352337 · focus · HN ↗
    Well, MSSQL has something similar:
    <a href="https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-ver17" rel="nofollow">https://learn.microsoft.com/en-us/sql/t-sql/database-console...
    jiggawatts · 1790470542 · focus · HN ↗
    Those trace flags are reset by an implicit "EXEC sp_reset_connection" called every time you take a connection out of the pool.
    See: <a href="https://github.com/dotnet/SqlClient/issues/767#issuecomment-714625076" rel="nofollow">https://github.com/dotnet/SqlClient/issues/767#issuecomment-...
    "So, let's say you created a new pooled connection and closed it, driver will pool this connection but the physical connection is already active on server side. When the driver reactivates this pooled connection, it's only done on client side by taking it out of pool stack and setting it's state Active. But when next query is executed, we ensure a "RESET" bit is set in TDS header with next command on this newly reactivated pooled connection to cleanup any stale state, as per standard behavior."
    Oracle requires an opt-in(!) flag that is incomplete and configured on the server instead of the client, which is a "special" kind of nonsense that I have no patience for: <a href="https://docs.oracle.com/en/database/oracle/oracle-database/26/odpnt/featConnecting.html#GUID-B970A7CF-6A02-464C-A999-C30D4DB304B4" rel="nofollow">https://docs.oracle.com/en/database/oracle/oracle-database/2...

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.