- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: About use of RAB$V_NQL No Query Locking
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-14-2009 10:30 AM
тАО09-14-2009 10:30 AM
Re: About use of RAB$V_NQL No Query Locking
Good!
>> the real situation is that during the night run a lot of batch processes, many of then them only read the files sequentially to generate reports and files to send to another aplications outside Alpha plataforms
Ok, so maybe you want to try completely different approaches.
- Use (Host-Based) shadowing to detach a member with a clone of a file.
- Use BACKUP/IGNORE=INTERLOCK to take a readonly snapshot of the file. If you have the memory, then stick the copy into a RAMdisk for transfer + delete?
- my (customers) preferred solution is to use the commercial Vselect tool (EGH company, John Santos and friends) to take a sequential file extract, with or without selection criteria. Vselect can read indexed file faster than RMS can, and uses no locks.
- write your own, or commission someone to create, an extract tool. That's not too hard for specific cases, but more tricky for a solid, commercial solution. (Check out DIX)
- tune the file for bigger data bucket. The reduces ENQ/DEQ proportinally, exchanging them for cheaper Converts to/from NL.
>> and others processes modifying data on the same files, but it run slow I think could be by the high generated locks.
Or because the XFC cache does not get a chance to help?
>> I send a picture with the amount of locks during 24 hours and a MONITOR DLOCK from the GS1260 machine.
Good stuff, but I'd prefer to see more quantitative words around 'it run slow'.
Because that seems to be the real problem you are trying to solve and you have not convinced me yet that locks are the cause for that.
Cheers!
Hein.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2009 04:29 AM
тАО09-16-2009 04:29 AM
Re: About use of RAB$V_NQL No Query Locking
Thanks for your contribution, I only want that you review the attached information, where in my modest opinion the LOCK is the principal cause of the low performance. Could you tell me if agree with this conclusion?
Thanks a lot for your attention.
Jose
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2009 05:40 AM
тАО09-16-2009 05:40 AM
Re: About use of RAB$V_NQL No Query Locking
I don't 'see' any low performance.
What is the (end user) measurement for that?
Is the performance good for most of the day, but acceptable during the nightly (transfer?) jobs?
The system is busy and has High MPsync at the time to took the snapshots, but the full day picture shows a relatively healthy system during most of the day. Lots of usermode, little kernel/mpsync overhead... except around midnight.
I'd recommend switching to the dedicated lock manager to reduce overhead and turn the cpu locking MPsyncs into low priority kernel mode waits.
Given the amount of memory, I would certainly consider how you could deploy read-only file clones.
And if extracts and selects are seen as not fast enough, and critical for the end user perception / SLA's then I would looks at alternatives for that, such as the commercial tool mentioned.
At this point this topic start to become too much like 'work' for me, and you exceeded your 'first 15 minutes are free' quota from me. Maybe someone else will step up, or contact me offline.
Best regards,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2009 06:05 AM
тАО09-16-2009 06:05 AM
Re: About use of RAB$V_NQL No Query Locking
Regards
Jose
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-16-2009 06:25 AM
тАО09-16-2009 06:25 AM
Re: About use of RAB$V_NQL No Query Locking
Cloning can be an option, as can be sharding the data. There are other approaches toward increasing performance and parallelism.
One of the general approaches here involves the DECset PCA or such tool, and determining where the application(s) are spending the most time. OpenVMS locking (particularly on recent OpenVMS versions) is pretty speedy. Excessive locking can point to some underlying application or file-level issue.
I've also seen the NQL knob used for an on-line archive; to work around some other application that's holding a lock for too long. For similar reasons around why BACKUP /IGNORE = INTERLOCK can produce questionable results, the use of NQL here can be problematic, too.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО09-18-2009 05:57 AM
тАО09-18-2009 05:57 AM
Re: About use of RAB$V_NQL No Query Locking
Ther eis a freeware solution bin Fekko Stubbe called DIX.
The extract would roughly look like (good luck with the Dutch comments!):
$ DIX FILE/FAST file -
/DES=$LINE - !een descriptor met een veld char*nnnnnn
/OUTPUT=x.x -
/WIDTH=nn - !groot genoeg om het record te bevatten, ander gaat dix wrappen
/DISPLAY=(NOALL,DATA) - !alleen de data, niet de offset/veldnaam
/FORMAT=PASSALL - !Unprintables zo laten als het is (anders worden het .tjes)
zoekterm [zoekterm]
zoekterm = RSE = Record selection expression. Tons of options. See HELP.
http://www.oooovms.dyndns.org/dix/
Hein.
- « Previous
-
- 1
- 2
- Next »