Search results

Hi All, The existing DB (Size 2 TB) on 9.1E version has got all variable extents (963 tables split across 55 data and 55 index area) where the segregation of tables are based on functionality which doesn't seem to be a good design. We are migrating to 11.6 version; as part of our migration we...

@TomBascom - What happens in case of system crash if we go with internal SSD or disks. Basically how do we handle if we have to recover from system failure, or to build new one or attach to some stand-by system.

@Rob Fitzpatrick - Sure, will use these parameters/values and test the same.

Cool, these are good numbers to know as our system may end up in similar configuration or bit more. I will do more testing on different servers we have and get some statistics posted as well. Thanks @RealHeavyDude @Rob Fitzpatrick...!!

FYI - Our application can be classified under records management domain where we face very high CRUD operations on tables.

When I say Record Size it's Mean Record Size. Let's consider the below example; Table Name - # of Records, Table Size, Mean Record Size T1 - 120969962, 28.8G, 98 [120.96 Million Records] T2 - 35389652, 40.2G, 315 [35.9 Million Records] In the above example even though T2 has way too less # of...

Got it. Thanks @Rob Fitzpatrick.. How about the rest, i mean the table classifications? Are you fine with the table being classified this way?

@RealHeavyDude - Thanks!

Hi All, I see scripts using prostrct builddb on 9.1E machine. I assume it's used when the area or schema gets corrupted. But at the first time when am trying to create a new DB and create a structure to it, I guess I have to use prostrct create. Is my understanding right? Or can I do the same...

We have a new approach proposed from our DBA team and wanted to see if it will be a recommended one. As per this thread we have classified tables based on below parameters; 1. Record Size 2. Transaction Operations (CRUD Report) 3. Mean Record Size Considering these parameters, I can classify...

Hi All, As part of our migration project we have option to choose either NFS, NetApp iSCSI or San Pure Array. Our DB size is 2 TB. Which one of this would you recommend to use from performance stand point? Regards, Saravanakumar B

Thanks Tom, I took the list of 900 tables to an excel with then list of records. As you pointed out there are around 6 tables that are > 100GB and rest are less than 50 GB. I guess I can put those 7 tables into separate areas. I have also categorized it based on CRUD operations report, mean...

Thanks everyone. I am giving a try on the test machine based on above discussion and advises; will keep you posted on further clarifications.

@Rob Fitzpatrick - Sorry for the delayed response. I was working in classifying the tables to different areas based on the information and advice from this thread. One quick question, you have mentioned saying you will put tables which are very large size into a new area. I have tables ranging...

@Rob Fitzpatrick - I am a newbie to Progress DB Admin and pretty much a progress programmer. Sorry for asking dumb questions; I did monitor during parallel load and the below was the statistics I got; Parallel load stats using promon: Total Per Min Per Sec Per Tx Commits 5946 35676...

@Rob Fitzpatrick - I just checked with the management, looks like I will have a weekend (but again we have close to 2 TB of db to migrate, backup's and testing).

@Rob Fitzpatrick - I am performing a migration to a test machine to see how much downtime I will require to get this done and go back to my management to see if we have that time or come up with some other strategy. I wanted to check if I/O contention is the issue in this case. Should I be...

@Rob Fitzpatrick / @TomBascom - Looks like PROUTIL (independent run; in serial mode) executes faster than using proserve (parallel mode). I think it should be the other way around - right? I don't understand what could be the real bottleneck in this case.

@Rob Fitzpatrick - "More thread with few cores will just lead to more context switching"; Is that the reason why parallel load consumes ~23 minutes whereas loading tables one by one without using proserve and just proutil consumes ~6 minutes? Is this the bottle neck in my case? Yes, we should...

@Rob Fitzpatrick - Yes its VM configured 1-core per CPU and we have 4 CPUs on this VM. Will increasing cores helps in parallel load? @TomBascom - Thanks Tom, will change my approach to 'one big index rebuild after everything is loaded' approach.