Shrink Database in MS SQLServer7(100分)

  • 主题发起人 主题发起人 HanFeng
  • 开始时间 开始时间
H

HanFeng

Unregistered / Unconfirmed
GUEST, unregistred user!

原来MS SQL6.5上有一个库,1G(日志和数据公用一个设备),升级到MS SQL7
后,自动分成了2部分,一个数据文件,正常大小,另一个日志文件,1G.通过组合应
用ShinkDataBase,
ShinkFile,Truncate logs,现在缩减到376M左右.实际上系统报告(all task -> shink database)used 17.92M,如何才能找回浪费的340M空间?
为了解决上述问题,我使用过更改文件名的方法,当修改文件名后,有时会将数据库变得可疑,如何恢复.
 
需要用DBCC命令进行处理，具体忘记了，呵呵
查查吧，一致性校验，和容量估计吧
 
CJ:
不知您帮我解决压缩日志文件的问题还是恢复可疑表的问题
对于前者,MS SQL 7的DBCC支持的命令已经大为减少,剩下的几个
使了,好像并没有效果,(没有枚举测试每个选项参数).通过阅读联机
帮助Transaction log--shrinking,似乎是不能再缩了,(我的E文不好,
猜他大概是这个意思.)
对于后一个问题,因为我在胡作非为之前作过备份,把它DROP,然后重新
恢复了一个,当然又用掉1G,然后又缩减到376M.
但我听说有解决办法,如果您知道具体方法,麻烦您告诉我.但是我想,
我在胡作非为之前会作备份,用户可不一定,类似的情况以前也发生过
一次,是因为在服务器上挂了一块硬盘,挪动了盘符,导致一个原来装在
d上的DATABASE可疑了,所以我想一定有人遇到过这种情况.
BTW,您和其他大虾在发布MS SQL数据库用的是什么方法,我一直在用
BACKUP & RESTORE 的方法,不知是否正解?正是因为这种方法,才让我
遇到了这个问题.
 
sql7还真有这么多人用:-) 我可不敢, 一来机器太慢, 二来bug太多:-(
 
1.用truncateonly 参数
在BOL中:
DBCC SHRINKDATABASE
( database_name [, target_percent]
[, {NOTRUNCATE | TRUNCATEONLY}]
)

Arguments
database_name
Is the name of the database to be shrunk. Database names must conform to the rules for identifiers. For more information, see Using Identifiers.
target_percent
Is the desired percentage of free space left in the database file after the database has been shrunk.
NOTRUNCATE
Causes the freed file space to be retained in the database files. If not specified, the freed file space is released to the operating system.
TRUNCATEONLY
Causes any unused space in the data files to be released to the operating system and shrinks the file to the last allocated extent, reducing the file size without moving any data. No attempt is made to relocate rows to unallocated pages. target_percent is ignored when TRUNCATEONLY is used.


2.
 
taik先生:
谢谢您关心我的问题.
应用您1.方法,可以从1G缩减到376m.但不能从376m往下缩.
在bol的FAQ中有I execute DBCC SHRINKDATABASE to shrink my transaction
log files.However, they don't seem to be shrinking. What's going on?
其中谈到shrink 到virtual logfile bondary时,不能再缩,不知是否使用于本问题?
6.5升级到7时,是否自动生成VIRTUAL LOG FILE?
2.以后的文字看不到.
 
1.database
dbcc SHRINKDATABASE (mydatabase,5)
剩5%的空间.
2 清log
backup log mydatabase TRUNCATEONLY
3.清log file
再DBCC SHRINKFILE

可疑问题我再查下
 
taik:
还是不行,不过你启发了我,能否不带日志备份,然后重新恢复?
 
1.backup log with "no_log" to clear the log.

2.about a suspect database:

exec sp_config "allow update",1
exec reconfig with override
exec sp_resetstatus 'database_name'
exec sp_config "allow update",0
restart your SQL server.

U need rename your database file back to it's normal status.
Or U can modify the MASTER DB to do it.

 
Taik:
谢谢您的帮助,可疑数据库的问题解决了,您的方法是对的,具体语句如下:
exec sp_configure "allow update",1
reconfigure with override
exec sp_resetstatus 'test' /*test是可疑数据库的名字*/
exec sp_configure "allow update",0
reconfigure
go
restart sql server
您肯定会有分.
shrink database 仍然不成功,原因是backup log 或backup without log
正确写法我不知道,无法实现.
 
to cytown: SQL7有很多bug吗? 我也还没用呢.
 
HanFeng:
你在发布数据库时，是否先Backup原数据库，然后在发布时，Restore
Database 原数据库，这时，是否应先在Sql Server 7中创建Database
然后恢复，可我这样做时，在Restore 时，老出现ID 错误，请问这里
有何诀窍可以正确发布数据库?
另：to cytown: SQL7有很多bug吗? 能否说明一下？你采用什么数据库呢?
 
呵呵, sql6.5到现在已经sp5了, sql7能没有bug, 那才见鬼了呢:-)
而且企业应用 1是看稳定性, 2是看性能, sql7新出, 稳定性肯定没有sql6.5好吧?!
再从性能来看, sql7需要比sql6.5高得多的配置, 因此, 也许在你目前机器上运行
如飞的数据库, 在sql7上, 也许只能喘喘气而已.
 
To pount:
Id 号错误我以前也遇到过,是由于备份恢复
时设置错误引起的.主要问题产生于以下2点:
1. Src DB & Dst DB unicode 不一致,可以通过
sp_configure 看到这一点,
2.Dst DB 必须先创建一个备份, 且与Src DB
包含备份个数相同.
做到以上2点,应该不会出现id号错误问题.
我出钱,替你解答问题,真不公平!
To cytown:
我被sql 6.5 搞怕了,所以使用7.用7作过2个
项目,1大1小,均未经实践检验.实验室感觉7
比6.5方便易用,运行速度与6.5无大差异,
但Enterprise Manager运行缓慢.理论上应该比
6.5 有更高的OLTP能力.未发现明显BUG.
 
To HanFeng:
感谢！但您说的我不太明白。
1. 如何使其ID号一致？
2. Dst DB 要先创建(?),然后再生成一备份(?),可该新创建的
Dst DB 无任何内容，备份又有何意义?
3. Dst DB 创建后，再恢复，可恢复后(用Force Restore existing
database),原用户无法进入?必须创建别的用户才可以，请
问：该如何做？（请详细些，我给你加分,谢谢)
 
另：我在恢复时，若已建好数据库，再恢复则出现提示：
"The Backup set holds a backup of a database other then the
existing 'test' database"
若是不建数据库就恢复，则恢复完后，想重新用原来的用户登录，则出
错，若创建该登录用户，然后设置其Database Access为test,(该用户
和原用户名一致,出现提示：
"user or role already exist in the current database"
HanFeng,真不好意思，借你的宝地一用，不过，若回答正确的话，
我一定给他加分!
 
to pount:
我低估了你的问题,没想到你遇到的问题这么麻烦,我现在没条件帮你试
但是我想你用我说的办法可以解决.操作时注意以下问题
1.在另一个数据库上恢复和在本地恢复不一样
2.BACKUP时,SQL 7 会在MSDB中记录一大堆信息,其中包括备份ID号
3.在另一台机器上恢复时,按我说的方法,先建立一个空备份,然后用
SRC DB 备份文件将其覆盖,然后恢复,可能这样可以在DST DB 的 MSDB中
产生一大堆伪信息,欺骗MS SQL 7.
4.做空备份和备份SRC DB时,注意包含相同个数的备份,最好用覆盖方式
不要用追加方式备份.
5.用以上办法我已经多次实现了异地恢复,从未出现过问题.
6.你说的用户帐号问题没遇到过,现在我没有环境,无法作异地恢复试验.
taik哪里去了?我的db 还370m呢
 
HaHa,以为这问题早结束了，好久没来了。

终于仔细看了下问题(不好意思，以前都是一目十行),对问题的理解为:
Data File大小正常，Log File占了300MB左右？

我的想法:
1.backup log with "No Log"参数(在BOL中用No Log查)。
2.Shrink log file
理由:如果我对问题理解正确的话，应该是在Log中有较大的No Active的
交易存在。No Log通常在Log占满了磁盘，TRUNCATE_ONLY 无效时用。

To: Pount、Han Feng,
1.通常Backup database-->把database中的Object(User,table...)等转成SQL
脚本-->安装(含运行脚本)。
2.如果目标机和源机在同一Lan上，用DTS较简单。
3.在oracle 7,Sybase 10上作过开发，建Dump 设备-->backup-->目标机建
Backup设备-->copy dat文件到目标机-->restore,没问题。SQL7应该更简单。
4.没用SQL Server作过开发，全是纸上谈兵。
5.环境P133+Windows 2000 AS+SQL 7,没作过应用，还未见到什么Bug。速度
不比Sybase 10差(作过简单的应用对比).


 
实在搞不定,结束讨论,姑且认为此题无解
taik 先生对可以数据库的处理意见非常正确,分全部给他吧!
 
您必须登录或注册才可回复。

Similar threads

Ray
[转]终于可以发布Delphi下收点OSGI精髓皮毛而设计的插件框架WisdomPluginFramework
回复
4
查看
4K
chlkuei
C
Q
如何合并sqlserver7中的数据库(100分)
回复
2
查看
191
louhong
L
力
SqlServer7的备份文件在SqlServer2000还原后存在问题(100分)
回复
0
查看
139
力奇
力
Q
database控件无法访问sqlserver7下演示数据库Northwind(50分)
回复
5
查看
117
qufengtao
Q
N
一个关于MS SQL Server7.0 的怪问题(50分)
回复
8
查看
147
duancy
D
后退
顶部