Author |
Topic  |
lkerznowski
Starting Member
USA
22 Posts |
Posted - 07/18/2014 : 14:59:52
|
I tried the telnet with <domain> for both server, and both went through fine.
I just went to run the command from DB2 (the Mirror), and it gave me:
Msg 1405, level 16, State 1, Line 1 The database "extenddb" is already enabled for database mirroring. |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
|
lkerznowski
Starting Member
USA
22 Posts |
Posted - 07/18/2014 : 15:44:43
|
Alright. Thank you for everything. Very helpful learning more about SQL. |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
|
lkerznowski
Starting Member
USA
22 Posts |
Posted - 07/21/2014 : 12:02:41
|
Hey. I was looking back into to this, and think I may have come across an issue.
I was reading somewhere that when you take the initial Full Backup and Transaction Log that they should be stored on the Primary server, and then that folder is shared to the Mirror Server.
Our DB1 server is pretty full, so when making the backups, I had them saved to a shared location on the Mirror server's local files. Do you think that could be causing a problem that the Primary server maybe cannot verify it's ready for mirroring?
Just an idea. Let me know if you think that matters. |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
Posted - 07/21/2014 : 12:41:08
|
That's not an issue as you've already completed the restore of the full and tlog backups. That location is no longer needed after the restores are done.
It doesn't matter where those files get stored so long as the primary server can read/write to it and the mirror server can read from it.
Tara Kizer SQL Server MVP since 2007 http://weblogs.sqlteam.com/tarad/ |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
|
lkerznowski
Starting Member
USA
22 Posts |
Posted - 07/21/2014 : 13:00:23
|
No. Like I sort of mentioned before, we're using a TEST server on DB1. Basically, a couple of months ago, we created this server as a duplicate of our live one. We then used this TEST to mess with whatever we were trying to do before moving to the live. This TEST data is months old, and only gets "changed" for testing purposes.
So the Full Backup and T Log should be fine. Also, sometime in the last week when I was trying everything, I made a new back/tlog so those should be up-to-date still as no one has touched the database data. |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
Posted - 07/21/2014 : 13:12:37
|
Cool. I didn't think it was the issue as you should receive a different error.
At this point, I would recommend running a network sniffer to figure out where the issue is. Possibly a DNS issue. Now I'm going to get the names wrong here, but hopefully you get the idea. At my old job, servers were www.subdomain.domain.com and then there was an alias in the DNS record for www.domain.com. If we specified the alias in mirroring, we would get the error you are receiving. So we had to specify the whole thing.
Tara Kizer SQL Server MVP since 2007 http://weblogs.sqlteam.com/tarad/ |
 |
|
lkerznowski
Starting Member
USA
22 Posts |
Posted - 07/21/2014 : 13:17:19
|
Ours is setup in a similar x.x.com fashion, with a alias of TRACEYONE.
Do you think some of the issues could be a lot of the logon names and such I'm associating are being called through TRACEYONE\SQL instead of SQL.x.x.com? I do not think the issue is with the service logons, as I had transaction log shipping set up before (which needed this setup), and the TRACEYONE\SQL worked find in the services.
in the security sections of the servers I have permissions set under TRACEYONE\SQL. Should I try adding SQL.x.x.com and then change the logons in the services to reflect that? |
 |
|
tkizer
Almighty SQL Goddess
USA
38200 Posts |
|
Topic  |
|