When using Microsoft SQL Server, enabling Read Committed Snapshot Isolation (RCSI) is one way to prevent reads (SELECT statements) from escalating into full table locks. Depending on your application this can either be a good or a bad thing. I’m not going to get into the why’s and why-nots of each strategy - this is a good article to read if you’re having a hard time deciding which strategy to choose and why.
So let’s say you want to enable RCSI on a fictional database MyDB. This can be achieved by simply issuing the following T-SQL:
ALTERDATABASE MyDB SET READ_COMMITTED_SNAPSHOT ONGO
To check that it was successfully enabled, you can check the System View sys.databases:
WHERE [name] ='MyDB'
If it returns 1 then RCSI was successfully applied, you’re done! Unless…
To connect to a box on your network that is running Oracle Database, you will first need to allow connections to Oracle through your firewall.
If you’re running CentOS, RHEL, Fedora or any other Linux variant that uses iptables, use the following commands to create a firewall exception (Assuming you’re running your listener on port 1521 - check with sudo lsnrctl status):
I was tasked with writing some code to pull all the research project data that we’d collected over the past 10-15 years into our new J2EE-based product, Kuali Coeus. The legacy system ran off SQL Server which is a lot more forgiving of character encodings and string data in general than the new system (which runs off MySQL).
It had taken me a while to figure out a way to map all the old data onto the new data structures, but I felt like I had done a pretty awesome job. The few batches I had tested it with all passed its tests with no problems. However when I unleashed it on a full dataset (some 6000 rows), about 60% (roughly 2 hours) of the way through, it crashed, and rolled the ENTIRE thing back.