Print ER diagram for a database in SQL Server

Uday,
right-click on the white background on the database
diagram and select Page Setup. You can select different
page sizes and scale ratios on this form.
Rgds,
Paul Ibison (SQL Server MVP)
You might also want to create "subject" areas by creating several individual
diagrams for the functional areas of the database instead of the entire
thing in one.
Sincerely,
Anthony Thomas

"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:02af01c4dc3c$1ce5b0a0$a601280a@.phx.gbl...
Uday,
right-click on the white background on the database
diagram and select Page Setup. You can select different
page sizes and scale ratios on this form.
Rgds,
Paul Ibison (SQL Server MVP)
sql

principal db in "principal, synchronizing" state, the mirror in "restoring"

We have mirroring setup for 5 dbs, 4 of which are synchronized and 1 which is in "synchronizing" state on the principal and "restoring" state on the mirror. Mirroring for all dbs has been working fine for the past several months and we have a witness that has allowed automatic failover in the past without problems.

This database has several bulk inserts performed throughout the day and am sure there is some latency due to the size of these transactions.

Not sure as to why this is happening all of a sudden, but the db in question has been in this state for the past 12 hrs. I checked the mirroring status on the principal and it states that it is "synchronizing: data is being transferred from principal to mirror", but the mirror server states that db is in "restoring" state. Can anyone suggest as to how I can get the database on the mirroring server to get back to "mirror, synchronizing/restoring..." state? Or suggest on how I can troubleshoot this?

Thanks in advance.

Have you tried pulling up the Database Mirroring Monitor, to see what it shows? Do you have Unsent Log or Unrestored Log? Does the I/O subsystem on the mirror have comparable I/O capacity to the Principal?

Primary Key Violation - Transactional Replication

Hi All,
I have setup a transactional replication between 2 SQL 2005 servers.
Unfortunately, I am getting the error listed below:
Replication-Replication Distribution Subsystem: agent
JFCIS3TRM02-JFJDAT-JFJDAT_PUBLICATION-JFCIS3TRM01-13 failed.
Violation of PRIMARY KEY constraint 'ARSTRUN_KEY_0'. Cannot insert duplicate
key in object 'dbo.ARSTRUN'.
Is this error being raised because I haven't enabled automatic range
management? If so, how would I fix this error?
Regards,
JN
Hi Paul,
The type of transactional replication setup is just the plain one, not the
one with updatable subscription.
I am not sure whether it is nosync or automatic as I used the wizard and I
didn't recall being asked for those settings.
Regards,
JN
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:eWzOLQD2HHA.4680@.TK2MSFTNGP03.phx.gbl...
>I really need to know what type of transactional replication setup you have
>configured - plain, updatable (immediate or queued) and nosync or
>automatic...
> Cheers,
> Paul Ibison
>
|||That could be possible since I have created an ODBC connection to the
replicated database which an end user can select from a drop down list when
they open the application.
What do you suggest I do to get the two databases synchronized again?
"Paul Ibison" <Paul.Ibison@.Pygmalion.Com> wrote in message
news:OjdWiMF2HHA.5164@.TK2MSFTNGP05.phx.gbl...
> OK - in that case my suspicion is that someone has entered a row on the
> subscriber. Is that possible? In this plain transactional case the
> subscriber data is supposed to be read only and only changed via the
> distribution agent.
> HTH,
> Paul Ibison
>

Primary Database Backup in Log Shipping Scenario

I've setup a Log Shipping scenario for one of our databases. This works fine.
Also, every night a full database backup of the primary database is made to a
disk location. Normally, the transaction log would be truncated after a full
database backup. This behavior is unwanted in a Log Shipping scenario since
the content of the transaction log needs to be applied to the secondary
database. We've seen that since the Log Shipping scenario is in place, the
log is no longer truncated after the full database backup of the primary
database. How does the primary database "know" not to truncate the
transaction log? In other words, I'd like to know how the full database
backup mechanism works in a Log Shipping environment.
Are you saying you with issue a backup log with truncate_only statement
after your backup has finished?
ie
backup log fulltext with truncate_only
If so, this will break your log shipping chain and should not be done.
The way a log shipping works is a backup is done. Embedded in the backup is
the LSN (Log Sequence Number) for the transaction log. The next log backup
you do contains log enteries starting at the lsn for this last backup. So
you can restore the log to the database backup where the lsn matches the lsn
embedded in the backup.
If you then deploy log shipping and do a backup the backup entry is in the
log but it is ignored, so you can continue to apply subsequent log dumps
without breaking the chain.
Does this answer your question?
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Wilbert" <Wilbert@.discussions.microsoft.com> wrote in message
news:542507D8-50F4-4CEC-BEE5-36DF1EBBA607@.microsoft.com...
> I've setup a Log Shipping scenario for one of our databases. This works
> fine.
> Also, every night a full database backup of the primary database is made
> to a
> disk location. Normally, the transaction log would be truncated after a
> full
> database backup. This behavior is unwanted in a Log Shipping scenario
> since
> the content of the transaction log needs to be applied to the secondary
> database. We've seen that since the Log Shipping scenario is in place, the
> log is no longer truncated after the full database backup of the primary
> database. How does the primary database "know" not to truncate the
> transaction log? In other words, I'd like to know how the full database
> backup mechanism works in a Log Shipping environment.
|||Hello Hilary,
I'll clarify my question: I'd like to know how SQL Server "knows" whether a
Log Shipping scenario is in place, and I'd like an explanation to the
subsequent difference in behavior when performing a Full Database backup
(truncate the log in "normal" operation and not truncating the log in a Log
Shipping scenario).
Best regards, Wilbert
|||SQL Server does not know if a log is being shipped or not. Log shipping fits
into the existing point in time recovery scheme that sql server uses to
recover databases.
If you truncate a log it will remove all committed entries in that log.
Logged open transaction and other non-committed commands will remain in the
log since the last checkpoint. There is no log truncation after a back up in
full recovery model, not in bulk logged. The problem with bulk logged is
that minimally logged operations are minimally logged and will destroy your
log shipping chain.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Wilbert" <Wilbert@.discussions.microsoft.com> wrote in message
news:00B5F549-71CE-4089-A81A-A537B6BA212F@.microsoft.com...
> Hello Hilary,
> I'll clarify my question: I'd like to know how SQL Server "knows" whether
> a
> Log Shipping scenario is in place, and I'd like an explanation to the
> subsequent difference in behavior when performing a Full Database backup
> (truncate the log in "normal" operation and not truncating the log in a
> Log
> Shipping scenario).
> Best regards, Wilbert
|||Hello Hilary,
Isn't it so that after a full database backup the committed entries in the
log are removed?
That's the origin of my question: in "normal" operation these entries are
removed from the log, while in a log shipping scenario this doesn't seem to
be the case. This led me to believe that SQL Server somehow "know" that log
shipping is taking place and that the entries in the log should be retained
until the next log backup.
Best regards, Wilbert
|||No, the log is insert and read only. What happens is that it is a record of
all of your database activity. Before anything hits disk it is written to
your log. When you issue a checkpoint the checkpoint is written to the log
and all dirty pages (including uncommitted pages are written to disk).
Should a failure occur the log is consulted to find the last checkpoint and
uncommitted transactions which occurred after the last checkpoint are
removed from disk and committed transactions which committed after the last
checkpoint are written to disk.
When you do a db backup nothing happens to the log other than the backup
happened. When you do a log backup, the internal vlf's in the log buffer I
believe have their status changed to 0 if there are no active transactions
in them. But the log itself does not have anything happen to it.
The above applies to full recovery model.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Wilbert" <Wilbert@.discussions.microsoft.com> wrote in message
news:668C79A5-01E2-4336-94D9-EB76B8D23866@.microsoft.com...
> Hello Hilary,
> Isn't it so that after a full database backup the committed entries in the
> log are removed?
> That's the origin of my question: in "normal" operation these entries are
> removed from the log, while in a log shipping scenario this doesn't seem
> to
> be the case. This led me to believe that SQL Server somehow "know" that
> log
> shipping is taking place and that the entries in the log should be
> retained
> until the next log backup.
> Best regards, Wilbert