unfortunately unless you got a very very high log set in the instance and a very long journal history you can't discover that.

If you got the info you can find in the journal the global change, get the process info and search the log for them. But usually is something that you can spot in the near time or something that happens on a regular basis, something spot is really difficult to find in that way.


never done that, always installed production under linux. Respecting the allocation size it will be good to match the same size so if you are using only 8k, it should be better to have 8k also on fs so 1 unit for db should also be 1 unit for fs and it won't be split in 2 fs operation. 8k should be fine because you can accept that if you are using a mixed db allocation size for 8k and 16k it will always be beneficial also for 16k chunks.

On this argument always remember to align the partition and the fs dropping the first bytes as per ms best practice so that also the disk (if on a raid) could match the writes


the error is quite generic and it basically says that you can't login but you don't know why.

Check that the superserver port is the same used in studio,

Check the license on the instance.

If the everything is fine, fire up the management portal, go to
system administration -> security -> auditing -> enable auditing
and check that the auditing is enabled. After that go to
system administration -> security -> auditing ->  configure system events
and check that
is enabled. If not click on "change status".

Try to login again with studio and check the audit database
system administration -> security -> auditing -> view audit database
and see what error comes up