1) If the primary database server dies, is it possible to allow users to connect to the secondary database so as to continue working with Read/Write access?
You have to manually failover to the secondary server as logshipping does not have a built-in mechanism to support automatic failover.
Once you failover, your application/s (provided they are using ADO.NET or SQL Native Client) can leverage the Failover Partner=Secondary_server
Brent has blogged about failover partner:
you don’t need to use database mirroring to use Failover Partner. Whether you’re using database mirroring, replication, log shipping, or duct tape, much like the honey badger, your applications don’t care. They’ll just try to connect to the Failover Partner name whenever the primary server is down.
.
2) Once the primary server comes back online, is it a difficult process to switch back to the primary database server?
Traditionally, depending on the size and number of database that are invloved in logshipping, it may or may not be difficult.
Database size and your network bandwidth matters a lot. Normally, you just have to resetup log-shipping. Meaning - point all your apps to primary and in background, do a full backup of primary, copy that to secondary server and restore it with no-recovery with subsequent log backups.
To minimize the downtime, you can use "Reverse logshipping" will prove to be a huge help.
3) Will changing the Recovery model to Full (from simple) have any issues?
Yes. Changing recovery model breaks the log chain. Paul Randall talks in his myths section. Also, see below chart :
4) Will my existing backups (using Symantec Backup Exec) be affected by enabling log shipping and switching to a full recovery model?
Once you setup logshipping, there is no need to take any additional log backups. In fact, any adhoc log backups will break the log chain. Use COPY_ONLY backups.
As I mentioned above, any change to the recover model should be followed by a FULL backup. That will be your base backup. Any adhoc backups (even full) should be taken with a COPY_ONLY option as if you are relying on differential backups then it will be an issue if someone takes an adhoc full backup.
As a side note, always fully document, test, test and test + automate (as much possible) your disaster recovery strategy. See Paul's DR Poster for more details.
Your log backups are being done by the Log shipping process, that is after all what is there to do. So, you will generally not include log backups in your backup strategy but take into account how often your log shipping process runs.
You would only worry about taking full and/or differential backups against the databases involved in log shipping.
Best Answer
I don't understand your issue. You can definitely log ship while performing Full and Diff backups. Are you trying to have some manually performed version of log shipping? Performing a Full or Diff backup will cause no issues, log shipping just uses log backups so the chain will not be broken.
Have you actually tried this out, from your question it appears that you just think it will break.