Recent content by stephenpyle

Progress doesn't have anything to add... they point to VMWare in all of their issues and give me suggestions that do not explain why just this server does it. All the VMWare issues they suggest would affect all the VM's... Their last suggestion is what we've been talking about anyways - which...

We are fully patched up... we moved to VM's so we could be. The old physical server had a full C:\ and we just couldn't keep enough space on it. VM allows us to expand that as necessary. We have a ton of resources available for these servers... we have increased... decreased... changed every...

I have run it as many ways as I can try. Most of our backups are through OE Management scheduler so I usually run that but have also run it from the command line a lot with or without the old BU being there.

Considering I have taken backups on multiple test VM's on the same server all day while the system is and is not under load - and the results have been similar - I think in our case, load has contributed to a +/- 20 minutes on the problem server and more +/- 5 minutes on the other servers. Just...

The BI file is large on this server but the time to back it up is small and the BI size doesn't seem to bother the other backups on similar VM's in the same way. I forgot to truncate it when we were switching and haven't been able to take it down to eliminate that possibility. I did truncate it...

That's the funny thing... moving files are speedier than on the physical server. And - we are not doing any snapshots... even if we were - it's only effecting this one p2v. Our other p2v is slow but still a 1/3rd of the time as this server and has less resources.

Of course lol Replication seems nice but you never know when you need to roll back. And we're still archiving AI files as well ;) We are writing locally and to the same disk the DB is on (this worked fine on the physical server we copied). I am sure it causes issues but test servers are not...

Server: Windows 2012 Progress: 10.2B08 DB Size: 180GB We just took our physical live server and did a p2v to move it to virtual. We already had moved our Roundtable server and had no issues. The one thing I forgot to test was the backups. We do have Replication but we run backups for...

Apparently, I need to not check the "Use Application User ID for Auditing" (like all the docs I read) in the Database Options and then restart the db... I think I tried this before and did not restart.

I was afraid of that... our ERP breaks when you change it to not accept blank user id's. We already changed access to the whole database to just the programmers - so that no one else could compile against the database or run anything against it.

My actual issue is not even to the application level. SOX auditors are wanting us to track schema changes so the only policy I have in place is for that. All I am doing is - opening the data administration, connecting to the database, and making a schema change. More data on the actual schema...

I have Auditing up and running in my test environment running OpenEdge 10.1C0203 After making a schema change from the Data Administration screen and I pull data from _aud-audit-data, the _aud-audit-data._user-id is all blank. I am logged in using a user/pass... I have "Use Application User ID...

We are looking at building a new server and my director is asking me if it would help performance. On the low cost end, I have read desktop reviews talking about bad firmware causing slowdowns over time and other problems so I wasn't high on the idea... I am sure some more "higher end" products...

So is anyone trying Solid State Disks for their DB? The only advice I am digging up is with using them for the BI and TMP files... Anyone have anything to add to this? Thanks Stephen