I'm almost running out of disk space so I want to move 1 DB to a different hard drive.
It's a rather simple but lengthy action during a shutdown of IRIS.
But is this somehow possible under runtime in a stand-alone installation?
I'm looking for kind of a "local failover"
note: Mirror or Shadow is not an option.
input by Vitaliy Serdtsev ยท Apr 12, 2021
If something does not suit in the bundle
Backup.General:ExternalFreeze()/ExternalThaw(),
then can try the bundle
SYS.Database:DismountDatabase()/MountDatabase().
Or at all SYS.Database:Copy().
See the excellent reply in Developer Community
I'll place the content in a different Answer
Related
I am a newbie and I am working on a driver that tracks creation/write/modification on files. Now I have been told to work on Volume snapshot. I have seen the code of VSS that comes with Windows SDK.
But I have been informed to work on VSS at the kernel level, means I have to find out how I can use or communicate Windows Volume snapshot service through my driver. Please can someone give some inputs on this and try to help me because i googled a lot for Volume snapshot but did not get much help from there. Should I implement VSS Writer at the kernel level or something else to use the feature of Windows VSS service. Thanks in advance.
I think you should implement the VSS Hardware Provider.
Get the development document
http://msdn.microsoft.com/en-us/library/windows/desktop/aa381601(v=vs.85).aspx
Get the Sample Code
You need to install the Microsoft SDK--for example--7.1
Assumed that the SDK is installed under default path, access the path C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\winbase\vss\vsssampleprovider
Here you can find the sample codes.
Good Luck!
Should I develop a VSS writer or VSS provider : Neither. Incremental block level backup of files would require a FS mini-filter driver approach which, for the incremental time range Tn to Tn+1, should track block level writes happening on the live file. At time Tn+1, when the vss snapshot is taken, this minifilter should additionally track writes happening on the "file's view" sitting on the snapshot block device. The snap is not always read-only from birth. There is a brief time window in the VSS state machine during which the snapshot is actually writable so that various writers could do their thing (writes, updates, rollbacks etc). You could, in principle, also delete files from the snapshot while executing the onpostsnapshot callback (if you have a custom writer i.e.) The exact point in time when you'd need to stop live file tracking and start snapshot view tracking can be managed based on the completion of flush and hold writes IOCTL. So basically, at the end of snapshot, you'd have 2 change bitmaps : one that describes the writes on the live file and the other describing the writes on the snapshot view of the file. Merge these 2 bitmaps and then backup the changed blocks (based on the merged bitmap), off the snapshot block device. More or less similar scheme can also be applied for taking incremental block level backups of volumes.
I found this article on technet regarding this topic:
http://technet.microsoft.com/en-us/magazine/ff382717.aspx
Does microsoft have some benchmarks for various manual page file configurations?
Somebody told me that it is a good idea to create an extra partition on the drive with the OS with say 4.5 Gig and move the pagefile to this partition while disableing the first partition with the OS. Additionally it was suggested to manually set the page file size to limit 2 / 2 Gig.
In my eyes this makes no sense. Could someone comment on this?
I don't know if this answer will satisfy you, but I've seen an opinion, that if you place your page file on ext[2-4] file system (you need drivers to do this on Windows, of course), system performance will increase.
However, I unfortunately can't recall where I've seen this (it was somehow connected with writing file system drivers using Installable FIle System API).
I'm stuck trying to debug a problem which only occurs on my machine. It doesn't exhibit on any of the other devs' systems, nor on our production test server. I've tried pretty much everything I can think of short of completely wiping my hard disk and starting from scratch, or sneaking into the office in the middle of the night to swap my computer with someone else's.
This brings to mind the titular question, then: short of those drastic measures, what do you do when trying to resolve issues that no one else has? I'm open to advice that's general or specific.
[Not sure if this should be CW or not.]
Have you attached a debugger to the program to find the exact point of failure? That is what I would do first.
Sometimes third party software can be the root cause of these sorts of issues. Things like Anti-virus software install low-level filesystem and network drivers that can cause random intermittent failures. You can try killing all processes that aren't base OS services and your app.
Depending on your OS there are different tools that you can use to see what's going on under the covers. E.g. on Windows you can use Process Monitor to see what Registry keys it opens, what DLLs get loaded, etc. You can run this on your machine and on the success machines and compare to see if perhaps some required module is missing .
But seriously, use a debugger. That's what they are there for.
Two things:
I start with the obvious: What's different on your box? More memory? Odball PCI card? Different Microsoft APIs or service packs?
For oddball random software and/or OS crashes:
Check your system for heat issues.
Check your RAM for bad bits.
In this situation, I would try to check out the code and cleanly rebuild it from a different directory to make sure that there are no miscellaneous files in your working directory that are causing a problem.
If you are doing work against a database, I would also try tearing down the database and reconstructing it, possibly using a dump from another developer's machine.
Check the versions of any external third party software - database version, OS version, even software patches.
Look at the configuration on someone else's machine who doesn't have the problem and compare.
Get another developer to sit at your workstation and try to reproduce the problem and also go to their workstation and try it. True story - a fellow developer had a bug that he could only reproduce on his machine...it turns out that he was doing something slightly different in the GUI that no one else was doing (tabbing to a button and then hitting enter, everyone else just hit enter). It never occurred to him that other people might just hit enter to submit, because that "didn't make sense" to him.
How do I improve Subversion client update performance? It appears to be disk bound on the client.
Details:
CollabNet Windows client version 1.6.2 (r37639)
Windows XP SP2
3 GB RAM with PF Usage around 1 GB and System Cache of 1.1 GB.
Disk has write caching enabled
Update takes 7-15 minutes (when very little to update).
Checkout has 36,083 directories/files (from svn list)
Repository has 58,750 revisions.
Checkout takes about 2.7 GB
Perf monitor shows % Disk Write time stays near 90% during update.
Max Disk Read Bytes/sec got up to 12.8M and write got up to 5.2M
CPU, paging file usage, and network usage are all low.
Watching the server performance seems to show that it isn't a bottleneck.
I'm especially interested in answers besides getting a faster disk (especially configuration changes).
Updates from some of the suggestions:
I need the whole thing so sparse directories won't work.
Another client (TortoiseSVN) takes 7 minutes also
TortoiseSVN icon overlays have be configured so they don't cause the problem.
Anti-virus is configured to to skip that directory is it isn't causing the problem.
I experience exatly the same thing. Recently replaced Perforce with svn, but if we cannot overcome the performance problems on Windows me must consider another tool.
Using svn 1.6.6, Win XP and Vista clients. RedHat server.
My observations matches yours:
Huge disk-write activity.
Antivirus not a bottleneck.
No matter witch svn-clients are used.
No server or network bottleneck.
Complementary info
More than 3 times faster operations on:
Linux (Ubuntu).
Linux (Ubuntu) running on VirtualBox at Win Vista host.
Win XP running on VMWare at RedHat host.
Do you need every bit of the repository on your working copy? If you truly only care about particular portions of the tree, look into Subversion's Sparse Directories (a.k.a. "Sparse Checkouts") feature. It allows you to manipulate your working copy so it only contains those directories of interest.
Just as an example, you might use this to prune documentation, installer-related files, etc. Depending on what you truly need on your local machine, embracing this approach could make a serious dent in your wait times.
Try svn client version 1.5.. It helped me on my Vista laptop. Versions 1.6. are extremely slow.
This is more likely to be your network and the amount of data moved as well as your client. Are you using Tortoise? I find it to be a bit slow myself when moving that much data!
Are you using TortoiseSVN? If so, the Icon Overlays do slow down operations. If you go to TortoiseSVN Settings/Icon Overlays there are several settings you can tweak to control the level to which you want to use the Overlays, including turning them off completely. See if that affects your performance.
Do you run a virus checker that uses on-access scanning? That can really make it crawl. If so, turn it off and see if that helps. Most scanners will have a way to exclude specific directories if that helps.
Nobody seems to be pointing out the one reason that I often consider a design flaw. Subversion creates a second "pristine" copy of the checkout for offline operations. If you're checking out 4G of files, it's actually writing 8G to disk.
Compare a checkout to an export. That will show you the massive difference when writing those second copies.
There's nothing you can do about that.
Upgrade to svn 1.7
From Discussion of Slow Performance of SVN Update:
The update process in svn 1.6 goes something like this:
search the entire working copy, to see what's there at the moment, and locking it so no one changes the answer during the next steps
tell that to the server
receive from the server whatever new stuff you need, applying the changes to the files as you go
recurse over the entire working copy again, unlocking it
If there are many directories and files, steps 1 and 4 can take up a
lot of time. This would be consistent with your observation of long
delays with no network traffic.
Working copy format was changed in svn 1.7. Now all meta information is stored in SQLite database in root folder of working copy and there is no need to perform steps 1 and 4 any more which consumed most of the time durring svn update.
I've run into this problem before and the solution has usually been to restart IIS. Basically I've made a number of changes to a .wsc file on our server. But when it runs it doesn't run the new code changes I made. I've verified this with event logging at the beginning of the file and it doesn't show up.
My problem is that obviously restarting IIS on our production server is something I'm loathe to do, but we need this running today. I've tried re-registering the file but to no avail.
The server is a 32-bit Server 2008 OS. And the code is running, it still generates the file it is supposed to, but like I said, it's not using the latest changes.
Any other info I can provide, please leave a comment and I'll edit.
Thank you,
Jeff
Edit: Oisin, thanks for the reply and yes I know I hate VBScript, and anything related to it including these Window Script Components. I've expressed such feelings to my manager, but it's a dirty job and someone has to do it!
Yes it's using a Server.CreateObject to call the component.
ANSWER: I've since realized my mistake. I was only 'registering' it over and over, when I should have first 'unregester'ed it the 'register'ed it. Man I feel stupid, but haste makes waste as they say.
Thanks for the response and link!
Eek, you mean WSC as in a Windows Script Component? I haven't written one of them since 2000.
Are you loading it using CreateObject (e.g. it's registered as a COM object via regsvr32), or are you using a file-based moniker to load it? (not registered).
If it's registered, it probably is cached until app restart. If you switched to a file based moniker, e.g. like: Set o = GetObject("script:c:\path\obj.wsc"), you might get away with runtime changes to the .wsc file.
(man, how did I even remember this)
more info here - quick before it's archived! :D
http://www.microsoft.com/technet/scriptcenter/resources/scriptshop/default.mspx
-Oisin