Is it possible to setup replication/Mirroring to a database server which is not in our windows domain?
Yes but it will be more work to secure.
We have a database of size around 100GB. We have to replicate this data to a diff company which is in not in our windows domain. We are in central zone they are in pacific zone.
First we need to load all the existing data into their database and then we have to load data either every day once or it could be real time data transfer.
What are the best recommended options?
The two realistic options are Replication (Transaction or Merge) or log shipping. Unless you have someone who is good at replication I would go with log shipping.
I am thinking if it's one time a day then log shipping and if it has to be real time data transfer then mirroring. Can we do the real time transfer with transactional replication?
I don't think mirroring is a viable option. Replication will get you as close to real-time as possible but will require more effort than log shipping. Setting up, maintaining, documenting and troubleshooting replication between two time zones (something I have done in the past) can get complicated; especially between dissimilar AD domains.
My recommendation is to push back against real-time data if possible and setup log shipping; weigh the benefits of the real-time data vs the cost to set it up.
If it absolutely must
be real-time, however, then replication is the way to go.
-- Alan Burstein
Best practices for getting help on SQLServerCentral -- Jeff Moden
How to Post Performance Problems -- Gail Shaw
Nasty fast set-based string manipulation functions:
For splitting strings try DelimitedSplit8K or DelimitedSplit8K_LEAD (SQL Server 2012+)
To split strings based on patterns try PatternSplitCM
Need to clean or transform a string? try NGrams, PatExclude8K, PatReplace8K, DigitsOnlyEE, or Translate8K
I cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code. -- Itzik Ben-Gan 2001