Quote:
Originally posted by pokksey
Okay,
Next, I had a problem with the space on my database (It was only 2M). So I created a segment on my master data device and gave it 20M of space. At least, I think that's what I did. But it is now accepting data.
I assume that when I run out of space on the master segment I will need to create another segment with an allocated amount of space? Is 20M enough (for a small palm app with 6 tables/30 fields@50 records in each table a day: all cols varchar(255)) ? Is this a naive question?
Just one more query regarding rowsize. I have used varchar(255) for most of my columns and got a warning when I created the columns about the rowsize not being large enough. Should I change the rowsize of each column? How? And will the current setup truncate my data if it exceeds the default rowsize?
Thanks for the help...
Poks
|
Hi Poks,
I'm beginning to form a picture of what you did. It sounds like you created a database as follows:
create database ActivityMonitoring
go
This creates a database on the "default devices" and the default size. After installing ASE the master device has the attribute of "default device". The best thing to do is prevent any databases to be accidentally created on the master device is to turn off the attribute:
exec sp_diskdefault, 'master', defaultoff
go
If you have no default devices then ASE will complain when you create a database, asking you to specify which devices the database will be created on. This is good because you're now in charge of the environment.
You are correct to be concerned the space on the master device. The master database cannot be moved from the master device or extended on to another device. At the moment that's probably OK. but after few logins etc have been added the master database will begin fill up, especially if its the default size, 6MB.
The best thing to do recreate the ActivityMonitoring database on it's own devices or on specific data and log devices, away from the master device.
You're going to need some downtime to do this. So stop the application while you're making the changes.
Obtain the script used to create the database, including the alterations you have just made. Store this in a safe place. Also dump the database so that it can be reloaded later.
Create two new devices; data_01 and log_01. These need to be large enough to contain both the data and log parts of the database. Create these devices using disk init in the same manner as you recently created the log device.
Something like this (assuming winnt as the OS) will suffice
disk init
name = "data_01",
physname = "c:\devices\data_01.dev"
size = 51200
go
disk init
name = "log_01",
physname = "c:\devices\log_01.dev"
size = 51200
go
Once done, create a new database on these devices, remember the name of the database must be changed in the script because you can't have two databases with the same name.
Your database creation script will need to look something like this, but exact script will depend on the sizes and segment maps used when creating the database in the first place.
create database ActivityMonitoring_New on data_01
go
alter database ActivityMonitoring_New on log_01 = Size of log you specified
go
alter database ActivityMonitoring_new on data_01 = 20
go
Load the dump of the database into the newly created database.
Run sp_helpdb ActivityMonitoring and sp_helpdb ActivityMonitoring_New and check the segment maps are the same. The segment map is the allocation of default, system and logsegments within the database.
You now need to rename the databases so the application doesn't pick up the old database.
The following renames ActivityMonitoring to ActivityMonitoring_old. You'll need to do something similar to change ActivityMonitoring_New to ActivityMonitoring.
use master
go
sp_dboption ActivityMonitoring, 'single', true
go
use ActivityMonitoring
go
checkpoint
go
sp_renamedb ActivityMonitoring, ActivityMonitoring_old
go
use master
go
sp_dboption ActivityMonitoring, 'single', true
go
use ActivityMonitoring
go
checkpoint
go
If everything went OK the old database should have _old on the end of it.
When you run out of space you will need to allocate more space. But don't allocate it on the master device. It makes recovery very difficult if the master device dies.
20 MB should be sufficient for you data as your specifications add up to 2,295,000. In real life this will be larger, but so that you would need to worry about it.
The warning you received was probably something along the lines "The row size may exceed the page size". This is only going to be a problem if you have a single row that is longer than 1960 bytes. The length of the data in the row will be slightly shorter because of the overheads to mange a row. If a row length greater than 1960 bytes is applied the insert or update statement will fail with an error message indicating the row length was too large.
Personally I would reconsider the data model and design the database with a fewer number of varchar columns. You may also be able to take advantage of smaller indexes and improve the performance of the application.
Let us know how you get on.
Richard.