Thank you for that! I'll have a bit of a play, later.
However - that wasn't the crux of my problem. And I did solve the problem. I discovered that field mon__qadi01 in the mon_mstr record holds the database "usr" number. That allowed me to identify the user who had set the record lock --...
If I have a long-running DB transaction I can get details like tty and PID. How can I match this with QAD details to identify the "real" user?
The usercount.log has information - but I can't see how to connect it with details from OE.
Can anyone help me?
OK, I get it, the comments were poking fun at "managed" DBs.
Tom is right - When the DR server is "just" a DR server it has a large amount of unused memory. For the next few months I have some "heavy" and time-sensitive jobs to run and just wanted to temporarily use all that memory to help...
I got the answer - I found a test server that was set-up as "managed" and did a test. You are right - the -B value in the pf file wins.
My problem was this ... I have a DR server that is configured to be a mirror-image of a prod server. Although we're licenced to allow running...
In a "managed" DB:
If this is set: blocksindatabasebuffers=8888 ... in conmgr.properties.
And then I set: -B 9999 ... in the pf file (pointed-to with otherargs=).
Which one takes precedence?
(I'd try it except that setting up a managed test DB is so much hassle.)
We're using 10.1B. (OLD! Yes, I know.)
I have to export full tables in csv format to give to a third party. Some of our CHAR fields contain new-line characters - which completely bamboozles them - even though they are quoted.
As far as I can see OpenEdge supports choosing a field...
I agree with all above comments - getting lock details via _Lock on any OE version prior to 11.4 is inviting some big trouble. On a large, busy, production system it can take HOURS to make one single pass through _Lock - and at the same time it will impact system performance dreadfully.
Thanks very much for the replies.
I was aware of the technique you mention - I saw it demonstrated at a Progress conference. Unfortunately we use an application where the licence precludes us from making any schema changes. I have made the vendor aware of the issue but they have not agreed to...
OE 11.6.3.017 on 64-bit Solaris
We have a 2 TB DB (actually 6 DBs that 'act' as one) - and we are in the process of migrating from 10.1C to 11.6.
I just read Tom Kincaid's blog about partitioning - in particular in an environment where very large tables are involved. He used an example of...
It was due to my lack of familiarity with table security .... I didn't appreciate that I needed to separately specify -U / -P for each database. Once I fixed that everything works just fine.
Thanks for your help everyone!
I have done more testing. The problem happens for each table where Can-read is set to "!,*" (rather than "*").
To isolate the problem from the script I'm testing - I have tried compiling using the Data Dictionary and I get exactly the same result - failure for any table where Can-read is "!,*".
Thank you Tom. (I should have worked that out for myself!)
Unfortunately, however, it has not solved the problem - even after providing a valid user and password I still get the same error.
Any suggestion welcome on how I can fix this.
OE 10.1C enterprise + Solaris 10
I sometimes need to recompile all the .p files in two directories - close to 1,300 files in total and I'm developing a script to do it. It works fine for most programs - but for some I get an error like this...
Thanks a lot. I'm getting the developers to review this urgently. I suspect that whoever originally set-up this table was "clueless" about how indexes work. I feel sure that two (maybe more) of the indexes need a few more keys added to them. I'll let you know what they find!
OE 10.1C on Solaris. (Heading for 11.6 Q1 next year.)
I have collected two months of tableStat in indexStat into an Excel report to analyse. Several "interesting" things for me to chase - but one thing stands-out as being quite strange; something I haven't seen before.
The VST details are...
Thanks for the replies - it's always very helpful getting multiple opinions, especially in the domain of DBA, because "the World is on your shoulders".
I don't see any real variation in opinion. It seems that the consensus is:
* Writing probkup files to disc is so reliable (especially with a...
I appreciate the reliability issues with tape and I'd never write a probkup to tape without including redundancy with -red - although even then I wouldn't choose a value as low as 9 for -red; maybe 50 to 100.
If a backup goes to disc - and then to tape, I wonder whether adding redundancy to the...
OE 10.1C (moving to 11.6 next March.)
We have multiple production DBs, totaling about 2.3 TB. At present they are backed-up using probkup online - to disc files - and later those files are copied to tape.
The existing scripts specify "-red 9". I understand what the "-red" does...
OE 10.1C0407 on Solaris. (Soon migrating to OE 11.6.)
I am new to this site. I wrote this short piece of code to show me info about _IndexStat:
DEF VAR naym AS CHAR.
DEF VAR i AS INT.
DEF STREAM xx.
OUTPUT STREAM xx TO /tmp/ronz.
FOR EACH _indexstat NO-LOCK