Showing posts with label mydatabase. Show all posts
Showing posts with label mydatabase. Show all posts

Friday, March 30, 2012

How to remove WITH FILLFACTOR = 100 when Generate Sql Script ?

Hello,

I'm using Entreprise Manager (for Sql Server 2000) to generate my
database's script. By mistake, i've changer FillFactor one time. And,
now I can't remove this data from generated sql script. How to remove
that ?

Thank's a lot.rabii (rabii.mail@.gmail.com) writes:
> I'm using Entreprise Manager (for Sql Server 2000) to generate my
> database's script. By mistake, i've changer FillFactor one time. And,
> now I can't remove this data from generated sql script. How to remove
> that ?

Can't you just run the file through a search/replace session in some
text editor? Then you could build a new database, and then script
from that one.

Even better, have all your SQL code under version control, so you
don't have to script from the databaes.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||Thanks for reply :),

I know this solutions :), but, the problem that I have a production
database. For each new version of my product, I have to compare my new
database schema and the old one (current production database). So the
tool "Sql Server Compare" (by comparing the databases script) show me
always that all the table are different although the difference is
simply the FILLFACTOR (in production database). Now I can change it
using Entreprise Manager but I can't remove it ?|||If that's Red-Gate's SQL Compare, I think that there is an option to
ignore fillfactors, among other things. Unfortunately, I'm at a machine
that doesn't have that tool installed, so I can't confirm that. I know
that you can definitely ignore some things, and I *think* that
FILLFACTOR is one of them.

Good luck,
-Tom.|||rabii (rabii.mail@.gmail.com) writes:
> I know this solutions :), but, the problem that I have a production
> database. For each new version of my product, I have to compare my new
> database schema and the old one (current production database). So the
> tool "Sql Server Compare" (by comparing the databases script) show me
> always that all the table are different although the difference is
> simply the FILLFACTOR (in production database). Now I can change it
> using Entreprise Manager but I can't remove it ?

So where is the fill factor wrong? In the development database or in
the production database? But whichever, can't you just adapt the
fillfactor of the development database to the production database?

Then again, fill factor is one of these things that could be different
from database to database, because different instances of the schema
has different data load. So you should probably see if your comparison
tool can ignore difference in fill factor.

Finally, I can't keep from saying that the whole thing of comparing
database schemas to build change scripts is not a very good idea. Do
you really want all sort of test junk in the dev database hit the
production server? If you have your code under version control,
you can build change scripts from the version-control system. This
gives you a much more solid base to stand on.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||thanks again for every one :)

I've said that I'm using the tool "Sql Server Compare" (it's a free
tool).

You're right when you said that it is better to use a version control
solution. But now the problem, that by mistake, I've added fillfactor =
x in the production database. In the dev database, I havn't did that.
When I compare the two databases, I notice that the comprator (sql
server compare) show me that all the table are different. When I
analyse the code, simply the fill factor is not the same. I can resolve
that by adding the same fillfactor in my dev database but I wan't to
know " if there is a way by script to remove fillfactor = x" ?|||rabii (rabii.mail@.gmail.com) writes:
> I've said that I'm using the tool "Sql Server Compare" (it's a free
> tool).
> You're right when you said that it is better to use a version control
> solution. But now the problem, that by mistake, I've added fillfactor =
> x in the production database. In the dev database, I havn't did that.
> When I compare the two databases, I notice that the comprator (sql
> server compare) show me that all the table are different. When I
> analyse the code, simply the fill factor is not the same. I can resolve
> that by adding the same fillfactor in my dev database but I wan't to
> know " if there is a way by script to remove fillfactor = x" ?

For an index you should be able to get rid of with with CREATE INDEX ...
WITH DROP_EXISTING. If it's a PRIMARY KEY constraint of a UNIQUE constraint,
I think you have to drop and recreate. Since you typically have FK
constraints to a PK, that can be kind of messy.

I played around a little, and it seems that Enterprise Manager does not
include fillfactor for primary keys, so changing your dev database may
not help.

Looks as if you either have to rebuild the production database or give
SQL Server Compare the boot...

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

Monday, March 12, 2012

HOw to recover a database from the .LDF file.

Hi,
Due to a hardware problem I lost my mydatabase.MDF file, but my
mydatabase.LDF file is still OK because it is on another partition. I can
restore the database, but (here comes Murphy) the tape containing the
transaction logs backups is corrupt too. Since my last full backup I made
transaction log backups with the NO_TRUNCATE option, so everything should be
in the mydatabase.LDF file. After restoring the database in no_recover mode,
how can I apply the transactions that are still in mydatabase.LDF file
(NO_TRUNCATE)?
Any help is welcome.
Thanks
Felix> Since my last full backup I made
> transaction log backups with the NO_TRUNCATE option, so everything should be
> in the mydatabase.LDF file.
I'm afraid not. The name of that option is misleading. See
http://www.karaszi.com/SQLServer/info_restore_no_truncate.asp
Your best bet is probably to use a log reader tool and see if you can salvage anything from the
existing log backup. But, as per the article, the information in the prior log backups is most
probably lost. You might want to open a case with MS Support and see if they have anything up their
sleeves.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Felix" <Felix@.discussions.microsoft.com> wrote in message
news:D686735A-BF91-40EA-BBD3-16ED67B13E3B@.microsoft.com...
> Hi,
> Due to a hardware problem I lost my mydatabase.MDF file, but my
> mydatabase.LDF file is still OK because it is on another partition. I can
> restore the database, but (here comes Murphy) the tape containing the
> transaction logs backups is corrupt too. Since my last full backup I made
> transaction log backups with the NO_TRUNCATE option, so everything should be
> in the mydatabase.LDF file. After restoring the database in no_recover mode,
> how can I apply the transactions that are still in mydatabase.LDF file
> (NO_TRUNCATE)?
> Any help is welcome.
> Thanks
> Felix|||Hi Tibor,
Thanks for your answer, this helped us a lot.
Lucky enough, this was not a production database, but a test we were
performing.
Indead, the NO_TRUNCATE is misleading.
This means also that you are only able to restore till the time of failure
if you are able to backup the still existing logs first, else you can only
restore untill the latest log backup. This means that you should backup as
often as possible for critical DB's!
Kind regards
Felix
"Tibor Karaszi" wrote:
> > Since my last full backup I made
> > transaction log backups with the NO_TRUNCATE option, so everything should be
> > in the mydatabase.LDF file.
> I'm afraid not. The name of that option is misleading. See
> http://www.karaszi.com/SQLServer/info_restore_no_truncate.asp
> Your best bet is probably to use a log reader tool and see if you can salvage anything from the
> existing log backup. But, as per the article, the information in the prior log backups is most
> probably lost. You might want to open a case with MS Support and see if they have anything up their
> sleeves.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Felix" <Felix@.discussions.microsoft.com> wrote in message
> news:D686735A-BF91-40EA-BBD3-16ED67B13E3B@.microsoft.com...
> > Hi,
> > Due to a hardware problem I lost my mydatabase.MDF file, but my
> > mydatabase.LDF file is still OK because it is on another partition. I can
> > restore the database, but (here comes Murphy) the tape containing the
> > transaction logs backups is corrupt too. Since my last full backup I made
> > transaction log backups with the NO_TRUNCATE option, so everything should be
> > in the mydatabase.LDF file. After restoring the database in no_recover mode,
> > how can I apply the transactions that are still in mydatabase.LDF file
> > (NO_TRUNCATE)?
> >
> > Any help is welcome.
> >
> > Thanks
> >
> > Felix
>

HOw to recover a database from the .LDF file.

Hi,
Due to a hardware problem I lost my mydatabase.MDF file, but my
mydatabase.LDF file is still OK because it is on another partition. I can
restore the database, but (here comes Murphy) the tape containing the
transaction logs backups is corrupt too. Since my last full backup I made
transaction log backups with the NO_TRUNCATE option, so everything should be
in the mydatabase.LDF file. After restoring the database in no_recover mode,
how can I apply the transactions that are still in mydatabase.LDF file
(NO_TRUNCATE)?
Any help is welcome.
Thanks
Felix
> Since my last full backup I made
> transaction log backups with the NO_TRUNCATE option, so everything should be
> in the mydatabase.LDF file.
I'm afraid not. The name of that option is misleading. See
http://www.karaszi.com/SQLServer/inf...o_truncate.asp
Your best bet is probably to use a log reader tool and see if you can salvage anything from the
existing log backup. But, as per the article, the information in the prior log backups is most
probably lost. You might want to open a case with MS Support and see if they have anything up their
sleeves.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Felix" <Felix@.discussions.microsoft.com> wrote in message
news:D686735A-BF91-40EA-BBD3-16ED67B13E3B@.microsoft.com...
> Hi,
> Due to a hardware problem I lost my mydatabase.MDF file, but my
> mydatabase.LDF file is still OK because it is on another partition. I can
> restore the database, but (here comes Murphy) the tape containing the
> transaction logs backups is corrupt too. Since my last full backup I made
> transaction log backups with the NO_TRUNCATE option, so everything should be
> in the mydatabase.LDF file. After restoring the database in no_recover mode,
> how can I apply the transactions that are still in mydatabase.LDF file
> (NO_TRUNCATE)?
> Any help is welcome.
> Thanks
> Felix
|||Hi Tibor,
Thanks for your answer, this helped us a lot.
Lucky enough, this was not a production database, but a test we were
performing.
Indead, the NO_TRUNCATE is misleading.
This means also that you are only able to restore till the time of failure
if you are able to backup the still existing logs first, else you can only
restore untill the latest log backup. This means that you should backup as
often as possible for critical DB's!
Kind regards
Felix
"Tibor Karaszi" wrote:

> I'm afraid not. The name of that option is misleading. See
> http://www.karaszi.com/SQLServer/inf...o_truncate.asp
> Your best bet is probably to use a log reader tool and see if you can salvage anything from the
> existing log backup. But, as per the article, the information in the prior log backups is most
> probably lost. You might want to open a case with MS Support and see if they have anything up their
> sleeves.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Felix" <Felix@.discussions.microsoft.com> wrote in message
> news:D686735A-BF91-40EA-BBD3-16ED67B13E3B@.microsoft.com...
>

HOw to recover a database from the .LDF file.

Hi,
Due to a hardware problem I lost my mydatabase.MDF file, but my
mydatabase.LDF file is still OK because it is on another partition. I can
restore the database, but (here comes Murphy) the tape containing the
transaction logs backups is corrupt too. Since my last full backup I made
transaction log backups with the NO_TRUNCATE option, so everything should be
in the mydatabase.LDF file. After restoring the database in no_recover mode,
how can I apply the transactions that are still in mydatabase.LDF file
(NO_TRUNCATE)?
Any help is welcome.
Thanks
Felix> Since my last full backup I made
> transaction log backups with the NO_TRUNCATE option, so everything should
be
> in the mydatabase.LDF file.
I'm afraid not. The name of that option is misleading. See
http://www.karaszi.com/SQLServer/in...no_truncate.asp
Your best bet is probably to use a log reader tool and see if you can salvag
e anything from the
existing log backup. But, as per the article, the information in the prior l
og backups is most
probably lost. You might want to open a case with MS Support and see if they
have anything up their
sleeves.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Felix" <Felix@.discussions.microsoft.com> wrote in message
news:D686735A-BF91-40EA-BBD3-16ED67B13E3B@.microsoft.com...
> Hi,
> Due to a hardware problem I lost my mydatabase.MDF file, but my
> mydatabase.LDF file is still OK because it is on another partition. I can
> restore the database, but (here comes Murphy) the tape containing the
> transaction logs backups is corrupt too. Since my last full backup I made
> transaction log backups with the NO_TRUNCATE option, so everything should
be
> in the mydatabase.LDF file. After restoring the database in no_recover mod
e,
> how can I apply the transactions that are still in mydatabase.LDF file
> (NO_TRUNCATE)?
> Any help is welcome.
> Thanks
> Felix|||Hi Tibor,
Thanks for your answer, this helped us a lot.
Lucky enough, this was not a production database, but a test we were
performing.
Indead, the NO_TRUNCATE is misleading.
This means also that you are only able to restore till the time of failure
if you are able to backup the still existing logs first, else you can only
restore untill the latest log backup. This means that you should backup as
often as possible for critical DB's!
Kind regards
Felix
"Tibor Karaszi" wrote:

> I'm afraid not. The name of that option is misleading. See
> http://www.karaszi.com/SQLServer/in...no_truncate.asp
> Your best bet is probably to use a log reader tool and see if you can salv
age anything from the
> existing log backup. But, as per the article, the information in the prior
log backups is most
> probably lost. You might want to open a case with MS Support and see if th
ey have anything up their
> sleeves.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> Blog: http://solidqualitylearning.com/blogs/tibor/
>
> "Felix" <Felix@.discussions.microsoft.com> wrote in message
> news:D686735A-BF91-40EA-BBD3-16ED67B13E3B@.microsoft.com...
>