If I have a trigger defined to fire "BEFORE INSERT,UPDATE", is there a way to determine whether the event is question is an INSERT or UPDATE? The table involved has at least one field defined as "not null", so at first blush I'm tempted to use somet...
The objective is to have a backup of a relatively large (30gb) database that can be restored rapidly, with a very narrow window of potential data loss, as this database is in use 24x7x365. This should all be documented in such a manner that we can a...
Over the long weekend, I upgraded our database from SQL anywhere 10 to SQL/A 16. It is hosted on WIndows 2008/R2, hosted on VMWare. I did the upgrade 'properly' in that I did a db unload/load to create the .db file from scratch. In the test environm...
Good Day. Our environment has a production database server, and a backup server that is sometimes used for training & testing. We are upgrading from version 10 to version 16, and I'm struggling with licensing. I purchased two CPU licenses, with th...
We've been running it on VMWare since version 10. Early efforts had server-local storage, current config is an HP storage array connected via iSCSI over 10GB fiber. No issues to report.
It's ISO, so "checking the box" mostly means that we show that we have the instructions available, and have confirmed that if followed, they will work -- janitor not required. Even as we speak, I am doing testing and documentation of the recovery pr...
I may have drawn an inaccurate picture. The primary server is running in VMWare with HA, connected to redundant iSCSI SANs, with geographic separation of redundant devices. So the primary mission for this exercise is protection from 1) catastrophic...
Having a copy of the previous backup is a good idea. It was always part of the plan, but I am kind of "backing in" to this, making sure I get the right files to perform the recovery. Then I'll figure out many redundant copies I want. Because we wan...
The other question I had was whether applying the transaction log from the initial full backup is required prior to applying the most recent transaction log, since the only time the log is truncated is when the full backup is accomplished.
