Support for Installation with MS SQL Database is Deprecated#

Starting with Identity Governance 4.2, utilizing MS SQL as a database to install against is deprecated and this option will be removed in a future release. The JDBC Collectors and Fulfillment will not be impacted when the ability to install against MS SQL has been removed.

Not a joke. Well, I didn't find it funny then.   It's a bit amusing now looking back on it.

I supported a client that was using MS SQL and we saw this problem when we had some VERY large reviews and/or a large number of simultaneous collections.  I'm speculating, but I think it was related to the lock escalation feature where the engine would arbitrarily just lock a whole table when it detected enough changes were happening, which meant other threads were on pause until the lock went away.  And since it happened mid-transaction, those other jobs had their own row-level locks.    You can turn off that feature but MS argues against it because its how they ensure performance in other areas, so its a bit of a catch 22.   That client migrated to Oracle and no problems since.

If on-prem doesn't work for your customers, you can always go to SaaS!

--Jim

...or to migrate Sailpoint ;)

You could, but I think you'd be giving up on the elegant provisioning and de-provisioning that IG has, and its integration with IDM.  I've done a Sailpoint deployment, and I don't think you can scale out to everything you need governance to cover with that product, while supporting provisioning and deprovisioning.

I did an impromptu survey at Gartner 2 years ago and asked everyone I could how many apps they'd connected to over how many years with Sailpoint, and it was overwhelmingly 10-20 apps over 3-5 years.   That's not good enough in my opinion, and I've seen IG deploy to thousands in less than 3 years.

Don't get me wrong, I think Sailpoint's interface for reviews was great a decade ago, but I don't think they've updated their technology much.  I think IG had parity with Sailpoint around version 2.5, and its just improved since.

I might be biased, but its an honest opinion.

--Jim

Sailpoint IIQ has this installation instruction for MS SQL:

To avoid deadlocking, ensure that these settings are set to true for your SQL Server database:

ALLOW_SNAPSHOT_ISOLATION

READ_COMMITTED_SNAPSHOT

Have OT engineering 'forgotten' this setting or is it a deeper thing?

Regards,

Tor Harald Lothe

We had this issue recently at our client...

The enabling of the option “is read committed snapshot on” on database level solved all lock issues we had. The DB admin told us that this is a quite common issue and Identity Governance is not only one application where they needed to set this setting.

So, I am also curious whether there is a deeper thing and if yes, I would like to know it ;)

Hopefully someone in engineering is reading this and can provide a qualified answer :)

I'm with you, and I anticipate this decision will hurt OT/Net-IQ market share...

If so-called deadlocks happen due to "too massive number of concurrent changes" then IG should behave less than as an intruder trying to hack or DDoS the database, with some sort of queuing/paging mechanism.

Also I wonder if the investment in that kind of smart(er) mechanism is less or more compare to the investment in rock-solid migration scripts for customers hat are on MS-SQL today and will need to migrate tomorrow.

All in all this is a risky decision and I'm convinced some customers will fly away...