Re: [U2] Unidata replication
On Mon, 4 Sep 2006, Steven Frost wrote: Hi, I was wondering if anybody uses rsync to keep a development database in step with another system between 2 tru64 Unix Alpha boxes. At present we use rcp after first putting the source data in read-only (dbpause) mode. But this copies every file regardless of whether any changes have been made. I think rsync copies changed files either by comparing datestamps and file size, or doing block checksum comparison. I use rsync with Unidata on Solaris without a hitch. I know others using rsync on HPUX and AIX with similar success so I don't expect you'd have any trouble. rsync is nearly flawless when copying changed data. About the only trouble rsync runs into with U2 databases is if you have a file that changed from static to dynamic hashing - rsync is really unhappy if something that was a file becomes a directory (with the same name) or vice-versa. I've been using rsync to replicate our production database to other servers (backup, testing) for several years. After the initial copy, it's really fast. If you use rsync in conjunction with some sort of filesystem snapshot, you can replicate with only a few seconds of downtime on your production server. Jeff Butera Administrative Systems Hampshire College [EMAIL PROTECTED] 413-559-5556 "You're not right, Daddy" my 3-year old showing her wisdom --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Unidata replication
Steven, We use rsync a lot and in Redhat is works very well. As you say, rsync works by firstly checking the timestamps and skipping the file if they are the same. If the file is different, it does a checksum on a piece of the file and compares that to a checksum on the remote dest and only copies that piece of the file if the checksums differ and then moves to the next piece. Our primary uses: 1. Copying snapshots taken on the san down to local disk. 2. Disk to disk backups (excellent for this). 3. Remote DR location copies - also excellent for this. 4. The situation you describe, having a dev version of a live account. We do the dbpause, take a snapshot and dbresume (app. 1 to 2 seconds) and then do the rsync of the snapshot. If you are going to do the rsync inside the dbpause I would do a couple of rsyncs first to get the remote data in a similar state, do the dbpause and run another rsync prior to the dbresume although you still can't predict the database pause time as someone may have come in with a big update between the rsync's. Some other points: 1. You can choose the transport layer (ssh or rsh - we use ssh). By using ssh it uses the same trust relationship you may have in place for other automated ssh tasks. 2. You can compress/decompress on the fly using the z switch. This gives an excellent effective transfer rate on rsyncs to remote sites with slower network links. 3. It is very robust, you can just break it and carry on later. 4. To play nicely on some slower speed links or if you are worried about server load, use the --bwlimit switch to slow the transfer down. HTH Adrian Cavalier Bremworth ltd Auckland, NZ On 9/4/06, Steven Frost <[EMAIL PROTECTED]> wrote: Hi, I was wondering if anybody uses rsync to keep a development database in step with another system between 2 tru64 Unix Alpha boxes. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Unidata replication
Hi, I was wondering if anybody uses rsync to keep a development database in step with another system between 2 tru64 Unix Alpha boxes. At present we use rcp after first putting the source data in read-only (dbpause) mode. But this copies every file regardless of whether any changes have been made. I think rsync copies changed files either by comparing datestamps and file size, or doing block checksum comparison. We copy about 60GB down a long 300km fibre 10M/bit pipe which takes 30 hours, so doing a 'changed blocks' only rsync process would save a lot of time. Steven Frost POWERCO 35 Junction Street Private Bag 2004 New Plymouth New Zealand Helpdesk 0800491491 DDI: +64 6 759 6583 Fax: +64 6 759 6253 Mob: +64 274 403940 Email:[EMAIL PROTECTED] Web: www.powerco.co.nz # This e-mail message has been scanned for Viruses and Content and cleared by MailMarshal # * *** CAUTION: This email and any attachments may contain information that is confidential. If you are not the intended recipient, you must not read, copy, distribute, disclose or use this email or any attachments. If you have received this email in error, please notify us and erase this email and any attachments. You must scan this email and any attachments for viruses. DISCLAIMER: Powerco Limited accepts no liability for any loss, damage or other consequences, whether caused by its negligence or not, resulting directly or indirectly from the use of this email or attachments or for any changes made to this email and any attachments after sending by Powerco Limited. The opinions expressed in this email and any attachments are not necessarily those of Powerco Limited. * *** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Using DICT items in basic program
Tim/Mark You both make good points. Mark was responding to a specific requirement (how to get a single field for a single record) with one working and largely cross platform solution. Obviously getting a tranch of data requires a different solution. I don't think Mark was seriously suggesting that a million executes is a way to go. Personally I would now look towards XML as that seems to be the best current option for integrating the enquiry and development languages - finally something native to close that gap in the PICK model - though in the past I have used everything from REFORMAT (slow but predicatable) to creating compound I Descriptors of the form: CONVERT(@FM:@VM:@SVM,CHAR(1):CHAR(2):CHAR(3),field1:@FM:field2:@FM ...) etc and doing a SELECT .. SAVING that descriptor. Each ReadNext then gets an entire row - just CONVERT() the delimiters back again - and the result is extremely fast. Doesn't work well with WHEN clauses though - but then few things really do :( Tim's point about DOWNLOAD does have some merit. But Mark is an old pro (sorry, forgive the 'old' bit ! ) and I'm sure he writes his utilities in a way that other developers can work out what they do . Calling a utility without looking to see how it works first - well that's just lazy. And it's not just MV that will screw up in those cases! You wouldn't expect to call a SQL Server or Oracle stored procedure without some DBA's approval, would you? Brian --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Using DICT items in basic program
>Timothy Snyder stated: >...system efficiency should always >be a key consideration in developing software. BIG AMEN. This statement should be printed in BIG BOLD letters and framed over every developer's desk. System efficiency is the responsibility of every developer, not of the machine. Forcing a solution that works at the expense of performance and/or readability is no solution at all. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] up-arrow w/command stack
Hi, I tried the code listed below and whilst it changed the command prompt to be preceeded by the path, I had no success with the up-arrow scroll-through-command-stack ... which is what I was really after. I am using Universe PE & Dynamic Connect. Any help would be greatly appreciated. Kym At 07:19 AM 31/08/2006, you wrote: Cool, just tried it, what version of UV is this available from? Or scroll forward or left and right to edit the command. Ain't life great! Roy I've been using a variation of the code snippet Bob Woodward posted a couple of weeks ago to change my UV prompt to display the current account: 0001: ACCOUNT = FIELD(@PATH,'/',DCOUNT(@PATH,'/')) 0002: STELPROMPT = ACCOUNT:'>' 0003: STELPROMPT<2>= ACCOUNT:'>>' 0004: STELPROMPT<3>= '+' 0005: ASSIGN 1 TO SYSTEM(4001) 0006: ASSIGN STELPROMPT TO SYSTEM(4002) I just discovered that if you use this with VT220 emulation, your up-arrow will let you scroll back through the command stack and execute a previous command by pressing . This discovery has made my day :). --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Using DICT items in basic program
[EMAIL PROTECTED] wrote on 09/03/2006 01:11:43 AM: > Anyone can create an example of extremes to invalidate any suggestion. I didn't really see one million records as being extreme. That's really not a very big file in today's world. Since many people here are working on large systems, I just wanted to give them a heads-up before they implement logic that drags down their systems. You never said this was for only small sets of records, so I felt people needed to be aware of the limitations. Many people who come here are new to the MV world, and we need to look out for them. > If I were intending to process 5 million records as you would suggest, I > would write a simple program to create the csv's. I create many of these as > programs for their recurring use. I use download for the one-shot simple > projects. The problem is that somebody could inherit the system years later, see something called DOWNLOAD, and assume it will work for their needs. Unless there are built-in warnings that say they should only process VERY small data sets with this logic, they're going to get bitten. And we all know that one-time programs often make into production. Who here has never had that happen? :-) > Besides, so what if it did 5 million executes. These systems can handle it. I know the common thinking these days is that the hardware can handle anything that programmers throw at it, and that programmer time is more expensive than hardware. Therefore, programmers should just put something together that works and let the system handle it. If not, you can always buy more hardware. When programmers think that way, their employers end up bringing in people like me to make it right - not that I'm complaining. :-) With one line of BASIC code you can consume an entire CPU. If your system has four CPUs, that's 25% of the entire system's capacity! Run that program in four different sessions and you've bogged down the entire system. Yes, hardware has come down in price over the years, but nobody's giving away CPUs yet. Also, the fact is that faster, more powerful systems very often exploit inefficient coding practices, and can create some very nasty bottlenecks. > Time or processor consumption wasn't an issue in the original request Again, just warning people. It's my belief that system efficiency should always be a key consideration in developing software. I acknowledge that you shouldn't agonize over every CPU cycle, but it doesn't take that much longer to consider how coding and implementation practices will impact the entire system. Unfortunately, performance is generally seen as a problem for the SAs and DBAs to solve. In the VAST majority of cases that I've come across, the best performance improvements come from cleaning up the application code. Please understand that I'm not picking on anyone here. Just trying to help people understand the consequences of the decisions they make while developing systems. When systems perform sluggishly, there's a tendency to blame that oddball Uni-whatchamacallit database. The more we all do to keep the application humming along, the better off we'll all be. And if anybody out there isn't sure how to make that happen, there are plenty of us out here that are willing to help out. [Wipes brow and steps down from soapbox] --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
