July 8, 2013
I’ve been recently working with a couple of customers who were dropping database columns from their schema on Oracle, and the drops were taking a long time to complete. In one instance, the customer estimated it would take 50 hours to drop a bunch of columns from their contact table. In another, a customer observed that dropping two columns from table_site_part took over two hours. Dropping 3 columns from table_contact took over 1 hour. These long execution times can disrupt normal operations – especially those environments with limited maintenance windows. Dovetail’s schema editing tool (Schema Editor) and Amdocs schema editing tools (ddcomp, SchemaManager) all do the same basic operations when it comes to dropping columns. Basically they all do this: ALTER TABLE table_name DROP COLUMN column_name; There’s a better way. Set Unused On large tables the process of physically…
SchemaEditor improvements when dropping columns on Oracle
July 8, 2013
I’ve been recently working with a couple of customers who were dropping database columns from their schema on Oracle, and the drops were taking a long time to complete. In one instance, the customer estimated it would take 50 hours to drop a bunch of columns from their contact table. In another, a customer observed that dropping two columns from table_site_part took over two hours. Dropping 3 columns from table_contact took over 1 hour. These long execution times can disrupt normal operations – especially those environments with limited maintenance windows. Dovetail’s schema editing tool (Schema Editor) and Amdocs schema editing tools (ddcomp, SchemaManager) all do the same basic operations when it comes to dropping columns. Basically they all do this: ALTER TABLE table_name DROP COLUMN column_name; There’s a better way. Set Unused On large tables the process of physically…
February 14, 2013
Are you running a Clarify version prior to Clarify 12.5? Is your Clarify database running on a version earlier than MS SQL Server 2005 or Oracle 10? With the news that MS SQL 2000 will no longer be supported by Microsoft in March, we’ve been receiving a lot of inquiries this month about our Clarify Infrastructure Upgrade Services. While we haven't marketed it as a service in the past, our team has extensive experience upgrading RDBMS Infrastructures for Clarify clients. It’s very common for organizations that have implemented Clarify over the last 20 years to lag behind on the Clarify version they are running and for good reason. Clarify upgrades are costly, time-consuming and the new features are often not the best fit for their business model. If you’re running an older version of Clarify and need to upgrade…
I have some software that generates SQL we support multiple versions of Microsoft SQL Server and Oracle. I ran into a failing test on Oracle today that was totally unexpected. [Test] public void Case_History_containing_a_queue_tag_should_be_destined_for_that_queue() { string queueName = "SUPPORT"; string caseHistory = String.Format("case is in queue {0}", queueName); string caseIDNumber = "275"; SetCaseHistoryForCase(caseIDNumber, caseHistory); string ruleText = String.Format(@"(case_history contains '{0}') -> ""{0}""", queueName); string[] queues = AutoDestRule.RunRule("case", ruleText, caseIDNumber); Assert.AreEqual(1, queues.Length); Assert.AreEqual(queueName, queues[0]); } The Gist There is a bit of noise in the test but the gist is that RunRule() generates and executes the following SQL: Here is what the database looks like for table_case: id_number case_history "275" "case is in queue SUPPORT" The test passes in Microsoft SQL Server but fails against Oracle. There is no difference in the SQL being generated between databases. I fired up Query…