<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>Question Re: Schema Update taking a long time in Technology Q&amp;A</title>
    <link>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaa-p/13848049#M4878892</link>
    <description>&lt;P&gt;If there are a lot of 1 or 2 digit NUMERIC values being converted to INTEGER then the space for each of them increases from 3 to 4 bytes. If the pages are packed with rows then many rows will be split which causes time.&lt;/P&gt;
&lt;P&gt;An alternative might be to UNLOAD TABLE to a file, DROP TABLE, CREATE TABLE with the new data types, and then LOAD TABLE. The end result would be a well-organized table with no page splits.&lt;/P&gt;
&lt;P&gt;The 10 GB might be partly due to the giant checkpoint log; it might be freed up when you restart the server.&lt;/P&gt;</description>
    <pubDate>Thu, 08 Jan 2015 19:48:36 GMT</pubDate>
    <dc:creator>Breck_Carter</dc:creator>
    <dc:date>2015-01-08T19:48:36Z</dc:date>
    <item>
      <title>Schema Update taking a long time</title>
      <link>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaq-p/13848048</link>
      <description>&lt;P&gt;We have a table with approxiamately 100 million rows in it.  &lt;/P&gt;
&lt;P&gt;Here is a shortened table definition:
&lt;/P&gt;&lt;PRE&gt;CREATE TABLE "DBA"."in_invoice_detail" (
"company" NUMERIC(3,0) NOT NULL,
"invoice" NUMERIC(6,0) NOT NULL,
"order_seq" NUMERIC(5,0) NOT NULL,
"date_entered" DATE NOT NULL,
"user_name" VARCHAR(10) NOT NULL,
"brand" NUMERIC(4,0) NOT NULL,
"size" NUMERIC(3,0) NOT NULL,
"invoice_seq" NUMERIC(3,0) NOT NULL,
"qty_ordered" NUMERIC(5,0) NULL,
"qty_sold" NUMERIC(5,0) NULL,
PRIMARY KEY ( "company" ASC, "invoice" ASC, "order_seq" ASC, "date_entered" ASC, "user_name" ASC, "brand" ASC, "size" ASC, "invoice_seq" ASC );
&lt;/PRE&gt;
We need to convert our brand, size columns from numeric to integer.  I have tested this several times and it takes about 4 hours and expands our database by about 10 GB.  &lt;P&gt;&lt;/P&gt;
&lt;P&gt;Can anyone give me some insight on why it might take this long and grows our database?  Any tips to make this conversion more efficient?&lt;/P&gt;
&lt;P&gt;Thanks,
Brian&lt;/P&gt;</description>
      <pubDate>Thu, 08 Jan 2015 16:10:45 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaq-p/13848048</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2015-01-08T16:10:45Z</dc:date>
    </item>
    <item>
      <title>Re: Schema Update taking a long time</title>
      <link>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaa-p/13848049#M4878892</link>
      <description>&lt;P&gt;If there are a lot of 1 or 2 digit NUMERIC values being converted to INTEGER then the space for each of them increases from 3 to 4 bytes. If the pages are packed with rows then many rows will be split which causes time.&lt;/P&gt;
&lt;P&gt;An alternative might be to UNLOAD TABLE to a file, DROP TABLE, CREATE TABLE with the new data types, and then LOAD TABLE. The end result would be a well-organized table with no page splits.&lt;/P&gt;
&lt;P&gt;The 10 GB might be partly due to the giant checkpoint log; it might be freed up when you restart the server.&lt;/P&gt;</description>
      <pubDate>Thu, 08 Jan 2015 19:48:36 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaa-p/13848049#M4878892</guid>
      <dc:creator>Breck_Carter</dc:creator>
      <dc:date>2015-01-08T19:48:36Z</dc:date>
    </item>
    <item>
      <title>Re: Schema Update taking a long time</title>
      <link>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaa-p/13848050#M4878893</link>
      <description>&lt;BLOCKQUOTE&gt;
&lt;P&gt;If there are a lot of 1 or 2 digit NUMERIC values being converted to INTEGER...&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;
&lt;P&gt;Just to add/clarify: The possible increase (or decrease) in required storage will depend on the &lt;STRONG&gt;actual values&lt;/STRONG&gt; of the NUMERIC field (or on formerly stored values of the same row), not on the declared precision/scale.&lt;/P&gt;</description>
      <pubDate>Fri, 09 Jan 2015 03:57:42 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/schema-update-taking-a-long-time/qaa-p/13848050#M4878893</guid>
      <dc:creator>VolkerBarth</dc:creator>
      <dc:date>2015-01-09T03:57:42Z</dc:date>
    </item>
  </channel>
</rss>

